When good recursives go bad: why does 1.1.1.1 not give the same answer as 8.8.8.8?

Anyone got a suggestion for this? Why would Cloudflare DNS be unable to resolve the SOA record of a given domain if Google DNS can? 9.9.9.9 can also resolve this without trouble. Its not a one-of either, it repeatedly refuses to answer, but does for other domains. Hmmm. Is this a disconnect between Cloudflare and .ca root? A caching issue in Cloudflare? Hmm. If we “$ dig @d.root-servers.net -t SOA 100years.ca” and then check each of the roots (c.ca-servers.ca etc), they all work from my house… Hmm.

$ dig @1.1.1.1 -t soa 100years.ca
 ...
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63615
 ...

$ dig @8.8.8.8 -t soa 100years.ca
 ...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 196

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;100years.ca.			IN	SOA

;; ANSWER SECTION:
100years.ca.		10799	IN	SOA	ns1.fastpark.net. hostmaster.100years.ca. 1545692000 28800 7200 604800 86400

Posted

in

by

db

Tags:

Comments

2 Responses to “When good recursives go bad: why does 1.1.1.1 not give the same answer as 8.8.8.8?”

  1. crimeflare

    C:\TEMP>nslookup 100years.ca
    Server: google-public-dns-a.google.com
    Address: 8.8.8.8

    Non-authoritative answer:
    Name: 100years.ca
    Address: 185.53.178.7

    C:\TEMP>nslookup 100years.ca 1.1.1.1
    Server: one.one.one.one
    Address: 1.1.1.1

    DNS request timed out.
    timeout was 2 seconds.
    DNS request timed out.
    timeout was 2 seconds.
    *** Request to one.one.one.one timed-out

    Reply
  2. Kevin Nisbet

    Oddly enough, it looks like it came alive while I was trying to test it out. I tried to check other regions to see if I accidentally populated a cache entry, but the other regions appear to be working as well.

    I see a couple of possibilities:
    1. Someone just managed to find and fix the error
    2. ns1/ns2.fastpark.net have a sort of IDS/IPS that may have blocked cloudflares DNS, or other configuration that was specific to cloudflare (like a zones setup). It looks like fastpark is hosted on ec2 though.
    3. There is a subtle bug in the cloudflare DNS resolver, when no glue record is returned and the record isn’t cached. When querying 100years.ca, the .ca nameserver returns ns1/ns2.fastpark.net. as the authority, without any additional (glue records) because .net is cross domain from .ca, which should cause the cloudflare resolver to try and find/load ns1/ns2 from .net, but may not have. I chased a problem similar to this in GSMA DNS several years ago, but GSMA DNS is very fragile and don’t believe this cenario is very likely.
    4. ns1/ns2.fastpark are somewhat slow to cloudflare. I got a sort of interesting result when I purged the cloudflare cache, where it took 3 seconds to refresh. It’s possible that quite often this times out for some reason, but just got lucky and it’s currently resolving under the timeout.

    Anyways, I would suspect cloudflare/fastpark connectivity or configuration / ahead of a problem with cloudflare/ca, but since it seems to be working it’s somewhere difficult to prove.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *