Maintained by: NLnet Labs

[Unbound-users] failing to stub an zone

martin f krafft
Tue Oct 21 17:15:26 CEST 2008

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

Is this something worth to consider, or are you saying that the
behaviour is as-is and unlikely to change?

martin | |
"my father, a good man, told me:
'never lose your ignorance; you cannot replace it.'"
                                               -- erich maria remarque
spamtraps: madduck.bogus at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature (see
URL: <>