Custom resolv.conf Options
I run unbound in forwarding mode for DNS over TLS, and maintain two VPN client connections over which DNS traffic is routed. So I have four DNS servers configured in System > General Setup, with two of those servers set to use the first tunnel and the other two set to use the second. I've noticed, though, that when one of the tunnels goes down, DNS seems to go down as well. With the realization that I may be barking up entirely the wrong tree, I found the following potentially interesting information on calomel.org:
However, I'm not aware of any easy way to add custom options to resolv.conf (i.e. nothing like loader.conf.local). Using the shellcmd package, though, seems to achieve the desired effect via the following rule:
At least, that achieves the desired modification to resolv.conf following a filter reload. So mostly I'm wondering:
- Is this method of adding custom options to resolv.conf dumb and/or stupid and/or dangerous?
- Is changing the specific options that I'm changing also any of the above adjectives and/or pointless?
The firewall itself should be hitting Unbound for DNS, so you should have
127.0.0.1as the first
nameserverline, which should render the other lines and options moot.
When using forwarding mode, Unbound tracks the quality and reachability of the servers you list independently and uses whichever one it thinks it can get a response from the fastest.
Thanks Jim, that makes sense. If I may tack on one additional related question . . . any idea why I might regularly be seeing terrible ping times on the DNS servers I list in "Status > DNS Resolver"? I'll often see ping times > 1s that I can't corroborate by pinging manually. As an example, just now the status showed as:
But for all three servers showing ping times of over a second, manual pings - even when run for a few minutes - never got over ~90ms (and averaged < 30ms). Those manual pings were also run through my VPN client tunnels, to rule out extra latency induced by them.
IIRC the pings it's talking about are not ICMP but in the DNS protocol itself. It may be slower to respond to a TCP TLS request than an ICMP echo.
Ah okay, that would explain it, thanks!