1.1.1.1 not resolving .co.il addresses

Zero Trust 1.1.1.1
1

What is the name of the domain?

mynames.co.il

Please include test result URL when you create a post in the community forum. Paste the results from → 1.1.1.1 — One of the Internet’s Fastest, Privacy-First DNS Resolver

What is the error message?

No Reachable Authority

What is the issue you’re encountering

I can’t resolve DNS for any .il domain

What steps have you taken to resolve the issue?

C:\Users\nsumn>dig @1.1.1.1 NS mynames.co.il

; <<>> DiG 9.16.28 <<>> @1.1.1.1 NS mynames.co.il
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 30994
;; 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): (at delegation mynames.co.il.)
;; QUESTION SECTION:
;mynames.co.il. IN NS

;; Query time: 2565 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sat Nov 02 20:58:55 Jerusalem Standard Time 2024
;; MSG SIZE rcvd: 76

I can do that for any .co.il domain I have tried. In fact mynames even happens to be hosted on cloudflare.

What are the steps to reproduce the issue?

I’m not sure because I can reproduce this on all my computers, and a colleague can as well. But my DNS host located outside of Israel is not seeing this issue (doing an identical dig). I can get results if I use 8.8.8.8, 9.9.9.9 etc.

C:\Users\nsumn>dig @8.8.8.8 NS mynames.co.il

; <<>> DiG 9.16.28 <<>> @8.8.8.8 NS mynames.co.il
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36610
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;mynames.co.il. IN NS

;; ANSWER SECTION:
mynames.co.il. 21600 IN NS lynn.ns.cloudflare.com.
mynames.co.il. 21600 IN NS alla.ns.cloudflare.com.

;; Query time: 55 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Nov 02 21:03:28 Jerusalem Standard Time 2024
;; MSG SIZE rcvd: 97

2

Looking around, I also see it consistently to be working from the locations I’m reaching, so it appears we have a quite local / regional issue.

That said, -

Can you share what results you see, if you include “+nsid”, such as e.g.:

dig +nsid CHAOS TXT id.server @1.1.1.1

dig +nsid NS mynames.co.il @1.1.1.1

You should receive NSID’s like this:

$ dig +nsid NS mynames.co.il @1.1.1.1

; <<>> DiG 9.16.48-Debian <<>> +nsid NS mynames.co.il @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19657
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; NSID: 32 31 6d 38 39 30 ("21m890")

I would suggest collecting a list of the NSID’s that are showing these issues for you.

1 Like
3

C:\Users\nsumn>dig +nsid NS mynames.co.il @1.1.1.1

; <<>> DiG 9.16.28 <<>> +nsid NS mynames.co.il @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7111
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; NSID: 34 33 39 6d 37 (“439m7”)
;; QUESTION SECTION:
;mynames.co.il. IN NS

;; ANSWER SECTION:
mynames.co.il. 86400 IN NS alla.ns.cloudflare.com.
mynames.co.il. 86400 IN NS lynn.ns.cloudflare.com.

;; Query time: 7 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sun Nov 03 06:38:32 Jerusalem Standard Time 2024
;; MSG SIZE rcvd: 106

Which is interesting what does +nsid do?

4

All “+nsid” is doing is to request the server to provide it’s identifier (if specified by the operator).

Location number 21 is LHR (London, United Kingdom).

Location number 439 is TLV (Tel Aviv, Israel).

The number after “m”, e.g. 890 or 7, should be the “metal” number, in other words, the number of the actual server that responded to your request.

→

With additional DNS queries, you aren’t guaranteed to reach the exact same colocation facility (e.g. 439), or metal/server (e.g. 7) again and again, and that itself can make troubleshooting the queries very tricky (if even possible at all).

As “+nsid” can be requested at the same time with the DNS query, you will get both the DNS result (if available), AND the NSID, which can help with troubleshooting, assuming that the DNS result indicate further investigation would be necessary.

If you consistently succeed with the query, when you hit “439m7”, and many other “439m*” ones, but that it is consistently failing when the NSID is reading e.g. “439m123” and “439m456”, then for further troubleshooting (e.g. at Cloudflare’s end), it would make sense to look in to what is happening on metal/server 123 and 456, as they were the ones, that were unable to provide a proper response.

5

I did a lookup for the actual domain I am interested in:

; <<>> DiG 9.16.28 <<>> +nsid NS citybook.co.il.co.il @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8691
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; NSID: 34 33 39 6d 32 (“439m2”)
;; QUESTION SECTION:
;citybook.co.il.co.il. IN NS

;; AUTHORITY SECTION:
co.il. 86400 IN SOA nsa.ns.il. hostmaster.isoc.org.il. 2024110349 1800 900 5184000 86400

;; Query time: 10 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sun Nov 03 17:00:49 Jerusalem Standard Time 2024
;; MSG SIZE rcvd: 121

It isn’t even sending a NS. So the NSID that I see is 439 (Tel Aviv) m2.

I am wondering could this be an ISP doing something stupid and modifying DNS?

I did more lookups for mynames.co.il and they now don’t give NS entries. In particular I hit m17, m13, m5, m16… So it seems to be all over the place.

6

It seems like it is working now without a problem.

7

One thing I notice here, is that you have “.co.il” twice.

The response with the SOA is the “co.il” zone that responds with that "“il.co.il” (and labels (e.g. sub-domains) below) doesn’t exist.

If you change the query from asking for “citybook.co.il.co.il”, to be asking for “citybook.co.il” instead, you should be seeing see four “cloudns.net” name servers.

Result:

→ “il.co.il”, “co.il.co.il” and “citybook.co.il.co.il” does NOT exist.

→ “citybook.co.il” does exist.

Did you take further notes than that?

E.g. considering your very first post:

Was it consistently “status: SERVFAIL”?

Was it consistently “; EDE: 22 (No Reachable Authority): (at delegation mynames.co.il.)”?

They are not supposed to be there at all DNS labels, e.g. such as in the above example, where neither “il.co.il”, “co.il.co.il” nor “citybook.co.il.co.il” exist.

If you see a “status: NXDOMAIN”, it signals that the current label (and any labels (e.g. sub-domains) below it) doesn’t exist.

You will therefore find the “SOA” record in the authority section, as you did, for the zone that you were able to reach (in the above example, the “co.il” zone), which will provide guidance for DNS resolvers in regards to negative caching (e.g. caching records that does not exist for a while, to avoid putting unnecessary load on the DNS system).

So for the “citybook.co.il.co.il” query, which I believe you misspelled, as “co.il” is there twice, the actual result seems to be exactly what you should be expecting to see.

1 Like
8

I’d also like to add that I am experiencing a similar problem, which started around the time the post was created.

It is quite inconsistent. After doing some checks, sometimes, my connection to 1.1.1.1 completely times out, sometimes it takes 8 seconds exactly (which I assume is some timeout), and sometimes I get a response in milliseconds.

Here you can see co.il timeouts while google.com resolves just fine:

aofekiko@OfekPC:~$ dig +nsid NS citybook.co.il @1.1.1.1
;; communications error to 1.1.1.1#53: timed out
;; communications error to 1.1.1.1#53: timed out

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> +nsid NS citybook.co.il @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44122
;; 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): (time limit exceeded)
; NSID: 34 33 39 6d 31 37 ("439m17")
;; QUESTION SECTION:
;citybook.co.il.                        IN      NS

;; Query time: 4656 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Mon Nov 04 19:28:49 IST 2024
;; MSG SIZE  rcvd: 78

aofekiko@OfekPC:~$ dig +nsid NS citybook.co.il @1.0.0.1
;; communications error to 1.0.0.1#53: timed out
;; communications error to 1.0.0.1#53: timed out
;; communications error to 1.0.0.1#53: timed out

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> +nsid NS citybook.co.il @1.0.0.1
;; global options: +cmd
;; no servers could be reached

aofekiko@OfekPC:~$ dig +nsid NS google.com @1.0.0.1

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> +nsid NS google.com @1.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36829
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; NSID: 34 33 39 6d 31 38 ("439m18")
;; QUESTION SECTION:
;google.com.                    IN      NS

;; ANSWER SECTION:
google.com.             336849  IN      NS      ns4.google.com.
google.com.             336849  IN      NS      ns2.google.com.
google.com.             336849  IN      NS      ns3.google.com.
google.com.             336849  IN      NS      ns1.google.com.

;; Query time: 0 msec
;; SERVER: 1.0.0.1#53(1.0.0.1) (UDP)
;; WHEN: Mon Nov 04 19:29:30 IST 2024
;; MSG SIZE  rcvd: 121

aofekiko@OfekPC:~$ dig +nsid NS google.com @1.1.1.1

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> +nsid NS google.com @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62737
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; NSID: 34 33 39 6d 37 ("439m7")
;; QUESTION SECTION:
;google.com.                    IN      NS

;; ANSWER SECTION:
google.com.             336862  IN      NS      ns4.google.com.
google.com.             336862  IN      NS      ns2.google.com.
google.com.             336862  IN      NS      ns3.google.com.
google.com.             336862  IN      NS      ns1.google.com.

;; Query time: 0 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Mon Nov 04 19:29:39 IST 2024
;; MSG SIZE  rcvd: 120

A case where I get a response:

dig +nsid NS ynet.co.il @1.1.1.1

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> +nsid NS ynet.co.il @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43588
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 3 (Stale Answer)
; NSID: 34 33 39 6d 31 33 ("439m13")
;; QUESTION SECTION:
;ynet.co.il.                    IN      NS

;; ANSWER SECTION:
ynet.co.il.             30      IN      NS      ns1-61.akam.net.
ynet.co.il.             30      IN      NS      usw1.akam.net.
ynet.co.il.             30      IN      NS      asia2.akam.net.
ynet.co.il.             30      IN      NS      use1.akam.net.
ynet.co.il.             30      IN      NS      usc2.akam.net.
ynet.co.il.             30      IN      NS      eur2.akam.net.
ynet.co.il.             30      IN      NS      ns1-168.akam.net.
ynet.co.il.             30      IN      NS      ns1-92.akam.net.

;; Query time: 0 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Mon Nov 04 19:34:52 IST 2024
;; MSG SIZE  rcvd: 223

Cases where there seems to be a retry due to a timeout and then a response:

dig +nsid NS ynet.co.il @1.1.1.1

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> +nsid NS ynet.co.il @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7566
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; NSID: 34 33 39 6d 34 ("439m4")
;; QUESTION SECTION:
;ynet.co.il.                    IN      NS

;; ANSWER SECTION:
ynet.co.il.             258     IN      NS      ns1-92.akam.net.
ynet.co.il.             258     IN      NS      eur2.akam.net.
ynet.co.il.             258     IN      NS      usw1.akam.net.
ynet.co.il.             258     IN      NS      use1.akam.net.
ynet.co.il.             258     IN      NS      ns1-168.akam.net.
ynet.co.il.             258     IN      NS      asia2.akam.net.
ynet.co.il.             258     IN      NS      usc2.akam.net.
ynet.co.il.             258     IN      NS      ns1-61.akam.net.

;; Query time: 4652 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Mon Nov 04 19:43:33 IST 2024
;; MSG SIZE  rcvd: 216

Sometimes times I do manage to reach a DNS server and fetch it’s NSID but sometimes I don’t:

aofekiko@OfekPC:~$ dig +nsid NS citybook.co.il @1.1.1.1
;; communications error to 1.1.1.1#53: timed out
;; communications error to 1.1.1.1#53: timed out
;; communications error to 1.1.1.1#53: timed out

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> +nsid NS citybook.co.il @1.1.1.1
;; global options: +cmd
;; no servers could be reached

aofekiko@OfekPC:~$ dig +nsid NS citybook.co.il @1.1.1.1
;; communications error to 1.1.1.1#53: timed out
;; communications error to 1.1.1.1#53: timed out

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> +nsid NS citybook.co.il @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57301
;; 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)
; NSID: 34 33 39 6d 31 39 ("439m19")
;; QUESTION SECTION:
;citybook.co.il.                        IN      NS

;; Query time: 0 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Mon Nov 04 19:49:26 IST 2024
;; MSG SIZE  rcvd: 59
9

Hi, thanks for reporting the issue.

The problem seems to be a network connectivity issue between our Israeli data centers and ClouDNS name servers. I’m creating a internal ticket for our team to take a look.

10

Hi @nsumner, when our team did the investigation, the problem seems already gone. I cannot reproduce either now. Can you re do the test to see if the issue is gone for you too?

11

@aofekiko , when you see dig timeout on communicating with 1.1.1.1. You can try to set a large timeout to see if it can receive a response.

dig’s default timeout is at 5 seconds, you can use +timeout to override it.

+timeout=###        (Set query timeout) [5]
12

Hey @Hunts, It is as you said. The issue seems to have already been gone.
I haven’t had any issues with my DNS queries in the past 3 days.
I have suspected that this issue was specific to my ISP, I have also reported the problem to them and they did mention that they saw an increase in DNS failures.

Thank you for your help!

13

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.