I have nsd3 serving on ::1 and unbound stubbing three zones to it.
Two of those zones work just fine, but the in-addr.arpa zone
I cannot get to work. Here is the configuration and the zone:
$ORIGIN @
86400 IN SOA ns hostmaster 155299844 7200 3600 604800 3600
86400 IN NS ns
ns 86400 IN A 127.0.0.1
ns 86400 IN AAAA ::1
[...]
I can query nsd3 fine with dig @::1.
When unbound forwards queries to the zone, however, it fails to send
them to nsd3, even though it seems like it found the delegation.
Upon startup, unbound seems to determine the delegation point just
fine:
also sprach W.C.A. Wijngaards <wouter@NLnetLabs.nl> [2008.10.21.1639 +0200]:
local-zone: "168.192.in-addr.arpa" nodefault
is the entry you need to remove the default NXDOMAIN for queries that
should not be sent to the greater internet by default.
This fixed the issue, while the more specific
local-zone: "14.168.192.in-addr.arpa" nodefault
did not. I can imagine why.
I'd say that it shouldn't be required. If 168.192.in-addr.arpa is
a default zone, then a stub-zone like 14.168.192.in-addr.arpa or
even 168.192.in-addr.arpa should override that, no?
I'd say that it shouldn't be required. If 168.192.in-addr.arpa is
a default zone, then a stub-zone like 14.168.192.in-addr.arpa or
even 168.192.in-addr.arpa should override that, no?
It is an entry in a different table internally. The local zones, stubs,
forwarders, have their own lookup tables. It seems to cause grief over
the forwarder/stub lookup as well.
Operators expect the most specific. But the application has a simple
ordering, first check local-zone, then check forwards, then stubs.
also sprach W.C.A. Wijngaards <wouter@NLnetLabs.nl> [2008.10.21.1706 +0200]:
It is an entry in a different table internally. The local zones, stubs,
forwarders, have their own lookup tables. It seems to cause grief over
the forwarder/stub lookup as well.
Operators expect the most specific. But the application has a simple
ordering, first check local-zone, then check forwards, then stubs.
Makes sense, and this is a common design pattern. One way to work
around it would be to return lists of matches and accumulate them
across all tables - none of these lookups would be costly. Then,
take the resulting set sorted by decreasing zone length and by
local/forwards/stubs for equal lengths, then simply use the first
entry.
Is this something worth to consider, or are you saying that the
behaviour is as-is and unlikely to change?