My DNS Server isn't getting resolved by Cloudflare

Hello,

I’ve been running my own DNS Server using bind for 10+ years. I’ve been able to resolve my domain, schnitter.net, without issue using any and all DNS services (Google, Cloudflare, OpenDNS, Quad9, etc).

At some point after August of this year, Cloudflare stopped resolving my domain. I can still resolve my domain using every other DNS service out there. Cloudflare is the only DNS out there that can’t resolve my domain. I haven’t made changes to my DNS or my DNS config in years, so I can’t image the problem being on my end.

dig @8.8.8.8 schnitter.net
resolves fine

dig @1.1.1.1 schnitter.net

; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24540
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;schnitter.net. IN A

;; Query time: 4034 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Nov 17 20:56:55 2022
;; MSG SIZE rcvd: 31

Is anyone aware of any changes Cloudflare implemented after August?

Any help or insight would be appreciated.

Thank You.

It looks like IntoDNS is having trouble with your DNS as well:

https://intodns.com/schnitter.net

Thanks this is interesting…
The items that IntroDNS are flagging don’t make any sense, half of the items noted have been verified to be correct by other DNS checkers. Other DNS checker tools are reporting everything is mostly ok. Any idea what would cause one DNS checker to report one thing and another something completely different?

For example:
NS RR exists and resolves OK
MX RR exists and resolves OK
WWW RR exists and resolves OK
SOA RR exists and and resolves OK

If you perform a dig on any of these, you will get a valid result (except if you use Cloudflare as the DNS resolver)

I’m reviewing my DNS config as well. Some minor improvements, but nothing so far that should cause name resolution to out right fail.

Is there anything that makes Cloudflare unique from a name resolution standpoint?

Thanks.

Your DNSSEC is a bit wonky. Cloudflare may be picky about that.

1 Like

By wonky, are you referring to the key strength?

https://dnsviz.net/d/schnitter.net/dnssec/

Algorithm 7 - RSASHA1-NSEC3-SHA1

While not the strongest algorithm, I would still hope it could resolve, given the number of site out there that do not even have DNSSEC turned on. I’ll work on regenerating my keys using a stronger algorithm.

What’s weird is that I can see Cloudflare talking to my DNS server. Same inbound communications as Google, OpenDNS, Quad9, etc. No errors on my end. Everyone else responds with a result query, but no response from Cloudflare. Weird.

Thanks,

I was referring to the dual DS records. I’m pretty sure that’s legal, as you do have a good one, but maybe the #7 isn’t helping, either.

There’s a reason DNS has such a bad reputation (“It’s always DNS”), so Cloudflare’s being finicky about something. @milk is super-sharp on DNS and might know what’s up.

RFC’s, building the grounds for Internet standards, namely RFC2182, which is also known as BCP (Best Current Practice) #16 from July 1997 dictates the following:

  1. Recommended 3 - 7 name servers.
  2. Name servers should be located carefully, to avoid a single point of failure (e.g. having 7 in one single city isn’t sufficient).
  3. At least one of the total amount of name servers must be topologically separate from the others (e.g. different ISP’s).
3.1. Selecting Secondary Servers

   When selecting secondary servers, attention should be given to the
   various likely failure modes.  Servers should be placed so that it is
   likely that at least one server will be available to all significant
   parts of the Internet, for any likely failure.

   Consequently, placing all servers at the local site, while easy to
   arrange, and easy to manage, is not a good policy.  Should a single
   link fail, or there be a site, or perhaps even building, or room,
   power failure, such a configuration can lead to all servers being
   disconnected from the Internet.

   Secondary servers must be placed at both topologically and
   geographically dispersed locations on the Internet, to minimise the
   likelihood of a single failure disabling all of them.

and

5. How many secondaries?

   The DNS specification and domain name registration rules require at
   least two servers for every zone.  That is, usually, the primary and
   one secondary.  While two, carefully placed, are often sufficient,
   occasions where two are insufficient are frequent enough that we
   advise the use of more than two listed servers.  Various problems can
   cause a server to be unavailable for extended periods - during such a
   period, a zone with only two listed servers is actually running with
   just one.  Since any server may occasionally be unavailable, for all
   kinds of reasons, this zone is likely, at times, to have no
   functional servers at all.

   [...]

   It is recommended that three servers be provided for most
   organisation level zones, with at least one which must be well
   removed from the others.  For zones where even higher reliability is
   required, four, or even five, servers may be desirable.  Two, or
   occasionally three of five, would be at the local site, with the
   others not geographically or topologically close to the site, or each
   other.

When I’m looking at your domain, I see not just one of them, but all three being violated:

$ dig NS schnitter.net @a.gtld-servers.net

; <<>> DiG 9.16.27-Debian <<>> NS schnitter.net @a.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37106
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;schnitter.net.                 IN      NS

;; AUTHORITY SECTION:
schnitter.net.          172800  IN      NS      ns.schnitter.net.

;; ADDITIONAL SECTION:
ns.schnitter.net.       172800  IN      A       [...]

;; Query time: 3 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Sat Nov 19 03:53:28 CET 2022
;; MSG SIZE  rcvd: 75

and, after a bit of waiting, while querying Cloudflare:

$ dig schnitter.net @1.1.1.1

; <<>> DiG 9.16.27-Debian <<>> schnitter.net @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10878
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for schnitter.net.)
; EDE: 22 (No Reachable Authority): (at delegation schnitter.net.)
;; QUESTION SECTION:
;schnitter.net.                 IN      A

;; Query time: 4011 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sat Nov 19 03:53:41 CET 2022
;; MSG SIZE  rcvd: 129

EDE: 22 (No Reachable Authority) points towards the fact that Cloudflare cannot properly reach any of the name servers for schnitter.net delegation, if there had been 3 or even 7 name servers, this one indicates none of them could provide Cloudflare with the desired response.

Could be anything from firewall issues, routing issues, or similar to that.

EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for schnitter.net.) claims that there is no DNSKEY record, which isn’t true, - however, given the above where Cloudflare cannot reach the very lonely name server you have, it obviously cannot find the DNSKEY record either.

Although I obviously cannot make decisions for you, I would strongly recommend you to update your current set up to follow RFC2182 / BCP-16 100%.

Going that route, will likely fix the issues anywhere from nearly instantaneous to 48 hours after the (successful) change.

With both Cloudflare and intodns.com being unable to reach you, … that recommendation would be my two cents.

Is Cloudflare allowed through your firewall? When querying myself I am able to get a response:

dig schnitter.net @ns.schnitter.net +short
184.54.149.172

But through a Cloudflare IP (via WARP) I am unable to reach your server:

dig schnitter.net @ns.schnitter.net +short
;; communications error to 184.54.149.172#53: timed out
;; communications error to 184.54.149.172#53: timed out
;; communications error to 184.54.149.172#53: timed out

; <<>> DiG 9.18.8 <<>> schnitter.net @ns.schnitter.net +short
;; global options: +cmd
;; no servers could be reached

Ping works from WARP to 184.54.149.172, but HTTP or DNS requests seem to get dropped.

2 Likes

Hello,

I found it!!

First, thank you for your insight and help. The fact you were unable to ping my DNS and web site from Cloudflare’s location is what tipped me off.

It just so happened that I was in contact with my ISP asking them what if anything had changed on their end. I was getting a nice tour of this new customer dashboard they added for extra security, when I noticed a GEOIP blocking option that had been defaulted to on. After I read your comment about not being able to ping my site from Cloudflare’s location, I went into the GEOIP blocking section and discovered that almost every location was blocked. I disabled my ISP’s GEOIP blocking for my account, and everything started to resolve without issue.

I have since gone back and disabled all the security options in my customer dashboard since they are all redundant to what I’m already doing. (My ISP recently merged with another ISP and they are making “improvements”) I was already looking at switching ISP’s so this is only going to accelerate the process.

I’m going to look at what GEOIP ID 1.1.1.1 is associated with and make sure it is whitelisted on my end too.

Thank You.

1 Like

Thank you for your help and adding “@milk” to this conversation. The root cause turned out to be a GEOIP feature my ISP added a couple of months ago. The GEOIP was blocking 1.1.1.1. I have since disabled the GEOIP feature and everything is now working.

Thanks Again!

2 Likes

Hello,

Thank you for your insight. I’m in the process of remediating the issue with the number of name servers I have. The root cause was a GEOIP filter my ISP had turned on, causing the Cloudflare IPs to get blocked. I have turned that feature off, and everything is working as expected.

Thank you.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.