strange behaviour with non-standard ports in stub-zone

[Luc Maisonobe]

Hello,

I am trying to configure unbound/nsd on a local network
and stumbled upon a strange behaviour.

Unbound is set up on the standard port 53 in order to be used
by all machines on the local network without any specific
configuration. It will use external servers for regular internet
connections and it will delegate to a local authoritative nsd server
for the local names (with stub-zone configuration), caching all results
regardless of their location.

Nsd is set up on the same machine as unbound, so it uses a non-standard
port and unbound is configured to use this non-standard port, using
the @port extension in the stub-addr entry within stub-zone.

In order to work around risks of single machine failures, this setup
is available on two hosts in the local network and zone transfers
have been configured between the two nsd servers. Nsd is therefore
configured to use a network interface that can be accessed remotely
(i.e. it is *not* set up on either 127.0.0.1 or ::1).

This seemed to me to be a classical setup.

With this setup, nsd works well, zone transfers work and if I query
it using "drill -p <the nsd port>", I get the answers I except for
the local hosts.

Unbound works well for hosts not belonging to my local network.

My problem is that if I query unbound (using "drill -p 53" to use the
stanbdard domain port), then I get NXDOMAIN errors on queries
related to my local network.

Looking at the unbound logs after having set verbosity to 4,
it seemed to me that unbound properly identified that the query was
related to a stub zone and properly queried the nsd server at the 
non-standard port as specified in the stub-zone configuration. This
connection worked, but seemed to have been used by unbound not to
get the address of the original query, but only to get the name server 
for the zone. Then, it seems as if unbound made a second query to the
name server for the original name. However, for this second query, it
did not use the port specified in stub-addr, but only shte standard port 
53. However, as both nsd and unbound are on the same server and as
port 53 has been dedicated to unbound whereas nsd was assigned a 
non-standard port, the second query was from unbound to itself, not from
unbound to nsd! I don't understand what happened next, it could have
been an infinite loop or anything. At the end I got a NXDOMAIN error.

I tried to remove the NS entries from the nsd zone file, as the zone
file in this case is not really intended to be widely available but
was only intended for unbound use, and unbound was specifically told
(using the stub-zone), which server to call and on which port. This did
not work.

The only way I was able to make it work was to move nsd on a
different machine and set the port to 53 in both nsd.conf and
in the unbound stub-zone. With this setup, unbound still
performed two requests (one using the configuration from the
stub zone and a second one from the name server it got from
nsd), and it succeeded.

I don't like this setup because it forces using two different
servers (or four if I also count the redundancy hosts), wastes
electric energy, looks more complex, is less robust to single
machine failure and it defeats the purpose of having the @port
syntax in stub-addr since this port is only used for the initial
connection but after that unbound forcibly uses port 53.

I am confused.

Could someone explain me what I am doing wrong? How could I
set up unboud+nsd so they run on the same machine, with nsd
configured so only unbound (and the redundant nsd for zone
transfers) connect to it and making sure unbound will use the
port specified in stub-addr when there is one?

I may try something like adding a specific IPV6 address (probably
a link-local one) for nsd and keep it on the same host, but this
looks weird: it looks like using IP addresses as if they were port
number, which is awkward.

best regards,
Luc