[dns-operations] Cloudflare considered harmful?

[Vicky Shrestha]

Hi,

On Apr 16, 20 11:47, Vicky Shrestha wrote:
> Hi,
> 
> On Apr 15, 20 18:19, Brian Somers wrote:
> > 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.
> 
> The fix is being rolled out to our canary POPs and it should be deployed in
> rest of the network next week.

The fix has been deployed and this issue should now be resolved. Can you
confirm?

Thanks again for bringing this to our attention.
> 
> > 
> > Cheers.
> > 
> > —
> > Brian


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 528 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20200420/f3b130bd/attachment.sig>