On Apr 10, 2020, at 1:05 PM, Vicky Shrestha <vi...@geeks.net.np> wrote: > > Hi, > > On Apr 09, 20 18:44, Alexander Dupuy wrote: >> FWIW, Google Public DNS doesn't make any attempt to try to check for or >> handle CNAMEs at apex, either in regular lookup or DNSSEC validation. >> There's not much point, since it's not legal zone data, and there is no >> possibility of consistent behavior. >> >> SERVFAILing the NODATA responses for domains with CNAME and other records, >> as Paul Vixie suggested, won't help in the case of the domain served from >> gslb01.nlm.nih.gov since the NSEC3 records don't have the CNAME, and even >> if they were present, only breaks negative responses, which has little >> operational effect. >> >> A case similar to the unsigned Cloudflare one was reported against Google >> Public DNS on our issue tracker over a year ago – I closed it in >> https://issuetracker.google.com/122204067#comment3 as Works as Intended and >> suggested they file an issue with Cloudflare. >> >> My best guess about the problem is that they allow users on paid plans to >> create CNAME at apex (since it is flattened, it works correctly). When >> users drop back to free plans (or free trials expire), the CNAME flattening >> is turned off, and then you see the CNAME at apex configuration. > > We found a bug in how we handle wildcard CNAME record pointing to apex > (with CNAME at apex). Bugfix is being tested and will be pushed out > soon. This is likely a regression that got introduced while cleaning up > the CNAME code. We flatten CNAME at apex for all customers. > > Thanks > > Vicky
Thanks for following up on this Vicky. Any idea on an ETA? It’d be great to close out these issues on our end. Cheers. — Brian _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
