
<!DOCTYPE html><html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8" /></head><body><div data-html-editor-font-wrapper="true" style="font-family: arial, sans-serif; font-size: 13px;">I have configured a stub-zone to delegate requests for a particular domain (mytest) to another instance of Unbound, which serves the requests from a Python module (returning an NS record with the nameserver who can handle the A record request).<br><br>In this particular instance we are testing behaviour when the last DNS server in the chain is not reachable.<br><br><br>Heres the flow:<br><br><span style="font-family:Courier New,Courier,monospace;">[local Unbound(172.16.198.20)] -> [mytest Unbound (172.20.0.1)] -> [ unreachable (172.21.0.1) ]</span><br><br><span style="font-family:Arial,Helvetica,sans-serif;">I use the following command to test:</span><br><br><span style="font-family:Courier New,Courier,monospace;">#dig -4 @172.16.198.20 mytest.example.mytest</span><br><br>It works great, when I first start it up - wireshark shows the following DNS packets:<br><br><span style="font-family:Courier New,Courier,monospace;"> 7 3.805095 172.16.198.20 → 172.16.198.20 DNS 94 Standard query 0x4741 A mytest.example.mytest OPT<br> 8 3.805328 172.20.0.1 → 172.20.0.1 DNS 94 Standard query 0xbd82 A mytest.example.mytest OPT<br> 9 3.805913 172.20.0.1 → 172.20.0.1 DNS 127 Standard query response 0xbd82 A mytest.example.mytest NS ns.mytest.example.mytest A 172.21.0.1 OPT<br> 10 3.806112 172.16.198.20 → 172.21.0.1 DNS 94 Standard query 0x5769 A mytest.example.mytest OPT<br> 13 4.182941 172.16.198.20 → 172.21.0.1 DNS 94 Standard query 0xa7be A mytest.example.mytest OPT<br> 14 4.559900 172.16.198.20 → 172.21.0.1 DNS 94 Standard query 0xafa9 A mytest.example.mytest OPT<br> 17 5.313861 172.16.198.20 → 172.21.0.1 DNS 94 Standard query 0x31f7 A mytest.example.mytest OPT<br> 20 6.067457 172.16.198.20 → 172.21.0.1 DNS 94 Standard query 0x6245 A mytest.example.mytest OPT<br> 21 7.574350 172.16.198.20 → 172.21.0.1 DNS 94 Standard query 0xb9ef A mytest.example.mytest OPT<br> 24 9.082170 172.16.198.20 → 172.21.0.1 DNS 94 Standard query 0xe275 A mytest.example.mytest OPT<br> 27 12.092103 172.16.198.20 → 172.21.0.1 DNS 94 Standard query 0x9261 A mytest.example.mytest OPT<br> 32 15.103658 172.16.198.20 → 172.21.0.1 DNS 83 Standard query 0x4a32 A mytest.example.mytest<br> 33 16.106309 172.20.0.1 → 172.20.0.1 DNS 97 Standard query 0x6af6 A ns.mytest.example.mytest OPT<br> 34 16.107670 172.20.0.1 → 172.20.0.1 DNS 113 Standard query response 0x6af6 A ns.mytest.example.mytest A 172.21.0.1 OPT<br> 35 16.108060 172.16.198.20 → 172.16.198.20 DNS 94 Standard query response 0x4741 Server failure A mytest.example.mytest OPT<br> 36 16.108079 172.16.198.20 → 172.16.198.20 ICMP 122 Destination unreachable (Port unreachable)</span><br><br><br>As you can see the 'local' Unbound attempts to query 172.21.0.1 for the A record. It retries because nothing is listening and eventually give us a SERVFAIL.<br><br>Now here is the 'strange' thing - <br><br>If I make an initial query for www.google.com, the subsequent behaviour of the command above changes<br><br><span style="font-family:Courier New,Courier,monospace;"> 3 0.000070 172.16.198.20 → 172.16.198.20 DNS 94 Standard query 0x3fac A mytest.example.mytest OPT<br> 4 0.000436 172.20.0.1 → 172.20.0.1 DNS 94 Standard query 0xc2af A mytest.example.mytest OPT<br> 5 0.001877 172.20.0.1 → 172.20.0.1 DNS 127 Standard query response 0xc2af A mytest.example.mytest NS ns.mytest.example.mytest A 172.21.0.1 OPT<br> 6 0.002201 172.16.198.20 → 172.21.0.1 DNS 94 Standard query 0x3bb7 A mytest.example.mytest OPT<br> 7 0.378956 172.16.198.20 → 172.21.0.1 DNS 94 Standard query 0x7ab2 A mytest.example.mytest OPT<br> 8 0.755943 172.16.198.20 → 172.21.0.1 DNS 94 Standard query 0xef10 A mytest.example.mytest OPT<br> 9 1.509470 172.16.198.20 → 172.21.0.1 DNS 94 Standard query 0x2777 A mytest.example.mytest OPT<br> 10 2.263616 172.16.198.20 → 172.21.0.1 DNS 94 Standard query 0x0514 A mytest.example.mytest OPT<br> 11 3.769610 172.16.198.20 → 172.21.0.1 DNS 94 Standard query 0xc9e9 A mytest.example.mytest OPT<br> 14 5.276551 172.16.198.20 → 172.21.0.1 DNS 94 Standard query 0x647c A mytest.example.mytest OPT<br> 15 8.288567 172.16.198.20 → 172.21.0.1 DNS 94 Standard query 0x90f2 A mytest.example.mytest OPT<br> 16 11.300684 172.16.198.20 → 172.21.0.1 DNS 83 Standard query 0x1e24 A mytest.example.mytest<br> <strong>17 12.307535 172.16.198.20 → 193.0.14.129 DNS 97 Standard query 0x704f A ns.mytest.example.mytest OPT<br> 18 12.327889 193.0.14.129 → 172.16.198.20 DNS 1082 Standard query response 0x704f No such name A ns.mytest.example.mytest SOA a.root-servers.net RRSIG NSEC aaa RRSIG NSEC mz RRSIG OPT</strong><br> 19 12.328306 172.16.198.20 → 172.16.198.20 DNS 94 Standard query response 0x3fac Server failure A mytest.example.mytest OPT<br> 20 12.328320 172.16.198.20 → 172.16.198.20 ICMP 122 Destination unreachable (Port unreachable)</span><br><br>As you can see, even though requests for .mytest should be directed to 172.20.0.1 (as seen in packet 33 of the first trace) the request for the ns.mytest.example.mytest in the second trace (packet 17) is sent to one of the configured root servers.<br>The net effect is that the client (dig) receives NXDOMAIN, instead of SERVFAIL.<br><br>Unbound configuration is as follows:<br><br><span style="font-family:Courier New,Courier,monospace;">server:<br> verbosity:5<br> do-ip6:no<br> interface: 172.16.198.20<br> module-config: "iterator"<br><br> do-ip4: yes<br> do-udp: yes<br> do-daemonize: yes<br> access-control: 172.16.198.0/8 allow<br> chroot: ""<br> use-syslog: yes<br> log-time-ascii: yes<br> log-queries: yes<br> local-zone: "mytest" nodefault<br><br>remote-control:<br> control-interface: 172.16.198.20<br> control-enable: yes<br><br>stub-zone:<br> name: "mytest"<br> stub-addr: 172.20.0.1</span><br><br><br>In the logs, the main significant difference I see is a missing statement in the failed case:<br><br><span style="font-family:Courier New,Courier,monospace;">info: use stub mctest. NS IN</span><br><br>also all of the root severs are listed as DelegationPoints<br><br>Any help appreciated - perhaps this is a bug?<br><br><br>Many thanks<br><br>Nick<br><br><br><br><signature></signature> </div></body></html>