Paul Vixie wrote: > Tony Finch wrote: > > Paul Wouters<paul at nohats.ca> wrote: > > I understand, I just disagree this is the right way. I don't see why > this entire problem shouldn't be resolved at the well, resolver level. > > I don't see how that can be deployed in a way that is compatible with > existing software. > > there are now a half dozen x.x.x.x (where x is the same in all four octets) > public anycast resolvers. if they can all be upgraded to handle dnssec or > ECS, they can all be upgraded to handle something like ANAME. > > the "resolver" here is the recursive, not the stub. stubs believe what they > hear, for good or ill. if we need to change what they hear, it's not as > impossible as changing what they understand. > > -- > P Vixie > > > Apologies for a late response to an early part of the thread/discussion.
To paraphrase (hopefully correctly), we should be looking at ways of getting the resolver to possibly just return A records (with appropriate TTL) to stubs, even if the recursive was handed something along the likes of an apex CNAME that it understood, or something that achieves the same effect if the apex CNAME isn't something the resolver understands. I think there is something that can be borrowed from the DNSSEC DNAME stuff, where a DNAME signed response is accompanied by an unsigned CNAME. DNAME-aware resolvers use/cache it, while DNAME-unaware resolvers get the synthesized CNAME which they can cache. DNSSEC required DNAME, which is very helpful -- this ensures the unsigned CNAME isn't breaking validation. The thing to note about DNAME/CNAME, is that there is a performance/scale benefit to having a resolver that understands DNAME. The CNAME hack works, but can require much more work by the resolver (in terms of query to the authoritative). Having DNSSEC-unaware resolver clients is pretty easy, as the resolver can do its own CNAME synthesis. The analogous set-up would be a CNAME2 RR type accompanied by (or replaced by) a corresponding CNAME RR with TTL=0. I think it would preferable to use a bit flag in the EDNS bitfield, where the client can signal CNAME2 awareness, and the server can signal its own support on replies. And I think chaining involving both types (regardless of order of type in an ordered chain) produces correct results/behavior. (In the following, foo2 means foo understands CNAME2, foo means it doesn't) foo -> resolver -> auth2 : auth2 sends CNAME TTL=0, resolver sends (but does not cache) CNAME TTL=0. foo -> resolver2 -> auth2 : auth2 sends CNAME2, resolver caches CNAME2, sends CNAME with TTL=0. foo2 -> resolver2 -> auth2 : auth2 sends CNAME2, resolver caches CNAME2, sends CNAME2 response. CNAME2 would need to have a bitfield of applicable RRTYPEs, similar to NSEC/NSEC3. resolver2 would then be able to synthesize CNAME TTL=0 responses for subsequent queries from foo (or any other non-CNAME2-aware client). Other than performance load due to TTL=0 for popular domains, which admittedly is a big one, I don't think this wouldn't work. This is probably something that would require substantial deployment in the resolver community before it likely gets much use on the auth side. Thoughts? Or discuss in Montreal... Brian
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
