Oddity with nsd-based in-addr.arpa zone

[W.C.A. Wijngaards]

Hi Dave,

What must be happening is that your authority server for the combine
192.168 stub clause, does not actually host a 192.168 reverse zone.  And
that causes unbound to detect that the delegation is lame.  Lameness
check only performed for authoritative servers (i.e. stub zones).  And
now that unbound has classified this server as lame it won't ask any more.

What you would need to do is actually host a zone with the name of the
stub zone on NSD.  In this case 168.192.in-addr.arpa.  Put in an empty
zonefile (or nearly empty, with no PTR data), for example.  This in
addition to your other zonefiles for 1.168.192, or 100.168.192 and so
on. This makes NSD answer authoritatively (and non-lame) for the zone
and thus no lameness for unbound and the stub clause works.

Best regards, Wouter

On 01/08/17 21:06, Dave Ulrick via Unbound-users wrote:
> I'm using Unbound & nsd to provide DNS services on my home LAN. nsd
> listens on udp/5053 and acts as authoritative DNS server for a forward
> zone (home.du) and a reverse zone (168.192.in-addr.arpa). The forward
> zone works well as an Unbound 'stub-zone' but I've run into some
> strangeness with the reverse zone.
> 
> Most of my IPs are in 192.168.1.x but I have a few IPs in other
> 192.168.x.x subnets: 192.168.56.x and 192.168.100.x in particular.
> 
> Assuming that I have this statement in unbound.conf:
> 
> local-zone: "168.192.in-addr.arpa." nodefault
> 
> I get good resolver performance if I create separate nsd zones for:
> 
> 1.168.192.in-addr.arpa
> 56.168.192.in-addr.arpa
> 100.168.192.in-addr.arpa
> 
> which are defined like this in nsd.conf:
> 
> zone:
>       name: "1.168.192.in-addr.arpa"
>       zonefile: "1.168.192.in-addr.arpa.zone"
> 
> and define them to Unbound like so:
> 
> stub-zone:
>     name: "1.168.192.in-addr.arpa"
>     stub-addr: 192.168.1.5 at 5053
> 
> stub-zone:
>     name: "56.168.192.in-addr.arpa"
>     stub-addr: 192.168.1.5 at 5053
> 
> stub-zone:
>     name: "100.168.192.in-addr.arpa"
>     stub-addr: 192.168.1.5 at 5053
> 
> but given that my DNS setup is so small I'd really rather just have one
> reverse zone:
> 
> 168.192.in-addr.arpa
> 
> defined in nsd like:
> 
> zone:
>       name: "168.192.in-addr.arpa"
>       zonefile: "168.192.in-addr.arpa.zone"
> 
> This consolidated zone is structured thusly:
> 
> $TTL 3D
> @        SOA    ...
>         NS    ...
>         NS    ...
> 
> $ORIGIN 1.168.192.in-addr.arpa.
> 1    PTR    ...
>     ...
> 
> $ORIGIN 56.168.192.in-addr.arpa.
> 1    PTR    ...
>     ...
> 
> $ORIGIN 100.168.192.in-addr.arpa.
> 1    PTR    ...
>     ...
> 
> Given this consolidated zone, nsd promptly answers queries that are
> directly sent to it such as with 'nslookup -port=5053 - 0.0.0.0'.
> However, if I configure the zone in unbound.conf like this:
> 
> stub-zone:
>     name: "168.192.in-addr.arpa"
>     stub-addr: 192.168.1.5 at 5053
> 
> the queries are _not_ resolved. However, if I define the zone as a
> forward-zone it works perfectly (all queries are replied to either
> positively or negatively in a prompt manner):
> 
> forward-zone:
>     name: "168.192.in-addr.arpa"
>     forward-addr: 192.168.1.5 at 5053
> 
> Note that adding the trailing '.' to the zone name in the Unbound or nsd
> configuration files appears to have no functional or performance effect.
> (Of course, the zone files themselves _do_ use trailing '.' at the end
> of each name.)
> 
> My understanding is that a 'stub-zone' is to be used for authoritative
> zones whereas a 'forward-zone' is to be used if recursive lookups might
> occur. Given that nsd is purely an authoritative DNS server, it doesn't
> make sense that I'd get bad results with 'stub-zone' but good results
> with a 'forward-zone'. In fact, using a 'forward-zone' for an nsd-hosted
> zone doesn't make any sense at all!
> 
> An Internet search reveals that many others have had issues with
> configuring reverse zones but nobody seems to have ended up with my
> exact configuration. Therefore, I thought I ought to run this by the
> Unbound experts to see if you can shed any light on this.
> 
> Thanks,
> Dave


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20170802/4e032ccf/attachment.bin>