I would appreciate a second pair of eyes on the below problem. I should say that I think I subsequently solved it by adding "stub-no-cache: yes" to the unbound config shown (early days, still monitoring it) but I would welcome any additional insight/opinion (and perhaps even suggestions as to if there are ways to improve the config).
Weird problem where I am getting an NXDOMAIN (per below) on my internal "bar.corp" domain.
My unbound config is as follows. If I do the same dig query directly against the stub resolvers, it works with no issue.
I should add that this is/was a long-standing config that was working fine for a long time until it mysteriously did not.
server:
interface: 127.0.0.1
# extra interface: entries removed for list post
Hi Laura,
I don't see something wrong with your configuration.
The
local-zone: "bar.corp" nodefault
is not needed because bar.corp is not one of the default zones; unless you use that domain as a placeholder here.
Which version of unbound is this?
Could you provide the 'unbound -V' output?
Is this reproducible in your case?
Best regards,
-- George
Hi George
Version 1.13.2
Configure line: --enable-allsymbols --with-ssl=/usr --with-libevent=/usr --with-libexpat=/usr --without-pythonmodule --with-chroot-dir=/var/unbound --with-pidfile= --with-rootkey-file=/var/unbound/db/root.key --with-conf-file=/var/unbound/etc/unbound.conf --with-username=_unbound --disable-shared --disable-explicit-port-randomisation --without-pthreads
Linked libs: pluggable-libevent 1.4.15-stable (it uses kqueue), LibreSSL 3.4.1
Linked modules: dns64 respip validator iterator
BSD licensed, see LICENSE in source package for details.
Report bugs to unbound-bugs@nlnetlabs.nl or https://github.com/NLnetLabs/unbound/issues