Julien Cristau wrote: > On 04/02/2017 10:07 AM, Robert Edmonds wrote: > > Julien Cristau wrote: > >> Package: unbound > >> Version: 1.6.0-3 > >> Severity: grave > >> > >> Hi, > >> > >> after upgrading from 1.6.0-2 to 1.6.0-3 unbound can't seem to be able to > >> resolve deb.debian.org. Upping the verbosity I get the feeling it's > >> alternating between querying deb.debian.org DS and static.debian.org DS, > >> never going up to debian.org DS. Downgrading makes things work again. > >> > >> Apr 2 15:49:55 tomate unbound: [685:0] info: resolving deb.debian.org. A > >> IN > >> Apr 2 15:49:55 tomate unbound: [685:0] info: resolving deb.debian.org. A > >> IN > >> Apr 2 15:49:55 tomate unbound: [685:0] info: resolving deb.debian.org. > >> DS IN > >> Apr 2 15:49:56 tomate unbound: [685:0] info: response for > >> deb.debian.org. DS IN > >> Apr 2 15:49:56 tomate unbound: [685:0] info: reply from <.> 4.2.2.1#53 > > > > Hi, Julien: > > > > Are you forwarding queries to 4.2.2.1? > > > Looks like it's in the domain-name-servers dhcp option on this network, > so yes (through dnssec-trigger). > > > Could you send your unbound.conf and any conf.d files and I'll try to > > replicate the problem? > > > unbound.conf says > include: "/etc/unbound/unbound.conf.d/*.conf" > > The entries in unbound.conf.d set "qname-minimisation: yes" and > "auto-trust-anchor-file: "/var/lib/unbound/root.key"" > > And then dnssec-trigger sets the forwarding.
Hi, Julien: It's very unlikely that this was a regression introduced in 1.6.0-3. The only change between 1.6.0-2 and 1.6.0-3 was to cherry-pick the updated root trust anchor for the upcoming DNSSEC root KSK rollover, which should have no impact on DNSSEC validation until that rollover actually begins. More likely, I would guess that there is some problem with the 4.2.2.1 resolver from your location that breaks DNSSEC validation, and when you downgraded to 1.6.0-2, the forwarding configuration got lost somehow and Unbound started performing full recursion. You can test whether forwarding is enabled for the running Unbound by running 'unbound-control forward' as root, which should print something like "4.2.2.1" or "off (using root hints)". If I recall correctly, Unbound requires that the upstream resolver itself perform DNSSEC validation, and the 4.2.2.1 nameserver doesn't perform DNSSEC validation, at least the instance that I queried. (The 4.2.2.x nameservers are anycasted.) You might try posting to the unbound-users mailing list (https://open.nlnetlabs.nl/mailman/listinfo/unbound-users) about your issue, since the upstream developers are generally pretty good about helping users debug DNSSEC validation issues. -- Robert Edmonds [email protected]
