[Unbound-users] failing to stub an in-addr.arpa zone

[martin f krafft]

also sprach W.C.A. Wijngaards <wouter at 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?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"my father, a good man, told me:
'never lose your ignorance; you cannot replace it.'"
                                               -- erich maria remarque
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20081021/ccc2b7a0/attachment.bin>