[Last-Call] Re: [Emailcore] Re: Re: Dnsdir last call review of draft-ietf-emailcore-rfc5321bis-31

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



It appears that Viktor Dukhovni  <emailcore@xxxxxxxx> said:
>Can you suggest text that manages to both discourage publication of
>CNAME-valued MX "exchange" names, and slightly nudges implementors to
>tolerate these, based on today ~1% of domains being in violation of this
>advice. 

I went back and looked at the documents that forbid CNAMEs, and while I am not
sure what the motivation was then, I am quite sure that whatever it was, it
doesn't matter now 30 years later. Some of the text suggests that the CNAME
extra lookup makes things needlessly slow. Or since CNAME was originally
envisioned as a short-term forward to the real ("canonical") name, you're just
lazy if you don't fix your mail DNS when you update the host name. Or that CNAME
support used to be buggy -- the DNS code in qmail which dates from 1998 had
special case CNAME code to work around a bug in widely used versions of BIND in
the 1990s.

These days if you do any sort of DNS lookup, your DNS library will follow the
CNAMEs for you. If you want to forbid CNAMEs, the application has to add special
checks to notice the CNAMEs and object to them.

Hence in section 5.1. I would say that for maximum compatibility with earlier
versions of this standard, recipient mail systems MUST NOT use CNAMEs to refer
to MX records or the A or AAAA records that an MX points to. Nonetheless,
sending mail systems SHOULD resolve CNAMEs in those contexts the same way that
they do everywhere else. This is deliberately different from what the current
text says. The SHOULD is so that the existing behavior remains conformant.

Section 2.3.5 says that EHLO can't be a CNAME.  I don't feel as strongly but I
see no reason not to make the same change.

Bonus question: the current text says nothing about DNAME.  Well?  Same thing,
the library will resolve it unless you tell it not to so we might as well allow it.

R's,
John

PS: In answer to the question how many levels of CNAME to allow, the only answer
is whatever your DNS library does. The dnsop WG has declined to set specific limits
on CNAME or DNAME or any of the many other ways you can make long chains of DNS
lookups, and we sure aren't going there either.

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux