1.7.3 - root zone transfer and resolving SLD of delegated TLD

[Wouter Wijngaards]

Hi,

So to summarize, another user also had this problem.  And the issue was
he enabled both a forward-zone with the new DoT.  And RFC7706 local copy
of the root.  But that is both forward and do full recursion at the same
time, conflicting.  You have to pick one.

That query can get TLSed and sent to an upstream forwarder.  Or it can
take a referral from an RFC7706 copy of the root and then do full
recursion.  But not really both at the same time.  Hence, a bug,
previously, and now it prints errors.  But you ran into that error.

Unbound can actually also do DoT with stub-zones too, if you configured
it in unbound.conf, but there are no upstreams or method to find any. 
Anyway, that was not what you tried to do.


Best regards, Wouter


On 28/11/2018 16:56, Wouter Wijngaards via Unbound-users wrote:
>
> Hi,
>
> Yes the RFC7706 functionality needs you to not have a forward-zone
> clause and then an auth-zone for the root.  With for-downstream: no
> and for-upstream: yes (and the RFC recommends the fallback enabled, I
> think).  Unbound uses the auth-zone as a repository of data that is
> accessed instead of the  upstream, this is why the forward-zone and
> stub-zone definitions are still used, because they regulate how that
> local-copy of the upstream is accessed.
>
> If you want DoT upstreams, you can define them.  Just not for the "."
> zone whilst doing the auth-zone for the root.  Define them for other
> names, and that should work for those subzones.
>
> There is an example in the example.conf for RFC7706 functionality for
> the root.  You keep turning the options wrong?
>
> The servfail is because you instructed unbound to act as a forwarder
> to a root server, whose content is locally cached in an auth-zone. 
> The root server has very little data, itself, hence the servfails.  It
> needs to not have that forwarder clause.  Then it uses the referrals
> from the local copy to continue the full recursion.  And you could
> have gotten non SERVFAIL answers, if only you asked for the data that
> the local copy actually has, the root SOA record.  That would be
> answered and then a forwarder configuration works, giving the SOA
> record answer.  But for RFC7706 it wants the referrals followed, so
> not the forwarder configuration.
>
> The auth zone, when configured as for-downstream:no and for-upstream:
> yes is a quick method to get a reply from the upstream.  By having a
> local copy of the data to fill in the upstream reply.  Unbound then
> still needs to have the configuration on how to contact upstreams. And
> for a local root copy mirror that means a configuration where it will
> use the referral answer.  Using the referral answer needs a stub-zone
> (or the absence of a forward-zone).
>
> Looks like the architecture of the system and its configuration
> settings is complicated, if you end up figureing out where the
> understanding issue is, I mean how to fix documentation that would be
> nice.  Unbound is using both stub/forward decls to feed into an
> upstream selection, using auth-zone copies.   With for-downstream: yes
> the auth-zone moves closer and overtakes the stub/forward zones to
> provide the answer directly, something that is useful for giving
> authority answers to downstreams.
>
> Best regards, Wouter
>
> On 28/11/2018 16:01, ѽ҉ᶬḳ℠ via Unbound-users wrote:
>> I am not sure where my understanding is going awry here. What I want
>> to achieve seems to be called “hyperlocal” concept - a local copy
>> (AXFR/IXFR) of the root zone (to be served) by unbound to its
>> clients. Something like:
>>
>>   * https://tools.ietf.org/html/rfc7706
>>   * https://tools.ietf.org/html/draft-ietf-dnsop-7706bis-00
>>   * https://localroot.isi.edu/about/
>>
>> Thus far my understanding is that is (zone transfer) best to be
>> achieved via auth-zone and sub-zone rather to be utilized for
>> company-local data or private  zones (authoritative data  that cannot
>> be accessed using the public internet servers), which the root zone
>> is not. And stub-zone does not provide for zone transfer, as far as I
>> understand.
>>
>> If the forward-zone definition is removed than I cannot utilise DoT
>> with selected upstream resolvers.
>>
>> What I not get is the servfail on the referrals/delegation from the
>> root zone. Is unbound not suited for this “hyperlocal” concept thence?
>>
>> On 28.11.2018 14:42, Wouter via Unbound-users wrote:
>>>
>>> Hi,
>>>
>>> On 28/11/2018 13:46, ѽ҉ᶬḳ℠ via Unbound-users wrote:
>>>> Hi Wouter,
>>>>
>>>> thanks for looking into it and the response. Unfortunately with the
>>>> below setting the /second-level domain does not resolve/
>>>
>>>
>>> It is configured to forward to the root zone that you have
>>> mirrored.  The root zone only contains delegations, so you get
>>> servfail or referrals out of that.  What you want is that it
>>> performs full recursion with the copy of the root zone, that is the
>>> stub-zone behaviour.  You should change your config to have
>>> stub-zone for the name: "." zone and not a forward-zone for that; or
>>> remove the forward-zone definition.
>>>
>>>
>>> These two log lines contained the info:
>>>
>>> debug: forwarder, ignoring referral from auth zone
>>> debug: auth zone lookup failed, no fallback, servfail
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20181128/f69da591/attachment.htm>