On Sat, Oct 19, 2024 at 03:10:05PM +0200, Ted Lemon wrote:
> 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.
The additional addresses won't show up if the CNAME crosses zone
boundaries. If both the CNAME source and the target are in the same
zone, they may, but note that many nameservers don't populate the
additional section with related unsolicited data, and many resolvers
don't propagate such data to their clients.
So optimisation for additional data is not a compelling argument. In
any case, if email to the destination domain is at all frequent, the
answer (or a chain of answers) will be cached long enough to ammortise
most of the initial lookup cost, and a even a few hundred milliseconds
of extra email delivery latency are not a big deal.
> > 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.
As I explained in my longer response to three previous posts, DNAME is
not material here.
--
Viktor.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
