[dns-operations] Cloudflare considered harmful?

[Vicky Shrestha]

Edit:

Thanks for reporting this.

We are looking into it and will update once we know why its happening.

looking at this briefly shows multiple level of CNAMEs across different
zones.

On Thu, Apr 2, 2020 at 17:35 Vicky Shrestha <vicky at geeks.net.np> wrote:

> Hi Brian,
>
> On Thu, Apr 2, 2020 at 12:46 Brian Somers <bsomers at opendns.com> wrote:
>
>> Hi,
>>
>> I saw an example of some pretty poor nameserver behaviour recently and it
>> has now turned up again for a different domain, both hosted by cloudflare.
>> It seems to be related to
>> https://blog.cloudflare.com/zone-apex-naked-domain-root-domain-cname-supp/.
>> I thought I’d bring it up here to see if I could get any comments.
>>
>> The issue is with CNAMEs at a zone apex.  While I could certainly add
>> some “look under the CNAME” code to our resolvers, that doesn’t seem to be
>> compliant with any RFCs… and it won’t be able to defend against this
>> “sometimes CNAME at a zone apex” behaviour.
>>
>> The issue - with an unsigned zone (well, they sign RRsets but have no DS
>> connection in the parent):
>>
>>         $ dig +short ns dev
>>         ns-tld1.charlestonroadregistry.com.
>>         ns-tld2.charlestonroadregistry.com.
>>         ns-tld3.charlestonroadregistry.com.
>>         ns-tld4.charlestonroadregistry.com.
>>         ns-tld5.charlestonroadregistry.com.
>>
>>         $ for type in NS DS; do echo $type: $(dig +noall +answer
>> +authority +nocrypt $type liferay.dev @ns-tld1.charlestonroadregistry.com);
>> done
>>         NS: liferay.dev. 10800 IN NS jim.ns.cloudflare.com. liferay.dev.
>> 10800 IN NS sofia.ns.cloudflare.com.
>>         DS: dev. 300 IN SOA ns-tld1.charlestonroadregistry.com.
>> cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300
>>
>>         $ for type in NS CNAME A TXT SOA; do echo $type: $(dig +noall
>> +answer $type liferay.dev @jim.ns.cloudflare.com); done
>>         NS: liferay.dev. 86400 IN NS jim.ns.cloudflare.com. liferay.dev.
>> 86400 IN NS sofia.ns.cloudflare.com.
>>         CNAME:
>>         A: liferay.dev. 300 IN A 34.95.124.159
>>         TXT: liferay.dev. 300 IN TXT "v=spf1 -all"
>>         SOA: liferay.dev. 3600 IN SOA jim.ns.cloudflare.com.
>> dns.cloudflare.com. 2033691112 10000 2400 604800 3600
>>
>>         $ dig +noall +answer portal.liferay.dev @jim.ns.cloudflare.com
>>         portal.liferay.dev.     300     IN      CNAME   liferay.dev.
>>         liferay.dev.            300     IN      CNAME
>>  web-lfrcommunity-prd.lfr.cloud.
>>
>> Pretty much the same issue with a signed zone:
>>
>>         $ dig +short ns gov
>>         d.gov-servers.net.
>>         a.gov-servers.net.
>>         b.gov-servers.net.
>>         c.gov-servers.net.
>>
>>         $ for type in NS DS; do echo $type: $(dig +noall +answer
>> +authority +nocrypt $type medlineplus.gov @d.gov-servers.net); done
>>         NS: medlineplus.gov. 86400 IN NS gslb01.nlm.nih.gov.
>> medlineplus.gov. 86400 IN NS gslb03.nlm.nih.gov. medlineplus.gov. 86400
>> IN NS gslb02.nlm.nih.gov.
>>         DS: medlineplus.gov. 3600 IN DS 30870 7 1 [omitted]
>> medlineplus.gov. 3600 IN DS 30870 7 2 [omitted]
>>
>>         $ for type in NS CNAME A TXT SOA; do echo $type: $(dig +noall
>> +answer $type medlineplus.gov @gslb01.nlm.nih.gov); done
>>         NS: medlineplus.gov. 60 IN NS gslb01.nlm.nih.gov. medlineplus.gov.
>> 60 IN NS gslb03.nlm.nih.gov. medlineplus.gov. 60 IN NS gslb02.nlm.nih.gov
>> .
>>         CNAME:
>>         A: medlineplus.gov. 30 IN CNAME medlineplus.awsprod.nlm.nih.gov.
>>         TXT: medlineplus.gov. 60 IN TXT "v=spf1 include:nih.gov ~all"
>> medlineplus.gov. 60 IN TXT "7ae5d325d5804e5893a3bf186eed3bd6"
>>         SOA: medlineplus.gov. 60 IN SOA gslb01.nlm.nih.gov.
>> hostmaster.gslb03.nlm.nih.gov. 2020021804 10800 3600 604800 60
>>
>> How do others deal with this “sometimes a CNAME” behaviour?  Does this
>> break all resolvers?
>>
>> Thanks for any input.
>
>
> Thanks for reporting this. We are looking into this and will update when
> we know this is happening.
>
> looking at this briefly shows multiple level of CNAMEs across different
> zones.
>
>
>>
>> —
>> Brian
>> _______________________________________________
>> dns-operations mailing list
>> dns-operations at lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>>
> --
> With Regards,
>
> Vicky Shrestha
>
-- 
With Regards,

Vicky Shrestha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20200402/0cf0f101/attachment.html>