[Unbound-users] Unbound fails to stub-zone to localhost
davidb at verisign.com
Tue Oct 21 13:40:57 UTC 2008
On Oct 21, 2008, at 8:43 AM, martin f krafft wrote:
> also sprach W.C.A. Wijngaards <wouter at NLnetLabs.nl> [2008.10.01.1528
>> 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: 127.0.0.1 at 10053 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
> 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
David Blacka <davidb at verisign.com>
Sr. Engineer VeriSign Platform Product Development
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3899 bytes
Desc: not available
More information about the Unbound-users