1.1.1.1 not resolving an address

[lorenzodimarco]

Hi, at home and on my devices i’m using 1.1.1.1 as dns resolver but since a couple of days i cannot resolve arithmostech[dot]com and anything like whatever[dot]arithmostech[dot]com

If i switch to Google or Quad9 there’s no error

I’m not sure whether this is the right place to post but using dig @1.1.1.1 i keep receving errors EDN 22 and 23 …and this section of the forum is linked here https://developers.cloudflare.com/1.1.1.1/infrastructure/extended-dns-error-codes/

is there anything that i could do to avoid switching resolver when i need to access resources from that domain?

[Laudian]

I have a guess what the problem might be.

arithmostech.com has these nameservers, which Cloudflare does not resolve either:

arithmostech.com.       172800  IN      NS      dns.widhost.net.
arithmostech.com.       172800  IN      NS      dns2.widhost.net.
;; Received 93 bytes from 2001:502:7094::30#53(j.gtld-servers.net) in 32 ms

dns.widhost.net uses these nameservers, of which Cloudflare only resolves one:

widhost.net.            172800  IN      NS      ns.abdns.eu.
widhost.net.            172800  IN      NS      ns.abdns.biz.
widhost.net.            172800  IN      NS      ns.abdns.info.
;; Received 122 bytes from 2001:503:83eb::30#53(c.gtld-servers.net) in 100 ms

Now the interesting part. The nameservers for all 3 of these are:

abdns.eu.               86400   IN      NS      ns.abdns.biz.
abdns.eu.               86400   IN      NS      ns.abdns.eu.
abdns.eu.               86400   IN      NS      ns.abdns.info.

abdns.biz.              3600    IN      NS      ns.abdns.eu.
abdns.biz.              3600    IN      NS      ns.abdns.info.
abdns.biz.              3600    IN      NS      ns.abdns.biz.

abdns.info.             3600    IN      NS      ns.abdns.info.
abdns.info.             3600    IN      NS      ns.abdns.biz.
abdns.info.             3600    IN      NS      ns.abdns.eu.

All 3 of these are the nameservers for their own zones, so glue-records are required to make it work:

;; AUTHORITY SECTION:
abdns.biz.              3600    IN      NS      ns.abdns.eu.
abdns.biz.              3600    IN      NS      ns.abdns.info.
abdns.biz.              3600    IN      NS      ns.abdns.biz.

;; ADDITIONAL SECTION:
ns.abdns.biz.           3600    IN      A       80.88.85.22

;; AUTHORITY SECTION:
abdns.eu.               86400   IN      NS      ns.abdns.eu.
abdns.eu.               86400   IN      NS      ns.abdns.biz.
abdns.eu.               86400   IN      NS      ns.abdns.info.

;; ADDITIONAL SECTION:
ns.abdns.eu.            86400   IN      A       185.12.179.88

;; AUTHORITY SECTION:
abdns.info.             3600    IN      NS      ns.abdns.eu.
abdns.info.             3600    IN      NS      ns.abdns.biz.
abdns.info.             3600    IN      NS      ns.abdns.info.

;; ADDITIONAL SECTION:
ns.abdns.info.          3600    IN      A       217.61.96.167

As you can see, all 3 parent zones deliver glue-records, but only for the nameserver that lies within their own zone. However, the recursive resolver is in no way mandated to use the nameserver for which glue-records were provided.

So I guess what happens is this:
Cloudflare queries the .info zone for ns.abdns.info. From the 3 results, it chooses one at random, say ns.abdns.eu. It then queries the .eu zone for ns.abdns.eu. From the 3 results, it chooses one at random… repeat until the resolver either times out or gets lucky and picks the nameserver for which glue records were provided.

This would also explain why it works in some locations but not in others. For me, all the problems above I only encountered on my home network (FRA colo), whereas the names all resolved fine on my server (HEL colo).

I believe glue records should be provided for all nameservers in this case, but I might be wrong.

That’s at least how others do it, for example:

dig b2.info.afilias-nst.org @a.root-servers.net

dig b2.info.afilias-nst.org @a.root-servers.net

; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> b2.info.afilias-nst.org @a.root-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60181
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 13
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;b2.info.afilias-nst.org.       IN      A

;; AUTHORITY SECTION:
org.                    172800  IN      NS      d0.org.afilias-nst.org.
org.                    172800  IN      NS      a0.org.afilias-nst.info.
org.                    172800  IN      NS      c0.org.afilias-nst.info.
org.                    172800  IN      NS      a2.org.afilias-nst.info.
org.                    172800  IN      NS      b0.org.afilias-nst.org.
org.                    172800  IN      NS      b2.org.afilias-nst.org.

;; ADDITIONAL SECTION:
d0.org.afilias-nst.org. 172800  IN      A       199.19.57.1
d0.org.afilias-nst.org. 172800  IN      AAAA    2001:500:f::1
a0.org.afilias-nst.info. 172800 IN      A       199.19.56.1
a0.org.afilias-nst.info. 172800 IN      AAAA    2001:500:e::1
c0.org.afilias-nst.info. 172800 IN      A       199.19.53.1
c0.org.afilias-nst.info. 172800 IN      AAAA    2001:500:b::1
a2.org.afilias-nst.info. 172800 IN      A       199.249.112.1
a2.org.afilias-nst.info. 172800 IN      AAAA    2001:500:40::1
b0.org.afilias-nst.org. 172800  IN      A       199.19.54.1
b0.org.afilias-nst.org. 172800  IN      AAAA    2001:500:c::1
b2.org.afilias-nst.org. 172800  IN      A       199.249.120.1
b2.org.afilias-nst.org. 172800  IN      AAAA    2001:500:48::1

;; Query time: 28 msec
;; SERVER: 2001:503:ba3e::2:30#53(a.root-servers.net) (UDP)
;; WHEN: Sat Sep 30 14:34:30 CEST 2023
;; MSG SIZE  rcvd: 442

[lorenzodimarco]

First of all thank you: much appreciated!

I’m really the most distant thing from a pro when it come s to DNS and i admit that I had to google for concepts like glue-record to (try to) understand your reply. Having said that I think i now understand a little bit more: thanks also for the insight that hinted at new concepts to study/understand!

Just a few more questions if you don’t mind:

1. This looks like a problem that has to be dealt by the ones that manage name servers for adbdsn.eu/biz/info…correct? or is this still something that Cloudflare could sort out? I’m asking this because after all even if it’s probably misconfigured there’s apparently nothing that prevents Google or Quad9 from correctly and consistently resolving this. And in case is there any possibility that someone at Cloudflare looks into it?
2. as this issue appeared just in the last few days (I’ve worked from home with the need of reaching that domain for a couple of years without ever noticing this issue) do you think that i’ve just been “lucky” so far (like your server network vs your home network) or is more plausible that something has changed in one of the “links” of the chain? is there a way to investigate this (like a sort of “history” of NS records)?

[Laudian]

@lorenzodimarco

This looks like a problem that has to be dealt by the ones that manage name servers for adbdsn.eu/biz/info…correct? or is this still something that Cloudflare could sort out?

I’m really not sure. I’ve read through the RFCs that relate to glue records a few times, and they are quite explicit in more than one place that glue records should only be provided if the NS is in a child zone of the queried zone.

However, it also says this:

@RFC 1034

Bound the amount of work (packets sent, parallel processes
started) so that a request can’t get into an infinite loop or
start off a chain reaction of requests or queries with other
implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
SOME DATA.

@RFC 1034

If the response shows a delegation, the resolver should check to see
that the delegation is “closer” to the answer than the servers in SLIST
are. This can be done by comparing the match count in SLIST with that
computed from SNAME and the NS RRs in the delegation. If not, the reply
is bogus and should be ignored.

I think it is very reasonable here that the resolver might discard the response because all delegations are already on the current searchlist (SLIST). Sure, in this case, if the resolver kept querying nameservers and caching the glue records, it would arrive at a point where it has records for all 3 nameservers, but this is essentially the “halting problem”, where the resolver cannot know whether this loop terminates until it terminates, so aborting is not unreasonable.

Keep in mind that maybe this is not the problem, I’m just guessing here. This nameserver setup is rather uncommon, but maybe someone who knows more about it can add their knowledge

@lorenzodimarco

do you think that i’ve just been “lucky” so far

That’s really impossible to say. IP histories exist, but you will probably not find detailed historical DNS queries that could answer these questions. I would probably just ask Widhost if they have made recent changes, but chances of getting in contact with someone who could answer this are rather slim.

What I think is a bit weird is that I still see the same problem on my home network but not on my server. I would expect the problem to occur more randomly if my explanation was even somewhat correct.