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
signature.asc
Description: PGP signature
_______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
