<div dir="ltr"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><p>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.</p><p>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 <a href="http://gslb01.nlm.nih.gov">gslb01.nlm.nih.gov</a> since the NSEC3 records don't have the CNAME, and even if they were present, only breaks negative responses, which has little operational effect.</p><p>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 <a href="https://issuetracker.google.com/122204067#comment3">https://issuetracker.google.com/122204067#comment3</a> as Works as Intended and suggested they file an issue with Cloudflare.</p><p>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.</p><p><br></p><p><br style="color:rgb(0,0,0);font-family:Times;font-size:medium"></p></div></div></div></div></div></div></div>