[dns-operations] Cloudflare considered harmful?

Brian Somers bsomers at opendns.com
Thu Apr 16 01:19:50 UTC 2020


On Apr 10, 2020, at 1:05 PM, Vicky Shrestha <vicky at 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


More information about the dns-operations mailing list