[Unbound-users] Unbound fails to stub-zone to localhost

[David Blacka]

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  
> +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: 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
>> 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                          <davidb at verisign.com>
Sr. Engineer          VeriSign Platform Product Development

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3899 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20081021/e568cab3/attachment.bin>