bind sends back server failure when local cache expired ( glue record)
Florian Schlums
bindbandbund at ggaweb.ch
Tue May 6 09:54:02 UTC 2025
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-bounces at lists.isc.org> *On Behalf Of
> *Florian Schlums
> *Sent:* Thursday, 24 April 2025 11.18
> *To:* bind-users at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20250506/2b7a5502/attachment-0001.htm>
More information about the bind-users
mailing list