On Thu, 21 Mar 2013, W.C.A. Wijngaards wrote:
Not for stub-prime, the newly introduced behaviour for 'normal
referrals' is to check at the parent as a last resort to get
information. When you add a stub-zone with stub-prime yes, then this
also activates.
Based on the current documentation, I would expect this to only activate
with stub-first.
Stub-zone's stated purpose is "to configure authoritative data to be used by
the resolver that cannot be accessed using the public internet servers.
This is useful for company-local data or private zones." Thus I expect it to
never try to start at the roots, otherwise there's no point to using
stub-zone for private data.
Stub-prime claims that it "performs NS set priming, which is similar to root
hints, where it starts using the list of nameservers currently published by
the zone. Thus, if the hint list is slightly outdated, the resolver picks
up a correct list online." I had assumed the correct list would only come
from the listed stub-host or stub-addr, not that this implies the fallback
behavior described under stub-first.
Because it does not failover to the parent as a last resort.
How does "stub-prime: yes, stub-first: no" differ from "stub-prime: yes,
stub-first: yes", if the former falls back to using the roots? Doesn't
"stub-first: no" tell it to not do that?
Not sure if I should fix this, or not. Is it merely unexpected, or
undesirable?
I would like "stub-prime: yes, stub-first: no" to still mean "I'm giving you
a private zone that can't be reached from the roots, please don't try and
ask them." If that's not what it means, I think updating the stub-prime
documentation to include the fallback behavior is necessary.
Thanks for looking at this,
-- Aaron
_______________________________________________
Unbound-users mailing list
Unbound-users@unbound.net
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
