[dns-operations] Cloudflare considered harmful?

[Brian Somers]

On Apr 20, 2020, at 10:41 AM, Vicky Shrestha <vicky at geeks.net.np> wrote:
> 
> 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.

Hi Vicky,

Yes, both liferay.dev and limango.pl are now behaving correctly.  Thanks for getting to the bottom of this.

—
Brian