also sprach W.C.A. Wijngaards <[EMAIL PROTECTED]> [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: [EMAIL PROTECTED]
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
_______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
