Oddity with nsd-based in-addr.arpa zone

[Dave Ulrick]

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
d-ulrick at comcast.net