<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#ffffff">
Hello Panagiotis<br>
Thank you for your reply and I apologize for my late response. I was
away on vacation.<br>
I was just wondering why the resolver reacts immediately with a
server failure and then continues the recursive resolution in the
background.<br>
In the meantime, the client has received an error message in the
browser, for example when accessing the web.<br>
Reloading the page would then work, as the resolver now has all the
information in the cache.<br>
<br>
So it is still not entirely clear to me. <br>
The resolver first initiates the process via a root server (No.
600+601) and the error (No. 602) is displayed before the response.<br>
<br>
Regards Florian<br>
<br>
<div class="moz-cite-prefix">Am 24.04.2025 um 11:38 schrieb
Panagiotis Matamis:<br>
</div>
<blockquote type="cite"
cite="mid:AS1P192MB1591CDB3AAA30F055B6C5D2CA7852@AS1P192MB1591.EURP192.PROD.OUTLOOK.COM">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator"
content="Microsoft Word 15 (filtered medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face
{font-family:Aptos;}@font-face
{font-family:"Ubuntu Mono";}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#467886;
text-decoration:underline;}span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}div.WordSection1
{page:WordSection1;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span lang="en-DK"
style="font-size:11.0pt;mso-fareast-language:EN-US">Hello
Flo,
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="en-DK"
style="font-size:11.0pt;mso-fareast-language:EN-US">I just
subscribed to this list yesterday and I am still learning...
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="en-DK"
style="font-size:11.0pt;mso-fareast-language:EN-US">It just
happens that I was reading about this today in the
documentation, hope it helps! <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="en-DK"
style="font-size:11.0pt;mso-fareast-language:EN-US"><a
href="https://bind9.readthedocs.io/en/latest/chapter6.html#a-quick-review-of-dns-iteration"
moz-do-not-send="true" class="moz-txt-link-freetext">https://bind9.readthedocs.io/en/latest/chapter6.html#a-quick-review-of-dns-iteration</a>
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="en-DK"
style="font-size:11.0pt;mso-fareast-language:EN-US">It
mentions that you can encounter some type of server failure.
I guess I can copy the first 2 paragraphs:<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span
style="font-size:11.0pt;mso-fareast-language:EN-US">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).<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span
style="font-size:11.0pt;mso-fareast-language:EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span
style="font-size:11.0pt;mso-fareast-language:EN-US">...<br>
Then it mentions about two different kinds of “glue”<br>
... <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="en-DK"
style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="en-DK"
style="font-size:11.0pt;mso-fareast-language:EN-US">Best
regards,
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="en-DK"
style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="en-DK"
style="font-size:11.0pt;mso-fareast-language:EN-US">Panagiotis<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="en-DK"
style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<div
style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US"
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span
lang="EN-US"
style="font-size:11.0pt;font-family:"Calibri",sans-serif">
bind-users <a class="moz-txt-link-rfc2396E" href="mailto:bind-users-bounces@lists.isc.org"><bind-users-bounces@lists.isc.org></a>
<b>On Behalf Of </b>Florian Schlums<br>
<b>Sent:</b> Thursday, 24 April 2025 11.18<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a><br>
<b>Subject:</b> bind sends back server failure when
local cache expired ( glue record)<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p>Dear list<o:p></o:p></p>
<p>I'm running several bind caching resolver based on Ubuntu
latest bind release 9.18.30.<br>
Configuration is pretty simple. A few public IP prefixes are
allowed to use these server as recursive resolver.
<br>
All other prefixes are no allowed to use them. The setup is up
for several years and works more or less without problems.<o:p></o:p></p>
<p>Now I have a case I have no explanation for.<br>
It's about a glue record and expired cache behavior: <span
style="font-family:"Ubuntu Mono"">
crane.smokva.net<br>
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.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Ubuntu Mono"">#dig
@ns2.ggamaur.net crane.smokva.net<br>
<br>
; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu
<<>> @ns2.ggamaur.net crane.smokva.net<br>
; (1 server found)<br>
;; global options: +cmd<br>
;; Got answer:<br>
;; ->>HEADER<<- opcode: QUERY, status: NOERROR,
id: 9174<br>
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0,
ADDITIONAL: 1<br>
<br>
;; OPT PSEUDOSECTION:<br>
; EDNS: version: 0, flags:; udp: 1232<br>
; COOKIE: f81401b79354e29b010000006809fd983d7daeae1c6bfada
(good)<br>
;; QUESTION SECTION:<br>
;crane.smokva.net. IN A<br>
<br>
;; ANSWER SECTION:<br>
crane.smokva.net. 26 IN A 85.10.196.166<br>
<br>
;; Query time: 1 msec<br>
;; SERVER: 213.160.40.34#53(ns2.ggamaur.net) (UDP)<br>
;; WHEN: Thu Apr 24 11:00:08 CEST 2025<br>
;; MSG SIZE rcvd: 89<br>
<br>
#dig @ns2.ggamaur.net crane.smokva.net<br>
<br>
; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu
<<>> @ns2.ggamaur.net crane.smokva.net<br>
; (1 server found)<br>
;; global options: +cmd<br>
;; Got answer:<br>
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL,
id: 26109 <---------------- Cache
expired<br>
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0,
ADDITIONAL: 1<br>
<br>
;; OPT PSEUDOSECTION:<br>
; EDNS: version: 0, flags:; udp: 1232<br>
; COOKIE: d2c192e8c153ff65010000006809fdc00ff4b74c1bc6a88a
(good)<br>
;; QUESTION SECTION:<br>
;crane.smokva.net. IN A<br>
<br>
;; Query time: 1 msec<br>
;; SERVER: 213.160.40.34#53(ns2.ggamaur.net) (UDP)<br>
;; WHEN: Thu Apr 24 11:00:48 CEST 2025<br>
;; MSG SIZE rcvd: 73</span><o:p></o:p></p>
<p><span
style="font-size:10.0pt;font-family:"Ubuntu Mono"">#dig
@ns2.ggamaur.net crane.smokva.net<br>
<br>
; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu
<<>> @ns2.ggamaur.net crane.smokva.net<br>
; (1 server found)<br>
;; global options: +cmd<br>
;; Got answer:<br>
;; ->>HEADER<<- opcode: QUERY, status: NOERROR,
id: 23097<br>
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0,
ADDITIONAL: 1<br>
<br>
;; OPT PSEUDOSECTION:<br>
; EDNS: version: 0, flags:; udp: 1232<br>
; COOKIE: 7573634154fc104a010000006809fdfe3b4159d1878e28be
(good)<br>
;; QUESTION SECTION:<br>
;crane.smokva.net. IN A<br>
<br>
;; ANSWER SECTION:<br>
crane.smokva.net. 300 IN A 85.10.196.166<br>
<br>
;; Query time: 11 msec<br>
;; SERVER: 213.160.40.34#53(ns2.ggamaur.net) (UDP)<br>
;; WHEN: Thu Apr 24 11:01:50 CEST 2025<br>
;; MSG SIZE rcvd: 89</span><o:p></o:p></p>
<p>In detail, wireshark shows me the following when a local
cache entry has expired.<o:p></o:p></p>
<p><span style="font-family:"Ubuntu Mono"">No.
Time Source
Destination Protocol Length
Info<br>
# query to local bind server<br>
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<br>
# server sends query to rootserver<br>
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<br>
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<br>
# server sends server failure as an answer to client<br>
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<br>
# answer from rootserver<br>
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<br>
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<br>
# server queries .net server<br>
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<br>
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<br>
# answer from .net server<br>
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<br>
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<br>
# server queries to crane.smokva.net <br>
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<br>
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<br>
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<br>
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</span><o:p></o:p></p>
<p><span style="font-family:"Ubuntu Mono"">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?</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span
style="font-family:"Ubuntu Mono"">Flo</span><br>
<br>
<o:p></o:p></p>
<p><o:p> </o:p></p>
</div>
</blockquote>
<br>
</body>
</html>