Subject: Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

From: Brian Dickson <[email-masked]>
Date: Thu, 5 Jul 2018 09:30:13 -0700

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