Hello Panagiotis
Thank you for your reply and I apologize for my late response. I was
away on vacation.
I was just wondering why the resolver reacts immediately with a server
failure and then continues the recursive resolution in the background.
In the meantime, the client has received an error message in the
browser, for example when accessing the web.
Reloading the page would then work, as the resolver now has all the
information in the cache.
So it is still not entirely clear to me.
The resolver first initiates the process via a root server (No. 600+601)
and the error (No. 602) is displayed before the response.
Regards Florian
Am 24.04.2025 um 11:38 schrieb Panagiotis Matamis:
Hello Flo,
I just subscribed to this list yesterday and I am still learning...
It just happens that I was reading about this today in the
documentation, hope it helps!
https://bind9.readthedocs.io/en/latest/chapter6.html#a-quick-review-of-dns-iteration
It mentions that you can encounter some type of server failure. I
guess I can copy the first 2 paragraphs:
In DNS recursive name servers, an incoming query that cannot be
answered from the local cache is sent to the closest known delegation
point for the query name. For example, if a server is looking up
XYZZY.ISC.ORG and it the name servers for ISC.ORG, then it sends the
query to those servers directly; however, if it has never heard of
ISC.ORG before, it must first send the query to the name servers for
ORG (or perhaps even to the root zone that is the parent of ORG).
When it asks one of the parent name servers, that server will not have
an answer, so it sends a “referral” consisting only of the “delegation
point NS RRset.” Once the server receives this referral, it “iterates”
by sending the same query again, but this time to name servers for a
more specific part of the query name. Eventually this iteration
terminates, usually by getting an answer or a “name error” (NXDOMAIN)
from the query name’s authoritative server, or by encountering some
type of server failure.
...
Then it mentions about two different kinds of “glue”
...
Best regards,
Panagiotis
*From:*bind-users <bind-users-boun...@lists.isc.org> *On Behalf Of
*Florian Schlums
*Sent:* Thursday, 24 April 2025 11.18
*To:* bind-users@lists.isc.org
*Subject:* bind sends back server failure when local cache expired (
glue record)
Dear list
I'm running several bind caching resolver based on Ubuntu latest bind
release 9.18.30.
Configuration is pretty simple. A few public IP prefixes are allowed
to use these server as recursive resolver.
All other prefixes are no allowed to use them. The setup is up for
several years and works more or less without problems.
Now I have a case I have no explanation for.
It's about a glue record and expired cache behavior: crane.smokva.net
In some cases "dig @ns2.ggamaur.net crane.smokva.net" gives me a
SERVFAIL back. This happens when TTL in servers local cache has
expired. But this answer will appear only once, a second dig gives me
the IP.
#dig @ns2.ggamaur.net crane.smokva.net
; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> @ns2.ggamaur.net
crane.smokva.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9174
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: f81401b79354e29b010000006809fd983d7daeae1c6bfada (good)
;; QUESTION SECTION:
;crane.smokva.net. IN A
;; ANSWER SECTION:
crane.smokva.net. 26 IN A 85.10.196.166
;; Query time: 1 msec
;; SERVER: 213.160.40.34#53(ns2.ggamaur.net) (UDP)
;; WHEN: Thu Apr 24 11:00:08 CEST 2025
;; MSG SIZE rcvd: 89
#dig @ns2.ggamaur.net crane.smokva.net
; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> @ns2.ggamaur.net
crane.smokva.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id:
26109 <---------------- Cache expired
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: d2c192e8c153ff65010000006809fdc00ff4b74c1bc6a88a (good)
;; QUESTION SECTION:
;crane.smokva.net. IN A
;; Query time: 1 msec
;; SERVER: 213.160.40.34#53(ns2.ggamaur.net) (UDP)
;; WHEN: Thu Apr 24 11:00:48 CEST 2025
;; MSG SIZE rcvd: 73
#dig @ns2.ggamaur.net crane.smokva.net
; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> @ns2.ggamaur.net
crane.smokva.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23097
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 7573634154fc104a010000006809fdfe3b4159d1878e28be (good)
;; QUESTION SECTION:
;crane.smokva.net. IN A
;; ANSWER SECTION:
crane.smokva.net. 300 IN A 85.10.196.166
;; Query time: 11 msec
;; SERVER: 213.160.40.34#53(ns2.ggamaur.net) (UDP)
;; WHEN: Thu Apr 24 11:01:50 CEST 2025
;; MSG SIZE rcvd: 89
In detail, wireshark shows me the following when a local cache entry
has expired.
No. Time Source
Destination Protocol Length Info
# query to local bind server
599 2025-04-24 08:34:32.084611 213.160.41.17
213.160.41.10 DNS 87 Standard query 0x5a68 A
crane.smokva.net OPT
# server sends query to rootserver
600 2025-04-24 08:34:32.086197 2a02:5c0:1:11::10
2001:500:2d::d DNS 119 Standard query 0xf931 A
crane.smokva.net OPT
601 2025-04-24 08:34:32.086318 2a02:5c0:1:11::10
2001:500:2d::d DNS 119 Standard query 0x7c1b AAAA
crane.smokva.net OPT
# server sends server failure as an answer to client
602 2025-04-24 08:34:32.086334 213.160.41.10
213.160.41.17 DNS 87 Standard query response
0x5a68 Server failure A crane.smokva.net OPT
# answer from rootserver
603 2025-04-24 08:34:32.087883 2001:500:2d::d
2a02:5c0:1:11::10 DNS 1235 Standard query response
0x7c1b AAAA crane.smokva.net NS a.gtld-servers.net NS
604 2025-04-24 08:34:32.087883 2001:500:2d::d
2a02:5c0:1:11::10 DNS 1235 Standard query response
0xf931 A crane.smokva.net NS a.gtld-servers.net NS
# server queries .net server
605 2025-04-24 08:34:32.089329 2a02:5c0:1:11::10
2001:503:231d::2:30 DNS 119 Standard query 0x18a7
AAAA crane.smokva.net OPT
606 2025-04-24 08:34:32.089399 2a02:5c0:1:11::10
2001:503:231d::2:30 DNS 119 Standard query 0x88f8
A crane.smokva.net OPT
# answer from .net server
607 2025-04-24 08:34:32.091282 2001:503:231d::2:30
2a02:5c0:1:11::10 DNS 494 Standard query response
0x88f8 A crane.smokva.net NS crane.smokva.net
608 2025-04-24 08:34:32.091283 2001:503:231d::2:30
2a02:5c0:1:11::10 DNS 494 Standard query response
0x18a7 AAAA crane.smokva.net NS crane.smokva.net
# server queries to crane.smokva.net
609 2025-04-24 08:34:32.091815 213.160.41.10
85.10.196.166 DNS 99 Standard query 0x1bda A
crane.smokva.net OPT
610 2025-04-24 08:34:32.091882 213.160.41.10
85.10.196.166 DNS 99 Standard query 0xb973 AAAA
crane.smokva.net OPT
611 2025-04-24 08:34:32.101617 85.10.196.166
213.160.41.10 DNS 129 Standard query response
0xb973 AAAA crane.smokva.net SOA crane.smokva.net OPT
612 2025-04-24 08:34:32.101617 85.10.196.166
213.160.41.10 DNS 117 Standard query response
0x1bda A crane.smokva.net A 85.10.196.166 NS crane.smokva.net OPT
Can somebody explain me why the server in No. 602 sends back a server
failure and still keeps its resolving process for crane.smokva.net?
Flo
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
