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: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature (see http://martin-krafft.net/gpg/) URL: <http://unbound.nlnetlabs.nl/pipermail/unbound-users/attachments/20081021/ccc2b7a0/attachment.pgp>