forward-zone and fail over

[Daniel Jakots]

Good morning,

I'm currently thinking about using unbound on each of my servers instead
of relying of the servers' providers resolvers. I'm not really happy
with the idea of all the unbound querying the root dns servers as it
could use some cache.

I thought about using one server with unbound and then install unbound
on each server (and setting the resolv.conf to localhost) and forward
requests to that main resolver. Of course I don't want to have a broken
dns if that host would stop working and I thought about
"forward-first" parameter.

The goal is to use the cache and if it's not working to fallback
transparently to querying the root servers directly.

So far, any opinion on that idea? Do I understand correctly what
"forward-first: yes" is for?



I happened to run Unbound on my laptop with a forward-zone for "." so I
tried the fallback mechanism on it (full config inlined at the end of
the email). Excerpt from -h:
Version 1.9.0
linked libs: pluggable-libevent 1.4.15-stable (it uses kqueue),
LibreSSL 2.9.0 linked modules: dns64 respip validator iterator
(it's on OpenBSD -current). FWIW the real setup I described would run
ubuntu 18.04.

The relevant part of my unbound config is:
forward-zone:
        name: "."                               # use for ALL queries
        forward-tls-upstream: yes
        forward-addr: 203.0.113.47 at 443#subdomain.example.com
        forward-first: yes

I blocked the upstream resolver with its firewall and tried both "block
drop" and "block return" (with pf(4)) but it didn't seem to change the
behaviour.

The first thing I noticed is that since I'm using DoT, when it tries
to fall back it looks like it tries with DoT as well... which doesn't
work very well as, AFAIK, root servers don't support (yet?) DoT.

I disabled my forward-tls-upstream and retried. It eventually falls back
but it's very slow. For instance if I run dig (DiG 9.4.2-P2, I didn't
try with drill but I don't think it would help my case, would it?) it
times out. If I rerun dig shortly after, it quickly gets the IP. This
works good as long as it's in the local cache. If I rerun dig for
another domain, the same thing happens, i.e. unbound doesn't seem to
learn about the upstream resolver being out of service.


Can anyone reproduce those behaviours? Are they to be expected?


Cheers,
Daniel


# $OpenBSD: unbound.conf,v 1.14 2018/12/16 20:41:30 tim Exp $

server:
	interface: 127.0.0.1
	#interface: 127.0.0.1 at 5353	# listen on alternative port
	do-ip6: no

	# override the default "any" address to send queries; if multiple
	# addresses are available, they are used randomly to counter spoofing
	#outgoing-interface: 192.0.2.1
	#outgoing-interface: 2001:db8::53

	access-control: 0.0.0.0/0 refuse
	access-control: 127.0.0.0/8 allow_snoop
	access-control: ::0/0 refuse
	access-control: ::1 allow

	hide-identity: yes
	hide-version: yes

	# Uncomment to enable DNSSEC validation.
	#
	#auto-trust-anchor-file: "/var/unbound/db/root.key"
	#val-log-level: 2

	# Uncomment to synthesize NXDOMAINs from DNSSEC NSEC chains
	# https://tools.ietf.org/html/rfc8198
	#
	#aggressive-nsec: yes

	# Serve zones authoritatively from Unbound to resolver clients.
	# Not for external service.
	#
	#local-zone: "local." static
	#local-data: "mycomputer.local. IN A 192.0.2.51"
	#local-zone: "2.0.192.in-addr.arpa." static
	#local-data-ptr: "192.0.2.51 mycomputer.local"

	# UDP EDNS reassembly buffer advertised to peers. Default 4096.
	# May need lowering on broken networks with fragmentation/MTU issues,
	# particularly if validating DNSSEC.
	#
	#edns-buffer-size: 1480
	#include: /var/unbound/etc/adblock.conf

	# Use TCP for "forward-zone" requests. Useful if you are making
	# DNS requests over an SSH port forwarding.
	#
	#tcp-upstream: yes
	tls-cert-bundle: /etc/ssl/cert.pem

remote-control:
	control-enable: yes
	control-interface: /var/run/unbound.sock


# Use an upstream forwarder (recursive resolver) for some or all zones.
#
forward-zone:
	name: "somerandomdomain.com."
	forward-addr: 172.16.210.1
	#forward-addr: 172.16.210.11
forward-zone:
	name: "."				# use for ALL queries
	forward-tls-upstream: yes
	forward-addr: 203.0.113.47 at 443#subdomain.example.com
	forward-first: yes