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 <[email protected]>, 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 <[email protected]>
> wrote:
>
> > John C Klensin <[email protected]> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
