[dns-operations] Cloudflare considered harmful?

[Brian Somers]

Hi,

I saw an example of some pretty poor nameserver behaviour recently and it has now turned up again for a different domain, both hosted by cloudflare.  It seems to be related to https://blog.cloudflare.com/zone-apex-naked-domain-root-domain-cname-supp/.  I thought I’d bring it up here to see if I could get any comments.

The issue is with CNAMEs at a zone apex.  While I could certainly add some “look under the CNAME” code to our resolvers, that doesn’t seem to be compliant with any RFCs… and it won’t be able to defend against this “sometimes CNAME at a zone apex” behaviour.

The issue - with an unsigned zone (well, they sign RRsets but have no DS connection in the parent):

        $ dig +short ns dev
        ns-tld1.charlestonroadregistry.com.
        ns-tld2.charlestonroadregistry.com.
        ns-tld3.charlestonroadregistry.com.
        ns-tld4.charlestonroadregistry.com.
        ns-tld5.charlestonroadregistry.com.

        $ for type in NS DS; do echo $type: $(dig +noall +answer +authority +nocrypt $type liferay.dev @ns-tld1.charlestonroadregistry.com); done
        NS: liferay.dev. 10800 IN NS jim.ns.cloudflare.com. liferay.dev. 10800 IN NS sofia.ns.cloudflare.com.
        DS: dev. 300 IN SOA ns-tld1.charlestonroadregistry.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300

        $ for type in NS CNAME A TXT SOA; do echo $type: $(dig +noall +answer $type liferay.dev @jim.ns.cloudflare.com); done
        NS: liferay.dev. 86400 IN NS jim.ns.cloudflare.com. liferay.dev. 86400 IN NS sofia.ns.cloudflare.com.
        CNAME:
        A: liferay.dev. 300 IN A 34.95.124.159
        TXT: liferay.dev. 300 IN TXT "v=spf1 -all"
        SOA: liferay.dev. 3600 IN SOA jim.ns.cloudflare.com. dns.cloudflare.com. 2033691112 10000 2400 604800 3600

        $ dig +noall +answer portal.liferay.dev @jim.ns.cloudflare.com
        portal.liferay.dev.     300     IN      CNAME   liferay.dev.
        liferay.dev.            300     IN      CNAME   web-lfrcommunity-prd.lfr.cloud.

Pretty much the same issue with a signed zone:

        $ dig +short ns gov
        d.gov-servers.net.
        a.gov-servers.net.
        b.gov-servers.net.
        c.gov-servers.net.

        $ for type in NS DS; do echo $type: $(dig +noall +answer +authority +nocrypt $type medlineplus.gov @d.gov-servers.net); done
        NS: medlineplus.gov. 86400 IN NS gslb01.nlm.nih.gov. medlineplus.gov. 86400 IN NS gslb03.nlm.nih.gov. medlineplus.gov. 86400 IN NS gslb02.nlm.nih.gov.
        DS: medlineplus.gov. 3600 IN DS 30870 7 1 [omitted] medlineplus.gov. 3600 IN DS 30870 7 2 [omitted]

        $ for type in NS CNAME A TXT SOA; do echo $type: $(dig +noall +answer $type medlineplus.gov @gslb01.nlm.nih.gov); done
        NS: medlineplus.gov. 60 IN NS gslb01.nlm.nih.gov. medlineplus.gov. 60 IN NS gslb03.nlm.nih.gov. medlineplus.gov. 60 IN NS gslb02.nlm.nih.gov.
        CNAME:
        A: medlineplus.gov. 30 IN CNAME medlineplus.awsprod.nlm.nih.gov.
        TXT: medlineplus.gov. 60 IN TXT "v=spf1 include:nih.gov ~all" medlineplus.gov. 60 IN TXT "7ae5d325d5804e5893a3bf186eed3bd6"
        SOA: medlineplus.gov. 60 IN SOA gslb01.nlm.nih.gov. hostmaster.gslb03.nlm.nih.gov. 2020021804 10800 3600 604800 60

How do others deal with this “sometimes a CNAME” behaviour?  Does this break all resolvers?

Thanks for any input.

—
Brian