The target us a hostname (RFC 1035). 3.3.9. MX RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PREFERENCE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / EXCHANGE / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: PREFERENCE A 16 bit integer which specifies the preference given to this RR among others at the same owner. Lower values are preferred. EXCHANGE A <domain-name> which specifies a host willing to act as a mail exchange for the owner name. In message <d6cbb305b5bc2818e7b34...@jck-hp8200.jck.com>, John C Klensin writes : > (Warning to DNSOP and IESG -- this response is going to descend > quickly into SMTP esoterica and is probably safe to ignore from > a DNS perspective) > > --On Friday, July 18, 2014 22:39 +0100 Tony Finch <d...@dotat.at> > wrote: > > > John C Klensin <john-i...@jck.com> wrote: > > > >> > MX target names should obey the LDH host name rules. > >> > >> I completely agree, but SMTP imposes no such requirement. > > > > RFC 974 specifies that the target of an MX record is a host > > name. > > And so? RFC 2821 obsoleted 974. As far as I can tell, it says > nothing at all about the DATA field in an MX record, leaving > pulling that information out and looking it up in the DNS to be > inferred from context and a parenthetical comment "(perhaps > taken from the preferred MX record)". It does use the term > "host addresses" and "destination host", but in a too-informal > context to assume that people would infer "host name" (aside: > whatever that means) in the DNS sense. After 14+ years, I no > longer remember and cannot reconstruct whether that was a DRUMS > screwup or mine although the WG is ultimately responsible for > not reviewing carefully enough. > > When RFC 5321 was done, we obviously knew there was a problem > with the 2821 text because its text improves on the situation. > The pre-5321 change log doesn't say much that sheds light on the > change, other than saying that the description of MX handing > was changed in -10 (one of several post-Last-Call versions). > The relevant section is more clear and it does explicitly say > "the data field of that response MUST contain a domain name. > That domain name, when queried, MUST return at least one address > record (e.g., A or AAAA RR)". But that is it: "domain name". > One can read that as an invocation of the discussion in Section > 2.3.5 but that isn't the only possible reading. The section > invokes 1035 and "a sequence of letters, digits, and hyphens > drawn from the ASCII character set." The following sentence > reads "Domain names are used as names of hosts and of other > entities in the domain name hierarchy." so, while 2.3.5 (if one > believes that the text in 5.1 invokes it) requires LDH, it does > not require a "host name". If one doesn't believe that 2.3,5 > is invoked, then a domain name is presumably just an FQDN > conforming to 1034/1035 as interpreted by 2181). There is, > fwiw, some additional test in 2.3.5 that further muddies the > waters. > > That is definitely not a good example of clarity or precision. > Mea culpa, with or without comments about quality of review. I > have tightened things up in the 5321bis editing copy (yes, there > is such a thing). > > >... > >> Does that imply that this spec should contain a warning that > >> loading one of these "null MX" records may require a > >> configuration change in one's nameserver? > > > > No, because "." doesn't violate LDH syntax. (What admin GUIs > > do is another matter...) > > Those admin GUIs or text input converters were what I was > concerned about (should have said "nameserver configuration > interface" or words to that effect). Your call (and John L.'s). > > john > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop