Comment by teddyh | Hacker News Reader

Comment by teddyh | Hacker News Reader

I agree with the article, but I would go even further. This whole thing is stupid. You physically can’t put an IP address into an MX DNS record. What the syntax (perhaps misleadingly) allows is to put a domain name there with labels consisting of only digits. That is, the “IP adress” 1.2.3.4 you wrote in your MX record is actually the domain name "1.2.3.4.yourdomain.com" with “1”, “2”, “3”, “4”, “yourdomain”, and “com” as the individual domain labels. There is no way to actually store an IP address in an MX DNS record. It just so happens that the usual syntax for IPv4 addresses turns out to be valid syntax for an (unrelated) domain name as well.

And, of course, if you try to write an IPv6 address, it will naturally fail, since IPv6 addresses uses colon “:” characters, which are not allowed in domain names.

Therefore, it would be beyond silly for programs to actually use these invalid domain names in MX records. MX records which point to domain names which cannot be resolved are simply broken.

Out of curiosity though: why is it like this? Wouldn't it make a lot more sense to set an IP address instead of a hostname? Now the admin needs to keep track of an additional DNS entry (for the mail server) and the client has to make one additional request.

It’s been the way since way back in the 80s.

Domain name is often the best way to go. Esp if different organisations are involved (like a mail hostel.)

Only A and AAAA records take an IP. Everything else is a hostname. This simplifies administration, as there's only one hostname->IP config point, so you have the flexibility to resolve the rest dynamically.

It's a good question. It did not have to be designed this way, and indeed there have existed for some decades now DNS content server softwares that hide this indirection from administrators as a convenience, and synthesize the intermediate domain names if necessary. For example, the back-end database for tinydns has "@" records in its source data files, and an administrator can (optionally) just enter:

    @example.net:192.0.2.0::10

tinydns synthesizes "mx.example.net." for the intermediate domain name.

* http://jdebp.uk./Softwares/djbwares/guide/commands/tinydns-d...

That said, the SMTP Relay server needs to know that "mx.example.net." is one of its names, if it is a fallback server.

One can envision a world where records in the DNS database map a (domain,service,transport) tuple directly to a set of (address,port,preference,weight) tuples, where that is what administrators consistently deal with for everything, where that is how the on-the-wire protocol actually works, and where SMTP Relay loop prevention works by comparing IP addresses; but SMTP doesn't work like that, the DNS did not start out like that, the DNS has gone through at least two iterations to even get to where it is now with SRV and MX records, and the DNS has grown through fitting new mechanisms against existing ones.

One point about "mx.example.net.": If the intermediate domain names are in-bailiwick like that, and the MX response contains "glue", then it is not actually "one additional request".

> That said, the SMTP Relay server needs to know that "mx.example.net." is one of its names, if it is a fallback server.

It also would need to know its name in order to have SMTP over TLS to work (as required by DANE).

> Out of curiosity though: why is it like this?

In order to have a pointer to what you actually want to have.

MX points to a hostname. This hostname can have many records including A, AAA, TXT, etc which are used by MTAs such as postfix and sendmail for delivery and verification. Also you'd have to make changes only in the hostname records which would affect all other records in the zone that point to it. Easier to maintain.

An MX record is a mail authority delegation.

The History Department at a major university could delegate mail to be handled by the schools IT department and need not be involved in the movement of a mail server from one IP to another.

This decision was made in a time when running mail involved lots of external coordination and was best delegated to a single central group, whereas a simple web server could be spun up by a technical person within the History dept.

MX records are used to point to mail servers by name. A/CNAME records handle redirection and pointing a name to IPs.

Having different DNS types helps simplify administration far more than the overhead of another entry.

What if I write 4.3.2.1.in-addr.arpa. instead?

That's a name, not an IP address. And what you would expect to find at that name is not an A record for that IP address (which would be redundant) but a PTR record providing its canonical name.

At some point someone’s going to get the .0 to .255 TLD somehow and cause a security fuffle.

As luck would have it, that’s probably not going to affect most people, because people who write an “IP address” in an MX record probably also didn’t put the terminating period at the end. Therefore, the MX record to “1.2.3.4” resolves to the local name “1.2.3.4.example.com” and not a domain in the hypothetical “.4” TLD.

Now I wonder how many of these might have the ability for users to create subdomains ... shades of being able to make "webmaster@" addresses for email sites and get an SSL cert or whatever.

Some software / sites put one there for you. Which is annoying when you don't want it.

According to RFC 1123:

However, a valid host name can never have the dotted-decimal form #.#.#.#, since at least the highest-level component label will be alphabetic

https://tools.ietf.org/html/rfc1123#page-13

Finally, 359.33.9.234 can be real.

> 359.33.9.234

I searched to see where it's from (CSI: Miami) and found a screenshot of it in a gallery with even more egregious examples, like 67.259.2942.1003 and 8394.83.384.38482:

https://www.root.cz/galerie/pocitacove-nesmysly-ve-filmech/#...

It's a simple way to avoid numbers on-screen from coinciding with any real IP addresses. It's the equivalent to phone numbers always starting with 555.

I'm not sure if this is still the case, but 555-1212 is the number for directory assistance.

NANP [1] has reserved other line numbers for other uses, including specifically entertainment

[1] https://nationalnanpa.com/number_resource_info/555_numbers.h...

In an alternate timeline, using four 16-bit numbers instead of octets could very well have been a solution to the IPv4 shortage. :)

Or in the future, CHAOS-2 could use one 1024 bit decimal number, making IPV6 obsolete, and disrupting the page layout of HN threads!

https://en.wikipedia.org/wiki/Chaosnet

All hail the second coming of Chaosnet, the return of the Tzeentch Control Protocol!

https://lovecraft.fandom.com/wiki/Chaos_God

>Major Chaos Gods

>Tzeentch: The Architect of Fate, who uses powerful sorceries to alter the future. He was once the greatest of the Chaos Gods and is potentially the most powerful. He's the God of Change, who endlessly plots and schemes, in a cosmic-wide game of subterfuge and manipulation. He became fully sentient in the 2nd millenium, due to mankind during Earth's medieval period. Tzeentch listens to the hopes of all mortals, feeding on their need and desire for change.

“1.2.3.4.in-addr.arpa.” would work, no?

> You physically can’t put an IP address into an MX DNS record

Per TFA,

> some mail servers do configure an IP address. Many mail servers are lenient when it comes to this misconfiguration and will deliver mails nevertheless

I.E. people can and do put IP addresses into these things. And any actual example is a complete rebuttal of claims of impossibility.

Standards don't have any cosmic significance. If people use a thing in a manner, then it's also that thing.

I think the point here is that the "lenient" behaviour actually is a lot more complex than one would expect - a compliant mail server would need some special logic to detect hostnames that kinda look like IP addresses and handle them in a special way - without this behaviour being in any way standardized.

E.g., the lenient server would have to treat the value "10.0.0.254" like an IP address but "10.0.0.256" like a hostname that requires DNS resolution.

This is a solved problem and not very complicated. For starters the last DNS label of a hostname cannot be all numbers: https://tools.ietf.org/html/rfc1123#page-13

But name stored in MX doesn't have to be FQDN. I can set up A record with real server IP at 1.2.3.4.example.com, then set 1.2.3.4 in MX for example.com, and it would be perfectly standard compliant record, while it probably would be misinterpreted by servers trying to be "lenient".

> But name stored in MX doesn't have to be FQDN.

On the contrary, an MX record can only contain a FQDN. If you type “foo” as your target in an MX record in your domain “yourdomain.example”, what actually gets stored in the MX record is “foo.yourdomain.example.”; a perfectly normal FQDN.

That doesn't sound right. A "tcpdump -n -s0 -x -X port 53" shows that the server simply returns "outlook-com.olc.protection", not a FQDN, for "dig mx outlook.com".

MX records are one of the few records that can contain name compression. I think you'll find you're looking at the labels for "outlook-com.olc.protection" followed by a pointer to "outlook.com." earlier in the message.

EDIT: Yep, wireshark shows the byte sequence c00c following "protection". c00c is a compression pointer to "outlook.com." in the question section of the message.

I cannot reproduce this behavior; I see the complete FQDN in the reply when I run the commands you specify.

I do, however, note that, in the -X part of the tcpdump output, the periods between labels are not really ASCII period characters, but simply displayed that way by tcpdump; these are in fact byte counts for the label lengths, which, since all the individual labels are below 32 characters in length, makes these bytes ASCII non-printing control characters, which tcpdump then displays as periods.

In another comment, eknshow writes¹ that DNS labels can either be specified inline with a byte count (as described above), or can be a pointer to another set of bytes. Could this be what you are seeing? That is, could the domain part be present, but specified as pointers and therefore not be obvious in the tcpdump output? One would have to carefully examine the raw bytes to be sure.

1. https://news.ycombinator.com/item?id=26217913

Thanks for the correction. Curious if these misconfigured MXs store 1.2.3.4. or 1.2.3.4.example.com.

Fair point. I just tested using tcpdump and the IP address in the response doesn't in fact end with a dot.

"Standards don't have any cosmic significance." - true but then I suspect you would get a right shitty on if your preferred IP stack didn't generally behave in the same way as mine and you lost comms with the world.

This discusses some consequences of avoiding standards: https://tools.ietf.org/id/draft-thomson-postel-was-wrong-03....

Of course your DNS server can return whatever you fancy in response to a request. If you want to return an MX record that looks like an IP address then go ahead. I think the old restriction on a hostname being greater than two chars and no leading int has gone away. If a MTA is happy with the result then fine.

However, anti-spam systems will frown on things like that and will probably tut a bit. ... and drop your mail on the floor. You can do what you like - you could call these records "Liberty MX" but I will still drop your mail because I can't be arsed to analyse your intent. You don't follow email standards - DROP!

No, they do not. They put a domain name whose human-readable form just happens to resemble the human-readable form of an IP address into the record. An actual machine-readable IP address, and the actual machine-readable domain names that go into MX resource records, are quite different things, and one simply cannot put one into the other. This has been pointed out several times in this discussion.

It has been further pointed out that even if dealing with human-readable forms in (say) BIND's "zone" format files, the human-readable form of an IP address doesn't actually get translated into a 4-label domain name, because it isn't a fully-qualified human-readble domain name. Human-readable IP addresses don't end in dots, and if one has typed in a human-readable IP address into a "zone" format file, one actually has not made the relevant misconfiguration; and conversely if one has made the misconfiguration (in a way that will actually work with dnscache et al.) what one has typed is not actually a vanilla human-readable IP address.

Ironically, neither the headlined article nor many in this discussion have noted that the SMTP standard's algorithm for loop prevention breaks when one does this in MX resource records for the same reason that it breaks when one uses alias domain names via CNAME records rather than the canonical domain names. SMTP Relay servers do not match the domain names in the data of MX resource records against (their own) IP addresses because ... well ... those domain names are not IP addresses.

Reply on news.ycombinator.com