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