[dns-operations] Cloudflare considered harmful?
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:
> 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 for following up on this Vicky. Any idea on an ETA? It’d be great to
close out these issues on our end.
More information about the dns-operations