Cannot resolve jli.st domain


#1

macOS 10.13.6

debug URL

dig reports

➜  ~ dig jli.st @1.1.1.1

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

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

;; Query time: 2222 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri Sep 14 09:13:58 EDT 2018
;; MSG SIZE  rcvd: 35

➜  ~ dig jli.st @1.0.0.1 

; <<>> DiG 9.10.6 <<>> jli.st @1.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 11284
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 2211 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Fri Sep 14 09:15:34 EDT 2018
;; MSG SIZE  rcvd: 35

➜  ~ dig jli.st @8.8.8.8

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

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

;; ANSWER SECTION:
jli.st.			10803	IN	A	67.199.248.12
jli.st.			10803	IN	A	67.199.248.13

;; Query time: 37 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Sep 14 09:17:05 EDT 2018
;; MSG SIZE  rcvd: 67

➜  ~ dig +short CHAOS TXT id.server @1.1.1.1
"YUL"

➜  ~ dig +short CHAOS TXT id.server @1.0.0.1
"YUL"

#2

http://dnsviz.net/d/jli.st/W5whPA/dnssec/

That domain has these nameservers:

ns1.parking.st.  (insecure)  3422  A     94.254.45.10
ns1.parking.st.  (insecure)  3421  AAAA  2001:9b1:8157:0:216:3eff:fe8c:f61e
ns2.parking.st.  (insecure)  3421  A     174.127.112.41
ns2.parking.st.  (insecure)  3421  AAAA  2607:fc98:0:44:216:3eff:fe33:5c50

The IPv6 addresses don’t work.

1.1.1.1 is less forgiving of that kind of outage than other resolvers. :confused:

Regardless, those 2 broken nameservers need to be fixed.


#3

Is there any workaround possible from Cloudflare’s part? Because otherwise, as an end user, i must switch back to Google’s DNS to access the site :slightly_frowning_face:


#4

Ideally you should report the misconfiguration to the domain owner, but yes, it would be really great if Cloudflare could fix this bug.

IDK if a rep has seen this or my original post, maybe @cscharff can comment?


#5

I’ve turned off IPv6 for this NS set, but it needs to be fixed by the operator eventually. It’d be fantastic if you could report it and reference this thread!


#6

Is there a plan to change how the resolver handles this?

My reading of RFC8305 would suggest that the query should succeed anyway, with some penalty for the v6 timeout.


#7

This is completely out of context. Happy eyeballs is for clients PCs, not for DNS recursors. The specific RFC section you mention is for clients accessing their own resolvers, not for resolvers accessing authoritative DNS servers, and it is there because clients may or may not have intermittent IPv6 connectivity.

However, an authoritative servers must be correctly configured. If you provider doesn’t, and doesn’t fix this issue immediately when reported, then that provider is obviously completely incompetent.

1.1.1.1 won’t be your last problem then, you will keep hitting this problems with various other providers.

The same exact issue happens with SMTP/MX records: there as well you have the same problem. If service providers are not competent enough to respond in IPv6, they have to drop the AAAA entries from their records. Just because Cloudflare does deploy a fix or not, and just because “it works with Google” doesn’t change the problem that you will continually face issues due to this missconfiguration on your service providers side.


IPv6 timeouts appear to be racey
#8

What? Resilient dual-stack behavior isn’t a factor for recursive resolvers? I think APNIC disagrees. The (apparently) upstream project to 1.1.1.1 implements happy eyeballs anyway and is capable of resolving OP’s domain (along with Unbound and a host of others). It’s not a Google thing. I don’t think this should be controversial.


#9

The RFC8305 “happy eyeballs” you mentioned is for clients, not for DNS resolvers, and the specific section talks about about client systems. The entire RFC has nothing to do with recursive resolver behavior.

A guy at a APNIC conference is not an authority on those things and neither is APNIC itself.

The DNS system has a clear failover strategy to due multiple (hopefully) different NS servers. If they all have the same error, lookup better fail fast and early, so that it can be found and fixed.

Having everyone hide severe administrative errors on part of the authoritative servers by falling back to IPv4 at the very least leads to lookup delays for everyone. And with the problem mostly hidden, and the “it works with 8.8.8.8” attitude, it’s even more unlikely that it will every get fixed, should a customer or someone else ever report the issue.

Really, if your provider sets up AAAA records for infrastructure critical services like the authoritative nameserver and then fails to monitor them on IPv6, that’s a bad sign.

It’s sad that everyone is giving in here and implement those fallbacks. It will hide real problems on the Internet, making sure issues with real-life impact get swiped under the rug and remain unfixed for years.

Providers like Cloudflare and Google would be in the unique position to enforce those things, sadly it looks like they don’t care. I’m sure Cloudflare will give in here as well, although they did a great job having the industry fix the 1.1.1.0/24 subnet, which was also not easy.

However, with miss-configured nameservers like this, you will always have issues with resolvers on the other side. Cloudflare will not be the last resolver not falling back to IPv4.