On 2026-01-16 at 10:32 -0500, John R Levine wrote: > On Fri, 16 Jan 2026, Florian Weimer wrote: > > > It seems to me that if we are going to say anything, we should both say > > > that > > > caches and forwarders have to emit the records in chain order so that > > > badly > > > written stubs won't break, and stubs have to accept records in any order > > > so > > > badly written caches won't break them. > > > > Can stubs just ignore CNAMEs and just extract addresses from A and AAAA > > records found in the answer section? > > My impression is that's pretty common and it's not obvious to me what the > point of the stub following the CNAME chain is. If it doesn't trust the > cache to provide the right results, there are a lot wronger things than > funky CNAMEs and stray A records.
Note that gethostbyname(3), returns the list of alias, so it needs to process the CNAMEs. High-level programs generally don't need them, though, and I can see a point in the stub resolver saying "see, I don't care about any intermediate CNAME, you may just give me the final entries" so it could skip sending them. In that case I would probably implement as Bit 2 of EDNS Flags.¹ But that should be a separate document than the proposed one. On the other hand, we are moving from needing to resolve A and AAAA types to also doing SVCB queries. Which doesn't encourage simplification. ¹ You may wonder why a flag and not an extension, which are generally more robust. But in this case a resolver not supporting this flag would simply return some extra CNAME RR that would be ignored by the resolver, so the presence of that flag would gracefully fall back. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
