1.1.1.1 not resolving - unlike all other DNS


#1

EXAMPLE #1 - OpenDNS - WORKING

$ dig one.webscitis .com @208.67.222.222 A

; <<>> DiG 9.10.6 <<>> one.webscitis .com @208.67.222.222 A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36521
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;one.webscitis .com. IN A

;; ANSWER SECTION:
one.webscitis .com. 86400 IN A 80.241.222.188

;; Query time: 84 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Thu Apr 05 15:37:38 WEST 2018
;; MSG SIZE rcvd: 62

EXAMPLE #2 - 1.1.1.1 - NOT WORKING

$ dig one.webscitis .com @1.1.1.1 A

; <<>> DiG 9.10.6 <<>> one.webscitis .com @1.1.1.1 A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24220
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;one.webscitis .com. IN A

;; Query time: 324 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Apr 05 15:37:52 WEST 2018
;; MSG SIZE rcvd: 35

Please fix. I can not and will not give any further try to DNS Servers that aren’t working.


#2

http://dnsviz.net/d/webscitis.com/WsY2oA/dnssec/

webscitis.com.          86400   IN      DS      55118 13 1 5BE3851B1FE6D7C68A92B54CF6ABFFAF6E74B6F0

The domain has a DS record, indicating that it uses DNSSEC, but it doesn’t use DNSSEC.

All validating resolvers will consider it bogus.

The domain’s administrators need to remove the DS record, or switch from Route 53 to a DNS provider that supports DNSSEC (and update the DS record, if necessary).


#3

actually I spotted a problem with one of the DNS servers, beside that the remark “switch from Route 53 to a DNS provider (…)” lol u gotta be kidding.
If this is the kind of service you’re offering, where a minor issue prevents name resolution and normal flow of events, then no I will not use or advise anyone to use a service that will bring delays and more issues to the organisation.


#4

To be clear, I don’t work for or represent Cloudflare.

What problem? There aren’t really any problems with any of the DNS servers involved. The domain’s DNS records are just configured in an invalid way.

Route 53 does not support DNSSEC at this time. The domain’s operators express enthusiasm for both DNSSEC and Route 53, but they are for now mutually exclusive. I listed both valid choices available to them.

Anyone who chooses to use DNSSEC considers a bogus zone to be a critical issue.

DNSSEC is rather controversial, but Cloudflare endorses it, and 1.1.1.1 is a typical validating resolver.

As a DNS user, if you don’t want DNSSEC, you’ll have to set the CD bit on all your queries, or use a non-validating resolver. (OpenDNS is good!)

Whoever operates the webscitis.com domain should decide what path to take, and fix the configuration accordingly. The invalid DNS records don’t work 12% of the time.


#5

The problem I spotted is regarding one of my nameservers by its IP I see it’s querying a wrong (an old) server. ns2 should reflect the following:

$ dig ns2.webscitis.com @ns1.webscitis.com A

; <<>> DiG 9.10.6 <<>> ns2.webscitis.com @ns1.webscitis.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8748
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 8
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ns2.webscitis.com.		IN	A

;; ANSWER SECTION:
ns2.webscitis.com.	86400	IN	A	205.251.192.203

but I’ll check on that later.
About the DNSSEC, I know about Route53 not fully supporting DNSSEC. I am not going to change that and many people using AWS infrastructure/Route53 will simply ditch 1.1.1.1 if it is not compatible. IMO, and just that.
So since it is what it is I will stick with OpenDNS, been using them for long and I am happy with it.

Thanks for all your replies. Cheers.

Ricardo


#6

Cloudflare has made the (perhaps controversial) decision that DNSSEC which allows for cryptographic proof that a DNS record is being served from a valid server is both a good thing and that where DNSSEC validation fails the result should not be trusted.

The risk that DNSSEC seeks to mitigate is man in the middle or DNS cache poisoning which pose a security risk to website visitors. As @mnordhoff notes, this particular zone has apparently decided that DNSSEC is important as well and enabled it for their zone (it doesn’t get turned on by accident). At the same time the server responding with the entries for their DNS records fails to validate based on the settings applied to the zone.

Now, we can assume that this is just operator error and return the results, but what if we’re wrong? Most public resolvers choose to make this assumption, but 1.1.1.1 intends to be a different type of resolver and we support features and functions that may or not be desirable for everyone.

I understand completely if you don’t care that the DNS values returned by other resolvers may be spoofed. If that’s not important to you, 1.1.1.1 may not be the right resolver for you. If webscitis.com is your zone, I’d recommend removing the DNSSEC value for your zone if you choose to use a DNS provider which doesn’t support DNSSEC. Other folks who try to visit your site using 1.1.1.1 with have the same issue whether you choose to use the resolver or not until you do.


#7

To emphasize, Cloudflare is far from the only validating resolver operator. Having an insecure zone is fine. Using Route 53 is fine. There are millions of Route 53 zones that validating resolvers can and do resolve.

The problem is having an incorrectly configured – bogus – zone.

My earlier link gives the global DNSSEC validation rate at 12%, though I don’t know what exactly it’s counting or how accurate it is. There are a number of countries with an extremely high validation rate – or a very low one – and the particular impact a broken configuration has on a domain, and its operators, and its users, utterly varies.


#8

@mnordhoff forget my previous reply about this issue. I am getting a wrong info on a reporting tool I’m using. I emailed them cause it seems to me ns2 is correct and their report is giving me an outdated result.
@mnordhoff & @cscharff i can’t seem to find a DNSSEC configuration on the webscitis.com zone.
On the registrar, the option of DNSSEC is also disabled for the domain. What am I missing here?


#9

You may want to check with your registrar again. With my registrar I have to get my DNSSEC entries added outside of any UI tools (which is always a joy) and there’s no hint in their UI that I have DNSSEC entries in place.

http://dnsviz.net/d/webscitis.com/dnssec/


#10

Ok so following that link you see that warning regarding ns2 that shows the IP 79.143.190.225 ? It should be 205.251.192.203. All the others are correct and below on the domain records most of them show all the correct ip’s but I see one that one is showing that 79.143… too.

So, I found in the registrar that turning on the DNSSEC option it shows me a key tag corresponding to that DS record. The thing here now is… 1st I had DNSSEC off, when I turn it off it hides the keys list. And when I try to remove the key it tells me that “At least one DNSSEC record should be present”.


#11

Your registrar’s DNSSEC handling is unfortunately buggy. Has been for years. Adding and removing DS records appears to happen instantly in the control panel, but they can take years to actually push the change to the TLD.

You can try contacting their support, but it’s an awkward situation.

You can also transfer the domain to another registrar, but I don’t know how long that will take.


#12

heh I have been with a few and I’m actually happy with these guys now, it’s NameCheap ! I have been around a few registrars and overall I can say these guys are pretty decent!
Anyway I’ll talk to them about this and I’ll share how it works out.


#13

Try Google Domains, it works beautifully!

domains.google


#14

Yes please let us know when you get it resolved, will be helpful for others who might be in the same boat.

To be fair we knew this (our decision to validate DNSSEC results) would potentially result in these kinds of issues and definitely sorry you got caught out by it… but we’re trying to help push providers, registrars and others to make necessary changes for the betterment of the interwebs in general. It would also be awesome if this encouraged Route53 to add DNSSEC support as well. I guess time will tell. :slight_smile:


#15

It seems absolutely incredible that Route53 doesn’t support DNSSEC!


#16

Yeah I agree it would be nice for Route53 to support DNSSEC in the first place too.
About Google domains… not really an option.

Regarding the Cloudflare option, I think it would be more interesting if CF would win a reasonable market share space and work on the speed and privacy as announced. It’s good, but second best to google dns (according to the namebench tool) which I believe is still #1 !

When you’ve taken an option that prevents domains to be resolved by the system due to this, this will have impact on organisations, users will encounter this problems, 12% that face them would be a nice 12% market to have for example.
The organisations if on AWS/Route53 will not know about this. An user who opts into 1.1.1.1 will have DNS problems and move to another. Many won’t come here and ultimately the sysadmins won’t be warned.

Speed and privacy are good motos for a good service. I would take the decision of validating DNSSEC in the future after having a bigger market share. That marketshare would force peers to look into DNSSEC and it would create a different impact on the organisations. But well all of this rambling is just an opinion, speed and privacy (=/= google) are always good arguments to make me try a service.

I opened a ticket on NameCheap let’s see how it goes, I’ll be back


#17

Google Public DNS also validates.


#18

I come across some networks that use google public dns and I never had such issue as the one that brought me here.


#19

In this case, their behavior is the same as Cloudflare’s.

$ dig webscitis.com @publicdns.goog

; <<>> DiG 9.10.3-P4-Ubuntu <<>> webscitis.com @publicdns.goog
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4792
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 21 msec
;; SERVER: 2001:4860:4860::8844#53(2001:4860:4860::8844)
;; WHEN: Thu Apr 05 18:36:24 UTC 2018
;; MSG SIZE  rcvd: 42

Every DNS implementation has its own unique bugs and quirks, but no validating resolver will accept that domain without an override.


#20

I have never used the address publicdns.goog but 8.8.8.8 seems fine

$ dig webscitis.com @8.8.8.8 A

; <<>> DiG 9.10.6 <<>> webscitis.com @8.8.8.8 A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46677
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
webscitis.com.		21599	IN	A	79.143.190.227

;; Query time: 106 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Apr 05 19:48:32 WEST 2018
;; MSG SIZE  rcvd: 58