Some domains not resolvable through 1.1.1.1

We are using 1.1.1.1 as our central resolver for all dns request for external services in our internal networks. Since a week or so i know about following domains we can not resolve anymore:

almatechnik.ch
datacomnet.ch

Maybe that there are some more i don’t know yet.
With other resolvers the queries get answered.

regards
Thomas

Looks fine from my side.

[[email protected] ~]# dig almatechnik.ch @1.1.1.1

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-16.P2.el7_8.6 <<>> almatechnik.ch @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61449
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;almatechnik.ch.                        IN      A

;; ANSWER SECTION:
almatechnik.ch.         3600    IN      A       212.x.x.x

;; Query time: 351 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Aug 18 14:10:08 +08 2021
;; MSG SIZE  rcvd: 59
[[email protected] ~]# dig datacomnet.ch @1.1.1.1

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-16.P2.el7_8.6 <<>> datacomnet.ch @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33201
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;datacomnet.ch.                 IN      A

;; ANSWER SECTION:
datacomnet.ch.          86400   IN      A       212.x.x.x

;; Query time: 336 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Aug 18 14:12:02 +08 2021
;; MSG SIZE  rcvd: 58

Note: IP addresses were purposely censored.

Hi Thomas,

Looks OK from here as well:

PS C:\Users*******_> Resolve-DnsName datacomnet.ch -Server 1.1.1.1

Name Type TTL Section IPAddress


datacomnet.ch A 86400 Answer 212.40.14.17

PS C:\Users*******_> Resolve-DnsName almatechnik.ch -Server 1.1.1.1

Name Type TTL Section IPAddress


almatechnik.ch A 3600 Answer 212.40.14.8

not for me from my company network :frowning:

[[email protected] ~]$ dig almatechnik.ch @1.1.1.1

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.5 <<>> almatechnik.ch @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 841
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; OPT=15: 00 16 ("…")
;; QUESTION SECTION:
;almatechnik.ch. IN A

;; Query time: 1033 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mi Aug 18 08:39:57 CEST 2021
;; MSG SIZE rcvd: 49

but from my privat system it now works ?!?

[[email protected] ~]$ dig almatechnik.ch mx

; <<>> DiG 9.16.18 <<>> almatechnik.ch mx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40498
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;almatechnik.ch. IN MX

;; ANSWER SECTION:
almatechnik.ch. 86053 IN MX 0 almatechnik-ch.mail.protection.outlook.com.

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mi Aug 18 08:37:16 CEST 2021
;; MSG SIZE rcvd: 101

:frowning:

; <<>> DiG 9.16.18 <<>> datacomnet.ch @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 16490
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 22 (No Reachable Authority)
;; QUESTION SECTION:
;datacomnet.ch. IN A

;; Query time: 2820 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mi Aug 18 08:49:36 CEST 2021
;; MSG SIZE rcvd: 48

working example

; <<>> DiG 9.16.18 <<>> getec.de @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25907
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;getec.de. IN A

;; ANSWER SECTION:
getec.de. 3600 IN A 178.77.118.233

;; Query time: 6 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mi Aug 18 08:53:11 CEST 2021
;; MSG SIZE rcvd: 53

Have the same issue.

If I dig for the zone SOA, A or TXT records, I get SERVFAIL.

I have found if I dig for the DNSKEYs for the zone, they return, then I can query the rest of the zone. So something very screwy with DNSSEC is going on…seems local to Cloudflare.

Have found the problem with a bunch of nic.tld zones as a test:

nic.fox
nic.cloud
nic.afl

a dig for the SOA or A record fails with SERVFAIL…

a dig for the DNSKEYs succeeds and then all other queries for the zone work.

doing a dig +cd also returns a SERVFAIL, so although it seems DNSSEC related, it’s a little confusing that it doesn’t return when not asking for DNSSEC validation

Still looks broken, and only seems to be Cloudflare :frowning:

Would love to know if people elsewhere on the internet can replicate this issue…

[email protected] ~ % dig @1.1.1.1 SOA nic.accountant +nsid 

; <<>> DiG 9.10.6 <<>> @1.1.1.1 SOA nic.accountant +nsid
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 18934
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; NSID: 34 37 6d 36 39 ("47m69")
; OPT=15: 00 06 ("..")
; OPT=15: 00 16 ("..")
;; QUESTION SECTION:
;nic.accountant.			IN	SOA

;; Query time: 179 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Aug 19 10:58:09 AEST 2021
;; MSG SIZE  rcvd: 64

I also get an ANSWER for both.

@thomas.heinemann, can you try dig +short CHAOS TXT id.server @1.1.1.1 to show which datacenter you’re going through?

For me:

[email protected] ~ % dig +short CHAOS TXT id.server @1.1.1.1

“MEL”

@sdayman it’s FRA

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20028
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;id.server. CH TXT

;; ANSWER SECTION:
id.server. 0 CH TXT “FRA”

;; Query time: 6 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Do Aug 19 07:32:42 CEST 2021
;; MSG SIZE rcvd: 43

I’m using a central resolver for all my systems. For the moment I have implemented a work-a-round which uses another public resolver than cloudflare for the known failing domains. I hope the problem will be solved in the coming few days. Otherwise I’m looking for switching all my external queries to the alternate public resolver, cause I don’t know how many other domains are also failing. :frowning:

1 Like

Well currently these 3 other domains have been reported failing on Cloudflare:

oaks.cnr.berkeley.edu
deptapps.coe.berkeley.edu
www.kyb.mpg.de
[email protected] ~ % dig +short oaks.cnr.berkeley.edu @8.8.8.8
nature.berkeley.edu.
169.229.19.202

[email protected] ~ % dig +short oaks.cnr.berkeley.edu @1.1.1.1

[email protected] ~ % dig +short deptapps.coe.berkeley.edu @8.8.8.8
acg-prod-01.ist.berkeley.edu.
128.32.189.121

[email protected] ~ % dig +short deptapps.coe.berkeley.edu @1.1.1.1

[email protected] ~ % dig +short www.kyb.mpg.de @8.8.8.8
npsw-www.mpg.de.
134.76.31.205

[email protected] ~ % dig +short www.kyb.mpg.de @1.1.1.1

But perhaps your company is rewriting all DNS queries from any public resolver to their own and the error is on their network. The domains resolve fine on my end as well (AMS). Did you try any other public resolver (8.8.8.8, 9.9.9.9, 208.67.222.222)?

I am the operator of our central DNS proxy. All systems in our networks are using the central DNS proxy. To solve our issues with non resolvable zones I have decided to use Quad9 (9.9.9.9) as a fallback after CloudFlare (1.1.1.1). It works for us but I don’t understand why Cloudflare seems to have trouble with some domains. We are using Cloudflare DNS since two years and had no problems until now. I lose a little trust in Cloudflare here.