Oddity with nsd-based in-addr.arpa zone

Wed Aug 2 12:17:23 UTC 2017

As I noted earlier, I do have a nsd zone named 168.192.in-addr.arpa, but 
your comments got me to thinking that perhaps what's missing is some kind 
of data at the 168.192.in-addr.arpa level. Just now, I edited the zone to 
add a TXT record at the top. It now looks like this:

$TTL 3D
@        SOA   ...
          NS    ...
          NS    ...
          TXT   "some text"    ; <=== NEW!!!

$ORIGIN 1.168.192.in-addr.arpa.
1        PTR    ...
          ...

Then, I reconfigured unbound to treat it as a stub-zone instead of a 
forward-zone:

stub-zone:
      name: "168.192.in-addr.arpa"
      stub-addr: 192.168.1.5 at 5053

Success! No lame queries or timeouts.

Thanks,
Dave

>> 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    ...
>>     ...

On Wed, 2 Aug 2017, W.C.A. Wijngaards via Unbound-users wrote:

> 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
>
>
>

-- 
Dave Ulrick
Email: d-ulrick at comcast.net