Folks, I've probably made a stupid mistake somewhere, but I can't find
it. Cluehammer me please. I setup DNS-over-TLS ages ago at home but
rarely touch it, and I just went to take a look and it doesn't appear to
be available. (I should probably sort out some monitoring). I last
touched it last year to replace an expiring cert.
As far as I can tell, Unbound is built with support, it's configured
with `interface:` and `tls-port:` and the key/cert, but
`lsof -nPc unbound` shows it's not listening on 853.
It looks like unbound-checkconf doesn't like the `tls-` names, but does
take `ssl-` variants; an oversight?
OS is Ubuntu 20.04 (amd64); unbound is self-compiled 1.14.0.
I restarted with `verbosity: 5` and can see no mention of this port.
It appears to just be silently ignored and I'm not figuring out what I
messed up.
The cert is a P-256/prime256v1 one from a home CA, EKU allows for
web-server, I don't recall any docs saying anything special is needed in
a cert for DNS. The SANs in the cert include my home LAN IPs, home LAN
hostnames, etc.
What did I do wrong, please? (Besides only monitor port 53)
-Phil
I can't tell what is happening by what you shared but I do know that if the SSL context cannot be created it leads to a fatal error (Unbound does not start) and if a listening socket cannot be setup, it also leads to Unbound not being able to start.
Verbosity on 4 and above logs the listening socket creation phase.
You asked for a clue hammer so are you sure that the config file you edit is the one that Unbound reads when starting?
You can change the DNS port to something non-standard (port: 1234), or just use module-config: "iterator" and see if those changes are picked up on startup.
At this point I would check whether you have an older unbound
binary package installed, and where unbound-checkconf comes from,
whether it's the 1.14.0 version you built yourself or something
else.
# whence -vfa unbound
unbound is /opt/unbound/sbin/unbound
# whence -vfa unbound-checkconf
unbound-checkconf is /opt/unbound/sbin/unbound-checkconf
# dpkg -l | grep unbound
ii optunbound-unbound 1.14.0~pt1 amd64 unbound packaged for install into /opt/unbound
Verbosity on 4 and above logs the listening socket creation phase.
Well, I used verbosity 5 and it doesn't log anything for these.
# journalctl -o cat -u unbound | less
[...]
Starting Validating, recursive, and caching DNS resolver...
[1643423300] unbound[1177707:0] debug: increased limit(open files) from 1024 to 4176
[1643423300] unbound[1177707:0] debug: creating udp6 socket :: 53
[1643423300] unbound[1177707:0] debug: creating tcp6 socket :: 53
[1643423300] unbound[1177707:0] debug: creating udp4 socket 0.0.0.0 53
[1643423300] unbound[1177707:0] debug: creating tcp4 socket 0.0.0.0 53
[1643423300] unbound[1177707:0] debug: creating tcp6 socket ::1 8953
[1643423300] unbound[1177707:0] debug: creating tcp4 socket 127.0.0.1 8953
[1643423300] unbound[1177707:0] debug: setup SSL certificates
[1643423300] unbound[1177707:0] debug: chdir to /etc/unbound
[1643423300] unbound[1177707:0] debug: drop user privileges, run as unbound
[1643423300] unbound[1177707:0] debug: switching log to stderr
[...]
You asked for a clue hammer so are you sure that the config file you edit is
the one that Unbound reads when starting?
Yes. Notably, I didn't edit a config file here, I was inspecting what I
had to see why it wasn't working; I use local-zone/local-data to create
both .lan and .home.arpa zones (same content, auto-generated from the
same data source); `unbound-control list_local_zones` shows them, and
also:
This may be unlikely, but I saw something similar and when I tailed the logs, it was the fact I had the interface as 0.0.0.0. It couldn't bind the ports to that interface. I changed it to the server's ip / interface and it worked.
Found it: setting server.interface-automatic to "yes" causes the
DNS-over-TLS ports to not be opened.
My config has:
# Multiple IPv6 addresses, replies come from the wrong one without this
interface-automatic: yes
Recompiling with some additional logging at VERB_OPS let me see what was
happening. Setting that bool to "no" was sufficient to get unbound
listening on port 853.
I _think_ the interface-automatic setting was needed because these boxes
are also home container servers (via K3S) so interfaces dynamically
appear and disappear over time and I debugged some DNS failures to
wrong-origin responses without the setting.
Working from current git head, release-1.14.0-51-g10d98041:
[1643673519] unbound[178009:0] notice: listening_ports_open: auto AF_INET6, do_auto=1
[1643673519] unbound[178009:0] notice: listening_ports_open: auto AF_INET(4), do_auto=1
-- port 853 not opened, confirmed with lsof
setting "interface-automatic: no":
[1643673589] unbound[178948:0] notice: listening_ports_open[0]: is IPv4 [0.0.0.0] ssl_port=853
[1643673589] unbound[178948:0] notice: listening_ports_open[1]: is IPv6 [::0] ssl_port=853
[1643673589] unbound[178948:0] notice: listening_ports_open[2]: is IPv4 [0.0.0.0@853] ssl_port=853
[1643673589] unbound[178948:0] notice: listening_ports_open[3]: is IPv6 [::0@853] ssl_port=853
