On Sat, Jul 26, 2014 at 07:34:16PM +0200, Sebastian Reitenbach wrote:
> On Saturday, July 26, 2014 17:35 CEST, Sonic <[email protected]> wrote:
>
> > On Sat, Jul 26, 2014 at 11:21 AM, Sonic <[email protected]> wrote:
> > > If you're just using a /24 as your access-control seems to indicate
> > > try replacing the above with (this works great for me):
> > > local-zone: "0.0.10.in-addr.arpa." transparent
> > >
> > > and update the stub-zone name to read:
> > > name: "0.0.10.in-addr.arpa."
> >
> > And, of course you NSD zone name must be:
> > zone:
> > name: "0.0.10.in-addr.arpa"
> > zonefile: "10.0.0.zone"
> >
> > (although the zonefile doesn't have to strictly be named as such)
>
> I indeed only use a /24, so I changed as you suggested, and it seems to help.
> But the problem was not apparrent all the time, will monitor it, if it comes
> back with this new configuration, hope not.
> Anyways, I still find it odd, that it worked only halfway with the other
> configuration I had before, and a simple restart of unbound fixed it.
>
My understanding is that "transparent" is used when you want to override
certain records in a zone with local-data configured in unbound.conf.
Given that you have no such things in the pasted configuration
"nodefault" is probably a better choice.
How is/was the reverse zone configured in nsd? I am currently trying to
debug an issue i've seen when the stub-zone in unbound is wider ("name:
"10.in-addr.arpa") than the zone in nsd (name: "0.0.10.in-addr.arpa").
To me the following is seen:
# dig @127.0.0.1 -x 10.0.0.1 <-- works
# dig @127.0.0.1 -x 10.0.0.2 <-- fails
# dig @127.0.0.1 -x 10.0.0.3 <-- works
# dig @127.0.0.1 -x 10.0.0.4 <-- works
Basically the first lookup works, the second ends up at IANA (as if the
stub-zone configuration did not exist), and any
following lookups work again.
It might be considered bad to tell unbound a server is authorative for a
wider zone than it actually is though, can this be the same problem you
saw?
Regards,
Patrik Lundin
