[lurgburg]

> 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.

[JdeBP]

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.

[gerdesj]

"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!

[xg15]

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.

[abiogenesis]

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

[garaetjjte]

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".

[teddyh]

> 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.

[abiogenesis]

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".

[eknshow]

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.

[teddyh]

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

[garaetjjte]

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

[abiogenesis]

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