Cloudflare 1.1.1.1 DNS resolver serving different records than Google DNS

Hi all,

Just to preface this, we updated our DNS records around 36 hours ago, as I originally thought it could be some sort of caching issue and hence we waited for some of our TTLs to expire.

When I query using Google DNS: dig -t ns dev.api.playsport.com @8.8.8.8
I get (what I consider to be) the correct NS result (I can’t post the results as I apparently have a link limit for my account).

When I query using Cloudflare’s DNS: dig -t ns dev.api.playsport.com @1.1.1.1
I simply get the SOA record for api. playsport. com

This is leading to obvious issues with our dev environment. Does anybody know if this is an issue with Cloudflare’s DNS issue, or a configuration issue our end?

There is an api.playsport.com. zone with these NS records:

api.playsport.com.      172800  IN      NS      ns-834.awsdns-40.net.
api.playsport.com.      172800  IN      NS      ns-1353.awsdns-41.org.
api.playsport.com.      172800  IN      NS      ns-1658.awsdns-15.co.uk.
api.playsport.com.      172800  IN      NS      ns-26.awsdns-03.com.

According to that zone, dev.api.playsport.com. does not exist.

You need to put the dev.api.playsport.com. delegation within that zone.

After that, remove the dev.api.playsport.com. delegation from the playsport.com. zone, since it shouldn’t really be there anyway.

1 Like

We have separate zones for dev.api.* and api.*, since they’re separate environments in different AWS accounts.

Within Cloudflare’s DNS, we have NS records for api.playsport.com and dev.api.playsport.com pointing to different zones.

Yes. That’s incorrect. :sweat_drops: The two delegations are in conflict with each other, and the api.playsport.com zone is missing the dev.api.playsport.com delegation.

Edit:

The issue is that, if playsport.com delegates api.playsport.com to ns-26.awsdns-03.com &c, that means Cloudflare shouldn’t know anything about what’s in api.playsport.com, whether it’s foo.api.playsport.com or bar.api.playsport.com or dev.api.playsport.com or anything else.*

But the playsport.com zone is inconsistent. It says, "api.playsport.com is over here" and also says "dev.api.playsport.com is over there at ns-168.awsdns-21.com &c" even though it ought not to know that.

Second, the api.playsport.com itself doesn’t contain a delegation for the dev.api.playsport.com zone, even though it needs to. If you ask it about dev.api.playsport.com, it says it doesn’t exist.

1.1.1.1 implements QNAME minimisation. (With limits, I think.) It’s guaranteed to send queries to Cloudflare that will result in it learning about the api.playsport.com zone cut. With the missing delegation, it’s guaranteed to ‘learn’ that dev.api.playsport.com doesn’t exist. Plus, it caches very well.

8.8.8.8 doesn’t implement QNAME minimisation, so it might send dev.api.playsport.com queries to Cloudflare’s playsport.com zone or to Route 53’s api.playsport.com zone depending on what other queries it has recently received and what it already has cached.

You could probably poison (as it were) your local 8.8.8.8 caches by sending a dozen or so queries for api.playsport.com. Then dev.api.playsport.com would start ‘failing’ in the same way it does with Cloudflare (except where older cached records keep it working).

* With some exceptions for glue, which isn’t involved here.

Edit again: Rewrite a bit. And fix playsports.com typos.

3 Likes