Hi Petr
Apologies for the delayed reply.
On Tue, Jun 19, 2018 at 03:18:22PM +0200, Petr Špaček wrote:
> Hello dnsop,
>
> beware, material in this e-mail might cause your head to explode :-)
>
> This proposal is based on following observations:
> - It seems that DNS protocol police lost battle about CNAME at apex,
> is is deployed on the Internet.
> - Major DNS resolvers like BIND, Unbound, PowerDNS Recursor, dnsmasq
> already have code to cope with the "impossible" case of CNAME at the
> apex and deal with it in ways which do not break stuff on resolver
> side.
> - Authoritative servers of vendors named above refuse to serve CNAME at
> apex.
> - There are CDNs etc. which allow users to create CNAME at apex
> no matter what the standards and "normal" servers say and do.
> (We have found out this because Knot Resolver is missing hacks for CNAME
> at apex and users complain that "it works with every other resolver".)
>
>
> Take a deep breath!
>
>
> Given that resolver side somehow works already ...
> could we standardize this obvious violation of RFC 1035?
>
> It is very clear violation of the standard, but almost everyone found
> his way around it using different hacks. These hacks are not going away
> because all the CDNs just don't care about standards so we will have
> to maintain this code no matter what a great solution we will invent for
> future. I.e. adding ANAME will just increase complexity because CNAME at
> apex will be there for a long time (if not forever).
>
> I personally do not like this but it seems better to think though
> corner cases in code we already have in production (i.e. think through
> current hacks for CNAME at apex) instead of inventing new things like ANAME
> (or whatever else).
>
> Opinions? Tomatoes? Can it work? If not, why not?
To me it seems it can work, and it sounds like a good idea. To relax DNS
protocol for CNAME to co-exist with other RR types, we'd need resolver
support, authoritive support and a time when it is practially usable.
----
Adding resolver support (to resolvers that don't have it, i.e., vs. RFC
1035) does not appear to break current DNS, i.e., it can be proposed
now.
1. When a resolver looks up a RR type in cache, and finds any positive
type match, it serves it.
2. If it does not find a positive type match, but finds a CNAME, it
looks for a negative cache entry for that RR type.
2.a. If a negative cache entry is found (or if it can synthesize one),
it returns/follows the CNAME chain.
2.b. If no negative cache entry is found (and it cannot synthesize one),
it starts a fetch for that type from upstream.
2.b.i. If the fetch returns a CNAME or NODATA, it means that the type
does not co-exist with CNAME in that node in the auth zone. The resolver
adds a negative cache entry for the type for the TTL of the returned
CNAME (or from SOA fields) to the cache, and returns/follows the CNAME
chain.
2.b.ii. If the fetch returns the type, it means that the type may
co-exist with the CNAME. The resolver adds a positive cache entry for
the type and returns the fetched answer.
2.b.iii. If the fetch returns NXDOMAIN, it overwrites the cache for that
node with a negative cache entry.
----
Adding authoriative support would mean relaxing checks and allowing
CNAME to co-exist with other types except non-apex NS (parent of zone
cut), and perhaps allow CNAME and DNAME to co-exist too.
For operators to be able to use it, they would need resolver support to
be available everywhere. I guess nothing stops a draft requiring
resolvers to implement support for it now.
So +1.
Mukund
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
