Date: Mon, 30 Jun 2014 09:42:48 +1000 From: Mark Andrews <marka@isc.org> To: Peter Wemm <peter@wemm.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, freebsd-stable@freebsd.org, Dmitry Morozovsky <marck@rinet.ru> Subject: Re: stable/10: unbound refuses to forward some DNS queries Message-ID: <20140629234248.EA4D419753E2@rock.dv.isc.org> In-Reply-To: Your message of "Sun, 29 Jun 2014 14:56:58 -0700." <4052053.k3ny9DzFll@overcee.wemm.org> References: <alpine.BSF.2.00.1406291514140.36231@woozle.rinet.ru> <alpine.BSF.2.00.1406291933560.36231@woozle.rinet.ru> <alpine.BSF.2.00.1406292002370.36231@woozle.rinet.ru> <4052053.k3ny9DzFll@overcee.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <4052053.k3ny9DzFll@overcee.wemm.org>, Peter Wemm writes:
> On Sunday 29 June 2014 20:04:29 Dmitry Morozovsky wrote:
> > On Sun, 29 Jun 2014, Dmitry Morozovsky wrote:
> > > Thank you so much, it works like a charm.
> > >
> > > I do not have special TLD for forward resolving, and for me the
> following
> > >
> > > subset seems to be enough:
> > > #suggested by kib@
> > > domain-insecure: "168.192.in-addr.arpa."
> > > local-zone: "168.192.in-addr.arpa." transparent
> >
> > ... and it turned out that even the last line is optional.
> >
> > To clarify: ALL queries for my case should be forwarded.
> >
> > It's on FreeBSD 10.0-STABLE #4 r267602: Wed Jun 18 11:15:36 MSK 2014
>
> I use 'nodefault' instead of 'transparent' for these.
>
> I'm pretty sure you do need it because unbound has the RFC1918 and other
> "fake" addresses stubbed out. If you only did a 'reload' after changing
> it, the stubs would have been replaced with a live address. I'd expect a
> full kill/restart to not work without it.
>
> You need the domain-insecure for 168.192.in-addr.arpa because there is a
> NSEC3 hash on 192.in-addr.arpa that has a 'proof of non existence' for the
> 192.168 node underneath.
168.192.in-addr.arpa is insecurely delegated to the AS112 servers.
This breaks the secure delegation chain. RFC 6303 requires this
insecure delegations for all the zones it lists so that serving
local content doesn't fail due to DNSSEC validation. I believe all
the RFC 6303 zones now have insecure delegations. I had to complain
to IANA that some didn't exist initially. The RFC 1918 subset
definitely do have insecure delegations.
No nameserver from any vendor should require validation to be
explicitly disabled for 168.192.in-addr.arpa or any of the rest of
the RFC 1918 / RFC 6303 zones. If unbound requires such a setting
it is broken.
> For what its worth, this is the general gist of what we do on the
> freebsd.org cluster with some use of RFC1918 addresses:
>
> Individual machines:
> server:
> ...
> domain-insecure: "10.in-addr.arpa"
> local-zone: "10.in-addr.arpa." nodefault
> ...
> forward-zone:
> # Forward to the cluster caching hub
> name: .
> forward-addr: 2001:4f8:3:ffe0:4064:0:35:1
> forward-addr: 2001:4f8:3:ffe0:4064:0:35:2
> forward-addr: 149.20.53.9
> forward-addr: 149.20.53.10
>
> And one of the corresponding cache hubs:
> server:
> ...
> domain-insecure: "10.in-addr.arpa"
> local-zone: "10.in-addr.arpa." nodefault
> ...
> stub-zone:
> name: "10.in-addr.arpa"
> stub-addr: 149.20.53.9@5301 # local authoritive-only zone server
> stub-addr: 149.20.53.10@5301 # local authoritive-only zone server
> ...
>
> Obviously this would need to be adjusted for whatever RFC1918 addresses
> you're using locally. But that's how we use the built-in local_unbound
> resolver for dogfood in the freebsd.org cluster.
If you forward the entire namespace then the forwarder should be
serving the RFC 6303 zones not the local recursive resolver.
Forwarding ("forward only" in named terms) is equivalent to serving
the zone locally. Note named takes forwarding (existance and
forwarding mode) into consideration when deciding whether to enable
a RFC 6303 zone or not.
Mark
> --
> Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com;
> KI6FJV
> UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140629234248.EA4D419753E2>