Cloudflare 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 @
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 @
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 zone with these NS records:      172800  IN      NS      172800  IN      NS      172800  IN      NS      172800  IN      NS

According to that zone, does not exist.

You need to put the delegation within that zone.

After that, remove the delegation from the 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 and pointing to different zones.

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


The issue is that, if delegates to &c, that means Cloudflare shouldn’t know anything about what’s in, whether it’s or or or anything else.*

But the zone is inconsistent. It says, " is over here" and also says " is over there at &c" even though it ought not to know that.

Second, the itself doesn’t contain a delegation for the zone, even though it needs to. If you ask it about, it says it doesn’t exist. implements QNAME minimisation. (With limits, I think.) It’s guaranteed to send queries to Cloudflare that will result in it learning about the zone cut. With the missing delegation, it’s guaranteed to ‘learn’ that doesn’t exist. Plus, it caches very well. doesn’t implement QNAME minimisation, so it might send queries to Cloudflare’s zone or to Route 53’s 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 caches by sending a dozen or so queries for Then 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 typos.