1.1.1.1 not resolving spiesschilderwerken.nl


#1

Hi,

It seems that 1.1.1.1 is not resolving a particular domain name: spiesschilderwerken.nl

See the following dig results:

$ dig spiesschilderwerken.nl @1.1.1.1

; <<>> DiG 9.10.3-P4-Ubuntu <<>> spiesschilderwerken.nl @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 27123
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;spiesschilderwerken.nl.                IN      A

;; Query time: 4471 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Tue Sep 18 08:26:17 UTC 2018
;; MSG SIZE  rcvd: 51

.

$ dig spiesschilderwerken.nl @1.0.0.1

; <<>> DiG 9.10.3-P4-Ubuntu <<>> spiesschilderwerken.nl @1.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 52796
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;spiesschilderwerken.nl.                IN      A

;; Query time: 4411 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Wed Sep 19 07:06:59 UTC 2018
;; MSG SIZE  rcvd: 51

.

$ dig spiesschilderwerken.nl @8.8.8.8

; <<>> DiG 9.10.3-P4-Ubuntu <<>> spiesschilderwerken.nl @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2543
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;spiesschilderwerken.nl.                IN      A

;; ANSWER SECTION:
spiesschilderwerken.nl. 14399   IN      A       149.210.225.16

;; Query time: 67 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Sep 18 08:26:05 UTC 2018
;; MSG SIZE  rcvd: 67

.
This issue happens from multiple locations, tested from the following locations:

$ dig +short CHAOS TXT id.server @1.1.1.1
"VNO"
$ dig +short CHAOS TXT id.server @1.0.0.1
"VNO"

.

$ dig +short CHAOS TXT id.server @1.1.1.1
"AMS"
$ dig +short CHAOS TXT id.server @1.0.0.1
"AMS"

For location AMS I’ve got the following help URL: https://cloudflare-dns.com/help/#eyJpc0NmIjoiTm8iLCJpc0RvdCI6Ik5vIiwiaXNEb2giOiJObyIsInJlc29sdmVySXAtMS4xLjEuMSI6IlllcyIsInJlc29sdmVySXAtMS4wLjAuMSI6IlllcyIsInJlc29sdmVySXAtMjYwNjo0NzAwOjQ3MDA6OjExMTEiOiJObyIsInJlc29sdmVySXAtMjYwNjo0NzAwOjQ3MDA6OjEwMDEiOiJObyIsImRhdGFjZW50ZXJMb2NhdGlvbiI6IkFNUyIsImlzcE5hbWUiOiJDbG91ZGZsYXJlIiwiaXNwQXNuIjoiMTMzMzUifQ==

DnsViz Analysis: http://dnsviz.net/d/spiesschilderwerken.nl/W6H4wA/dnssec/

Edit: Added additional information because I stumbled upon https://community.cloudflare.com/t/have-problems-with-1-1-1-1-read-me-first


#2

It seems that the nameservers for this domain advertises IPv6 addresses but refuse connectivity to them.

I think in this case, Cloudflares resolvers do not attempt a fallback to IPv4. Correct, @cscharff?

OP,
You may want to reach out to the provider of the nameservers and tell them about this misconfiguration.


#5

Late reply but thanks for helping.

So if I understand correctly, the nameservers are configured with AAAA records. But those addresses refuse connectivity. Therefor Cloudflare DNS returns an error whereas Google DNS falls back to IPv4?

Is fallback to IPv4 not something Cloudflare DNS should be doing? If it isn’t, can someone explain why?

I’ll contact the NS provider but this will help me better understand these DNS resolvers.

Thanks!


#6

Yes, correct.

I guess there are arguments for and against.

If an authoritative nameserver explicitly publishes AAAA records, but refuses connectivity on them, why would it be the responsibility of a resolver like 1.1.1.1 to implement a fallback mechanism? It wouldn’t encourage anyone to fix those problems, and it certainly doesn’t help increasing ipv6 adoption. Not to mention the side effects (eg speed) it would introduce.

From an end-user point of view on the other hand, I would agree that a fallback would give a better experience.

Luckily though, broken or misconfigured name servers like this (hopefully) happen less often nowadays. The only way to make it disappear is by telling and making providers aware of the situation.


#7

In the DNS world you always have multiple nameserver for redundancy. So when ns1 fails, resolvers can switch to ns2, and when that fails, ns3.

However, the fallback from one address-family to another is really not something that is supposed to happen there; that’s why you have multiple different servers. This is different in HTTP/HTTPS, with happy eyeballs recommendations encouraging such AF-fallbacks. However that has nothing to do with DNS (or SMTP).

But hey, your provider not only announces your NS record on IPv6 while being unreachable, he has both ns1 and ns2 pointing to the same exact IPv4 and IPv6 address. That is speaking volumes of the competence of this provider.

$ dig +short NS spiesschilderwerken.nl
ns2.mooionline.hostingsupport.nl.
ns1.mooionline.hostingsupport.nl.
$ host ns1.mooionline.hostingsupport.nl
ns1.mooionline.hostingsupport.nl has address 149.210.225.16
ns1.mooionline.hostingsupport.nl has IPv6 address 2a01:7c8:aaba:c::1
$ host ns2.mooionline.hostingsupport.nl
ns2.mooionline.hostingsupport.nl has address 149.210.225.16
ns2.mooionline.hostingsupport.nl has IPv6 address 2a01:7c8:aaba:c::1
$

You may want to call’em up for a quick fix by removing the bogus AAAA records, but honestly I’d switch to a more competent provider.

Not necessarily, Google may just prefer the IPv4 address-family. Ends up having the same effect, but I don’t think they do AF fallbacks.


#8

Thank you all for your kind elaboration!

It’s not my provider, I was kindly helping the one who’s actually their customer and was feeded by my curiosity to find out why the domain wasn’t reachable from our network.

As to the point of both ns1 and ns2 pointing to the same address. That’s what I saw as well upon second inspection of the DnsViz analysis. Thanks for confirming my suspicions haha.

Enjoy your weekends :smile: