Op vr 18 okt 2024 om 23:21 schreef John Levine <johnl@xxxxxxxxx>
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.
RFC2181 says the reason not to do this is that it would mean an extra found trip because the CNAME and its resolution would not show up in the additional section. I don’t know if that’s actually true, but I took it at face value. Seems implementation-specific and possibly ancient history, for sure.
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.
This is a good reason to punt to some existing document if possible. But yeah, it may make sense to mention this.
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.
I actually ran into this in my review and chased it all the way down. I had started a comment, but by the time I’d chased it down, I was satisfied. I think the document is fine with respect to this question.
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
