On Oct 21, 2008, at 8:43 AM, martin f krafft wrote:
also sprach W.C.A. Wijngaards <[EMAIL PROTECTED]> [2008.10.01.1528 +0200]:Unbound will send to the servers named in the NS set in preference to the configured 127.0.0.1.Why does it do this? What's the design decision? It seems wrong to have unbound redirect queries for a zone to e.g. localhost, then ask localhost for the zone's NS record, resolve that, and then direct all other queries there instead, effectively ignoring the explicit redirect/stub/forward instruction.
I assume this conversation was about stub zones, as forward zones would redirect queries to the address you configured.
I expect that the behavior of the stub zone feature is my fault. I made stub zones work, basically, like they worked in BIND. That is, the stub zone would use the values of the NS rrset on the configured server (for the zone in question) to resolve queries. I recall several reasons for implementing it this way:
1) for better or worse, it was how stub zones worked in the only implementation that I had access to, BIND, and I figured that this is how anyone who had used stub zones before would expect them to work,
2) I thought that there might be some operational reason why stub zones should work this way, even though I didn't know what it was, and
3) the design fit fairly well in to the algorithm. That is, it didn't create a special, TTL-less, artifical NS rrset in the cache.
This may help you. In svn trunk I recently fixed unbound so that you can run with stub-addr: [EMAIL PROTECTED] with NSD running on port 10053 on localhost. When you use the '@' for port notation (in the svn trunk version) the NS record set is not used in preference.This feels like a hack to me. Shouldn't it possibly be the other way around? By default, ignore the NS set (or at least don't require it), unless a special flag is set to make it recurse NS records and forward queries to the NS configured in the zone?
In retrospect, I agree with this. It is more natural for stub zones to always resolve via the configured addresses. I think changing the default behavior will make stub zones easier to understand and easier to use.
-- David Blacka <[EMAIL PROTECTED]> Sr. Engineer VeriSign Platform Product Development
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
