On Sunday, July 27, 2014 11:20 CEST, Patrik Lundin
<patrik.lundin....@gmail.com> wrote:
> On Sat, Jul 26, 2014 at 07:34:16PM +0200, Sebastian Reitenbach wrote:
> > On Saturday, July 26, 2014 17:35 CEST, Sonic <sonicsm...@gmail.com> wrote:
> >
> > > On Sat, Jul 26, 2014 at 11:21 AM, Sonic <sonicsm...@gmail.com> 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?
Yes, I think that's how I had it too, but with "nodefault" instead of
"transparent".
For the requests that failed, I've seen requests going out to the root DNS
servers trying to resolve my private IPs.
In unbound, I only had the 10.in-addr.arpa and in nsd I have
0.0.10.in-addr.arpa.
I only had to change unbound configuration as suggested, which up to now
seems to work reliable.
And when you restart unbound, then dig for 10.0.0.2 might start working,
and digging others may fail. IIRC, after a restart, the first one or two
reverse
records I looked up, then worked as expected, others then started to fail,
that worked before. Only very seldomly, all reverse lookups worked
after a restart of unbound.
Sebastian
>
> Regards,
> Patrik Lundin
