[dns-operations] Resolvers, DNSKEY queries and zone apex CNAMEs?

[Viktor Dukhovni]

I'm seeing what I think is undesirable behaviour from (at least) half of
the usual public resolvers (perhaps I've not been persistent enough to
elicit the unexpected response from the rest).  Also it seems (but not
easy to reproduce), sometimes from my own unbound 1.9.6 resolver.

This results from the kludge that is zone-apex CNAMEs, which resolvers
generally try to accept, but then it seems sometimes forward undesirable
answers downstream.

For example, I've sent multiple test (AD and DO bits set) DNSKEY queries
for "hypotheeklead.nl" to the Cloudflare, Google, Quad9 and Verisign
public DNS servers, with the following results:

  * 1.0.0.1 / 1.1.1.1 - Cloudflare, 64.6.64.6 / 64.6.65.6 - Verisign

    - Appear to consistently return the DNSKEY and AD=1:

        hypotheeklead.nl. IN DNSKEY 257 3 13 <key> ; NoError AD=1
        hypotheeklead.nl. IN RRSIG DNSKEY 13 2 <...>; NoError AD=1

  * 8.8.4.4 / 8.8.8.8 - Google, 9.9.9.10 / 149.112.112.10 - Quad9

    - Sometimes return the DNSKEY and AD=1:

        hypotheeklead.nl. IN DNSKEY 257 3 13 <...> ; NoError AD=1
        hypotheeklead.nl. IN RRSIG DNSKEY 13 2 <...> ; NoError AD=1

    - Other times return a zone apex CNAME and AD=0 (target is unsigned):

        hypotheeklead.nl. IN CNAME prd.hypotheeklead.theinvited.nl. ; NoError AD=0
        hypotheeklead.nl. IN RRSIG CNAME 13 2 <...> ; NoError AD=0
        prd.hypotheeklead.theinvited.nl. IN CNAME saturn.theinvited.nl. ; NoError AD=0
        theinvited.nl. IN SOA ns1.caveo.nl. hostmaster.caveo.nl. <...> ; AD=0

When these resolvers are forwarders for downstream validating (iterative
or stub) resolvers the CNAME response is a problem.  It can't be
validated if the downsteam resolver does not yet have the DNSKEYs it
asked for!

Even if the CNAME enters an iterative resolver's data cache, the DNSKEY
should be served from in preference to any CNAME learned at some point
later, i.e. at a signed zone apex, the CNAME should be ignored when
responding to DNSKEY queries.

Perhaps this is something to also (instead?) raise on dnsops?  Given
at multiple running implementations running into (IMHO) trouble
here, I am guessing that dns-operations is a good starting point
to bring this to the attention of some of the right folks.

-- 
    Viktor.