inconsistent forward-zone behavior between config files, unbound-control

[Robert Edmonds]

A. Schulze via Unbound-users wrote:
> Am 22.09.2015 um 19:02 schrieb Mike Brown via Unbound-users:
> >* by default, queries go to my ISP's resolvers (Comcast: 75.75.75.75 &
> >75.75.76.76)
> why would you do that?

Comcast's 75.75.75.75 and 75.75.76.76 nameservers are anycasted.
75.75.75.75 in particular should (probably) be routed to a nearby
Comcast data center.

For instance, on my home Comcast connection, 75.75.75.75, F-Root, and
L-Root all have anycast instances located in a local Comcast facility,
so the RTT to these three servers are identical (~10 ms) for me.

Comcast's servers perform DNSSEC validation and it should in theory be
possible to have a validating DNS server like Unbound forward to those
servers and re-validate the answers, so for a lightly loaded server it
may actually result in *better* performance (latency wise) to forward to
the nearby Comcast cache rather than directly contacting authoritative
nameservers that may be much farther than ~10 ms away.

> Also I'm not aware any unbound configuration is modified in any way by a DHCP client.
> I use to ignore any resolver announced by a DHCP server:

The stock upstream Unbound distribution does not have any DHCP client
integration, true.  However, some OSes (e.g. Debian) have optional
resolvconf integration, which can be used to automatically configure
nameservers learned via DHCP as forwarders for Unbound.  Other OSes may
have similar functionality.  This only works well if those nameservers
perform DNSSEC validation, however.

-- 
Robert Edmonds
edmonds at debian.org