> On 3 Apr 2020, at 06:30, Brian Somers <[email protected]> wrote: > > 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?
Yes, it breaks all resolvers. The fundamental problem is that many nameservers allow "CNAME and other data" to be loaded despite RFC1034 saying: The domain system provides such a feature using the canonical name (CNAME) RR. A CNAME RR identifies its owner name as an alias, and specifies the corresponding canonical name in the RDATA section of the RR. If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different. This rule also insures that a cached CNAME can be used without checking with an authoritative server for other RR types. This means there is no push back on operators doing the wrong thing with those servers. BIND has refused to load zones with CNAME and other data for the last 20+ years so, yes, it can be done. It just requires DNS vendors to have the intestinal fortitude to stop loading such zones. I hope that when HTTPSSVC is finalised DNS vendors which allow CNAME and other data to load will stop doing so, if not before then. HTTPSSVC, in most cases, provides a operational replacement for why the CNAME record has been installed. Mark > Thanks for any input. > > — > Brian > _______________________________________________ > dns-operations mailing list > [email protected] > https://lists.dns-oarc.net/mailman/listinfo/dns-operations -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
