[dns-operations] Cloudflare considered harmful?

Vicky Shrestha vicky at geeks.net.np
Fri Apr 10 20:05:55 UTC 2020


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 528 bytes
Desc: not available
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20200410/f3bbf6a5/attachment.sig>


More information about the dns-operations mailing list