Hello Unbound-Users! I hope all is well with everybody today and I would really appreciate any information that you could provide regarding the issue description below.
I didn't know whether this issue was a bug or a miss-configuration, and as such I decided to send this email to the Unbound community for guidance first before opening this in a GitHub ticket. Basically, I have 3 Slackware-based DNS servers running both Unbound 1.13.1 and BIND: user@ns1:/var/conf# unbound -v [1650373683] unbound[3573:0] notice: Start of unbound 1.13.1. I host numerous internal Authoritative DNS zones on all 3 DNS servers (ns1, ns2 and ns3) in BIND, and use "stub-zone" declarations in unbound.conf to forward DNS requests to the BIND service for internal domain resolution. However, last Friday (15th April) I noticed that unbound on ns1 would respond with NXDOMAIN for one of my domains (example.cso), but the rest of the domains would work, and the same example.cso domain would be resolved correctly on ns2 and ns3. After restarting the unbound service on ns1, queries for example.cso would begin to work again for a short amount of time (5-10 minutes) before going back to being answered with "NXDOMAIN". I did a tcpdump to see what was happening with the responses, as I thought they may have been going to the root servers wrongly, but all I saw was the initial query from the client, and then a response straight back from unbound to the client device with "NXDOMAIN" - almost suggesting that "NXDOMAIN" had been cached as a response or something along those lines? My stub-zone configuration in unbound.conf was as follows: stub-zone: name: example.cso stub-addr: 127.0.0.1@10053 It still is like this on ns2 and ns3, which work perfectly. To prevent responses for example.cso resulting in "NXDOMAIN" again, I added the "stub-no-cache: yes" config line to the example.cso stub-zone declaration shown below: stub-zone: name: example.cso stub-addr: 127.0.0.1@10053 stub-no-cache:yes After restarting unbound on ns1, queries for the example.cso internal domain began working again (and have been for the past few days.) The only reason I tried the "stub-no-cache" option is because of a mailing list entry by another individual, who reported the same issue to unbound-users on the 7th of Feb 2022: https://marc.info/?l=unbound-users&m=164424786232259&w=2 Do you know why this could have possibly occurred after the previous configuration was working for years? Furthermore, do you know whether this issue was raised and fixed already by the Devs? I'm not sure why this would occur out of the blue, but any answers as to whether I should raise this on GitHub as a ticket would be much appreciated. Thank you all so much for taking the time to read this! Kind Regards, ________________________________ Callum Key
