1.7.3 - root zone transfer and resolving SLD of delegated TLD
Wouter Wijngaards
wouter at nlnetlabs.nl
Wed Nov 28 15:56:31 UTC 2018
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
>>
>>
>> Best regards, Wouter
>>
>>
>>>
>>>> auth-zone:
>>>> name: .
>>>> zonefile: /etc/unbound/root
>>>> for-downstream: no
>>>> for-upstream: yes
>>>> master: 198.41.0.4
>>>> master: 199.9.14.201
>>>> master: 192.33.4.12
>>>> master: 199.7.91.13
>>>> master: 192.203.230.10
>>>> master: 192.5.5.241
>>>> master: 192.112.36.4
>>>> master: 198.97.190.53
>>>> master: 192.36.148.17
>>>> master: 192.58.128.30
>>>> master: 193.0.14.129
>>>> master: 199.7.83.42
>>>> master: 202.12.27.33
>>>
>>> The debug log (unbound 1.7.3):
>>>
>>>> info: validator operate: query bbc.com. A IN
>>>> debug: validator: pass to next module
>>>> debug: mesh_run: validator module exit state is module_wait_module
>>>> debug: iterator[module 1] operate: extstate:module_state_initial
>>>> event:module_event_pass
>>>> debug: process_request: new external request event
>>>> debug: iter_handle processing q with state INIT REQUEST STATE
>>>> info: resolving bbc.com. A IN
>>>> debug: request has dependency depth of 0
>>>> debug: forwarding request
>>>> debug: iter_handle processing q with state QUERY TARGETS STATE
>>>> info: processQueryTargets: bbc.com. A IN
>>>> debug: processQueryTargets: targetqueries 0, currentqueries 0
>>>> sentcount 0
>>>> info: DelegationPoint<.>: 0 names (0 missing), 10 addrs (0 result,
>>>> 10 avail) parentNS
>>>> info: auth_zone . query bbc.com. A, domain ns.amarshallinc.com.
>>>> notexact notexist, ce com., rrset NS
>>>> info: msg from auth zone ;; ->>HEADER<<- opcode: QUERY, rcode:
>>>> NOERROR, id: 0
>>>> ;; flags: qr ; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 26
>>>> ;; QUESTION SECTION:
>>>> bbc.com. IN A
>>>>
>>>> ;; ANSWER SECTION:
>>>>
>>>> ;; AUTHORITY SECTION:
>>>> com. 172800 IN NS a.gtld-servers.net.
>>>> com. 172800 IN NS b.gtld-servers.net.
>>>> com. 172800 IN NS c.gtld-servers.net.
>>>> com. 172800 IN NS d.gtld-servers.net.
>>>> com. 172800 IN NS e.gtld-servers.net.
>>>> com. 172800 IN NS f.gtld-servers.net.
>>>> com. 172800 IN NS g.gtld-servers.net.
>>>> com. 172800 IN NS h.gtld-servers.net.
>>>> com. 172800 IN NS i.gtld-servers.net.
>>>> com. 172800 IN NS j.gtld-servers.net.
>>>> com. 172800 IN NS k.gtld-servers.net.
>>>> com. 172800 IN NS l.gtld-servers.net.
>>>> com. 172800 IN NS m.gtld-servers.net.
>>>> com. 86400 IN DS 30909 8 2
>>>> E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CFC41A5766
>>>> com. 86400 IN RRSIG DS 8 1 86400 20181211050000
>>>> 20181128040000 2134 .
>>>> FeSgJRqqq/LY82e1pAM38Eiu07pepp53zIY23OlA65VDqA4ynhKWb8OvOKiWzHhWbM6KSs/4oXoTPMKn9x3EiWR0L170uKLloALiqbiVi9hJf/fYyRQB9QQPgxUqkkUnDdU7+zfK78BjBlEXgjd+5SfNiE32WKU9i5bP8crQg7J7tC/9FQwcn+eh/kz6pUJ5NVBG6YKkG2Y8YYCsOusOpa67WiRk3bf7DwJUAV6zD6v16TLr0GZesXokZbiwdIqPeJVjLumzLFxVHa+agDb3G2kv2qIjpFw7VPl1Nh/nADyJLdk6tvH5V9xu3MbkUgNcQeAoQG+BrEoRr7xfjKJhTA==
>>>> ;{id = 2134}
>>>>
>>>> ;; ADDITIONAL SECTION:
>>>> a.gtld-servers.net. 172800 IN A 192.5.6.30
>>>> a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
>>>> b.gtld-servers.net. 172800 IN A 192.33.14.30
>>>> b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30
>>>> c.gtld-servers.net. 172800 IN A 192.26.92.30
>>>> c.gtld-servers.net. 172800 IN AAAA 2001:503:83eb::30
>>>> d.gtld-servers.net. 172800 IN A 192.31.80.30
>>>> d.gtld-servers.net. 172800 IN AAAA 2001:500:856e::30
>>>> e.gtld-servers.net. 172800 IN A 192.12.94.30
>>>> e.gtld-servers.net. 172800 IN AAAA 2001:502:1ca1::30
>>>> f.gtld-servers.net. 172800 IN A 192.35.51.30
>>>> f.gtld-servers.net. 172800 IN AAAA 2001:503:d414::30
>>>> g.gtld-servers.net. 172800 IN A 192.42.93.30
>>>> g.gtld-servers.net. 172800 IN AAAA 2001:503:eea3::30
>>>> h.gtld-servers.net. 172800 IN A 192.54.112.30
>>>> h.gtld-servers.net. 172800 IN AAAA 2001:502:8cc::30
>>>> i.gtld-servers.net. 172800 IN A 192.43.172.30
>>>> i.gtld-servers.net. 172800 IN AAAA 2001:503:39c1::30
>>>> j.gtld-servers.net. 172800 IN A 192.48.79.30
>>>> j.gtld-servers.net. 172800 IN AAAA 2001:502:7094::30
>>>> k.gtld-servers.net. 172800 IN A 192.52.178.30
>>>> k.gtld-servers.net. 172800 IN AAAA 2001:503:d2d::30
>>>> l.gtld-servers.net. 172800 IN A 192.41.162.30
>>>> l.gtld-servers.net. 172800 IN AAAA 2001:500:d937::30
>>>> m.gtld-servers.net. 172800 IN A 192.55.83.30
>>>> m.gtld-servers.net. 172800 IN AAAA 2001:501:b1f9::30
>>>> ;; MSG SIZE rcvd: 1156
>>>>
>>>> debug: forwarder, ignoring referral from auth zone
>>>> debug: auth zone lookup failed, no fallback, servfail
>>>> debug: return error response SERVFAIL
>>>> debug: mesh_run: iterator module exit state is module_finished
>>>> debug: validator[module 0] operate: extstate:module_wait_module
>>>> event:module_event_moddone
>>>> info: validator operate: query bbc.com. A IN
>>>> debug: validator: nextmodule returned
>>>> debug: cannot validate non-answer, rcode SERVFAIL
>>>> debug: mesh_run: validator module exit state is module_finished
>>>> debug: query took 0.000000 sec
>>>> info: mesh_run: end 0 recursion states (0 with reply, 0 detached),
>>>> 0 waiting replies, 13 recursion replies sent, 0 replies dropped, 0
>>>> states jostled out
>>>
>>> Tried on another node with unbound 1.8.1
>>>
>>>> info: subnet operate: query cnn.com. A IN
>>>> debug: subnet: not found in cache. pass to next module
>>>> debug: mesh_run: subnet module exit state is module_wait_module
>>>> debug: validator[module 1] operate: extstate:module_state_initial
>>>> event:module_event_pass
>>>> info: validator operate: query cnn.com. A IN
>>>> debug: validator: pass to next module
>>>> debug: mesh_run: validator module exit state is module_wait_module
>>>> debug: iterator[module 2] operate: extstate:module_state_initial
>>>> event:module_event_pass
>>>> debug: process_request: new external request event
>>>> debug: iter_handle processing q with state INIT REQUEST STATE
>>>> info: resolving cnn.com. A IN
>>>> debug: request has dependency depth of 0
>>>> debug: forwarding request
>>>> debug: iter_handle processing q with state QUERY TARGETS STATE
>>>> info: processQueryTargets: cnn.com. A IN
>>>> debug: processQueryTargets: targetqueries 0, currentqueries 0
>>>> sentcount 0
>>>> info: DelegationPoint<.>: 0 names (0 missing), 10 addrs (0 result,
>>>> 10 avail) parentNS
>>>> info: auth_zone . query cnn.com. A, domain
>>>> ns-tld5.charlestonroadregistry.com. notexact notexist, ce com.,
>>>> rrset NS
>>>> [1543408434] unbound[28177:2] info: msg from auth zone ;;
>>>> ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
>>>> ;; flags: qr ; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 26
>>>> ;; QUESTION SECTION:
>>>> cnn.com. IN A
>>>>
>>>> ;; ANSWER SECTION:
>>>>
>>>> ;; AUTHORITY SECTION:
>>>> com. 172800 IN NS a.gtld-servers.net.
>>>> com. 172800 IN NS b.gtld-servers.net.
>>>> com. 172800 IN NS c.gtld-servers.net.
>>>> com. 172800 IN NS d.gtld-servers.net.
>>>> com. 172800 IN NS e.gtld-servers.net.
>>>> com. 172800 IN NS f.gtld-servers.net.
>>>> com. 172800 IN NS g.gtld-servers.net.
>>>> com. 172800 IN NS h.gtld-servers.net.
>>>> com. 172800 IN NS i.gtld-servers.net.
>>>> com. 172800 IN NS j.gtld-servers.net.
>>>> com. 172800 IN NS k.gtld-servers.net.
>>>> com. 172800 IN NS l.gtld-servers.net.
>>>> com. 172800 IN NS m.gtld-servers.net.
>>>> com. 86400 IN DS 30909 8 2
>>>> E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CFC41A5766
>>>> com. 86400 IN RRSIG DS 8 1 86400 20181211050000
>>>> 20181128040000 2134 .
>>>> FeSgJRqqq/LY82e1pAM38Eiu07pepp53zIY23OlA65VDqA4ynhKWb8OvOKiWzHhWbM6KSs/4oXoTPMKn9x3EiWR0L170uKLloALiqbiVi9hJf/fYyRQB9QQPgxUqkkUnDdU7+zfK78BjBlEXgjd+5SfNiE32WKU9i5bP8crQg7J7tC/9FQwcn+eh/kz6pUJ5NVBG6YKkG2Y8YYCsOusOpa67WiRk3bf7DwJUAV6zD6v16TLr0GZesXokZbiwdIqPeJVjLumzLFxVHa+agDb3G2kv2qIjpFw7VPl1Nh/nADyJLdk6tvH5V9xu3MbkUgNcQeAoQG+BrEoRr7xfjKJhTA==
>>>> ;{id = 2134}
>>>>
>>>> ;; ADDITIONAL SECTION:
>>>> a.gtld-servers.net. 172800 IN A 192.5.6.30
>>>> a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
>>>> b.gtld-servers.net. 172800 IN A 192.33.14.30
>>>> b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30
>>>> c.gtld-servers.net. 172800 IN A 192.26.92.30
>>>> c.gtld-servers.net. 172800 IN AAAA 2001:503:83eb::30
>>>> d.gtld-servers.net. 172800 IN A 192.31.80.30
>>>> d.gtld-servers.net. 172800 IN AAAA 2001:500:856e::30
>>>> e.gtld-servers.net. 172800 IN A 192.12.94.30
>>>> e.gtld-servers.net. 172800 IN AAAA 2001:502:1ca1::30
>>>> f.gtld-servers.net. 172800 IN A 192.35.51.30
>>>> f.gtld-servers.net. 172800 IN AAAA 2001:503:d414::30
>>>> g.gtld-servers.net. 172800 IN A 192.42.93.30
>>>> g.gtld-servers.net. 172800 IN AAAA 2001:503:eea3::30
>>>> h.gtld-servers.net. 172800 IN A 192.54.112.30
>>>> h.gtld-servers.net. 172800 IN AAAA 2001:502:8cc::30
>>>> i.gtld-servers.net. 172800 IN A 192.43.172.30
>>>> i.gtld-servers.net. 172800 IN AAAA 2001:503:39c1::30
>>>> j.gtld-servers.net. 172800 IN A 192.48.79.30
>>>> j.gtld-servers.net. 172800 IN AAAA 2001:502:7094::30
>>>> k.gtld-servers.net. 172800 IN A 192.52.178.30
>>>> k.gtld-servers.net. 172800 IN AAAA 2001:503:d2d::30
>>>> l.gtld-servers.net. 172800 IN A 192.41.162.30
>>>> l.gtld-servers.net. 172800 IN AAAA 2001:500:d937::30
>>>> m.gtld-servers.net. 172800 IN A 192.55.83.30
>>>> m.gtld-servers.net. 172800 IN AAAA 2001:501:b1f9::30
>>>> ;; MSG SIZE rcvd: 1156
>>>>
>>>> debug: forwarder, ignoring referral from auth zone
>>>> debug: auth zone lookup failed, no fallback, servfail
>>>> debug: return error response SERVFAIL
>>>> debug: mesh_run: iterator module exit state is module_finished
>>>> debug: validator[module 1] operate: extstate:module_wait_module
>>>> event:module_event_moddone
>>>> info: validator operate: query cnn.com. A IN
>>>> debug: validator: nextmodule returned
>>>> debug: cannot validate non-answer, rcode SERVFAIL
>>>> debug: mesh_run: validator module exit state is module_finished
>>>> debug: subnet[module 0] operate: extstate:module_wait_module
>>>> event:module_event_moddone
>>>> info: subnet operate: query cnn.com. A IN
>>>> debug: mesh_run: subnet module exit state is module_finished
>>>> debug: query took 0.000000 sec
>>>> info: mesh_run: end 0 recursion states (0 with reply, 0 detached),
>>>> 0 waiting replies, 21 recursion replies sent, 0 replies dropped, 0
>>>> states jostled out
>>>
>>> On 26.11.2018 09:57, Wouter via Unbound-users wrote:
>>>> Hi,
>>>>
>>>> On 10/28/18 7:08 PM, ѽ҉ᶬḳ℠ via Unbound-users wrote:
>>>>>> the following configuration is known to work with unbound 1.8.x
>>>>> Seems it does not make a difference whether it is 1.7.3 or 1.8.x
>>>>>
>>>>>> auth-zone:
>>>>>> name: "."
>>>>> The syntax *""* for *name: *is not stipulated in the online
>>>>> documentation, that is for *auth-zone:*. Why is it being used then?
>>>>> unbound-checkconf does not report an error either way, i.e. whether it
>>>>> reads *name: "."* or *name: .*, and the outcome of the query is the same.
>>>>>
>>>>>> for-downstream: no
>>>>> That does not make sense to me considering the purpose of transferring
>>>>> the root zone-> "If enabled, unbound serves authority responses to
>>>>> downstream clients for this zone. This option /makes unbound
>>>>> behave/, for the queries with names in this zone,/like one of the
>>>>> authority servers for that zone/."
>>>> You need the for-downstream: no setting. Because unbound has to be a
>>>> mirror for looking up root zone information in the contents. It has the
>>>> information, but is not a copy of a root server to its clients, but uses
>>>> the information as a copy of the root server information for its own
>>>> purposes. Subtly different in wording, but very different in responses.
>>>>
>>>> With for-downstream: yes, you got a referral for .com when queries for
>>>> somename.com. And that is exactly what that option does, serve a copy
>>>> of that zone.
>>>>
>>>> With for-downstream: no (and for-upstream: yes), unbound should use the
>>>> information when recursing to answer user queries. It uses it in
>>>> preference to making internet queries, and this means it uses the local
>>>> copy to speed up the look ups. That seems to be the option you wanted.
>>>>
>>>>> Setting it to *no* is defeating that purpose as a query does not resolve
>>>>> the SLD either:
>>>> This does not work either? Is that because you turned off for-upstream
>>>> with for-upstream: no? It should be working, with for-downstream: no
>>>> and for-upstream: yes, I wonder what went wrong. If the config fixes do
>>>> not work for you could you tell me the verbose log of that lookup? The
>>>> first result (the .com referral answer you got) tells me that mostly
>>>> things a fine, the zone is loaded and data is looked up correctly. But
>>>> I thought this would have worked?
>>>>
>>>> Best regards, Wouter
>>>>
>>>>>> # dig bbc.com
>>>>>>
>>>>>> ; <<>> DiG 9.11.2-P1 <<>> bbc.com
>>>>>> ;; global options: +cmd
>>>>>> ;; Got answer:
>>>>>> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34029
>>>>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>>>>>>
>>>>>> ;; OPT PSEUDOSECTION:
>>>>>> ; EDNS: version: 0, flags:; udp: 4096
>>>>>> ;; QUESTION SECTION:
>>>>>> ;bbc.com. IN A
>>>>>>
>>>>>> ;; Query time: 5 msec
>>>>>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>>>>>> ;; WHEN: Sun Oct 28 18:40:37 CET 2018
>>>>>> ;; MSG SIZE rcvd: 36
>>>>>> for-upstream: yes
>>>>> According to the online documentation this is a default setting and thus
>>>>> redundant to my understanding.
>>>>>
>>>>>
>>>>>> fallback-enabled: yes
>>>>> Only then the SLD resolves but that renders the transfer of the root
>>>>> zone redundant, i.e. means there is no apparent benefit/advantage of
>>>>> having a local the root zone with its delegated TLDs.
>>>>>
>>>>> The purpose of featuring a local copy of the root zone was that TLD
>>>>> queries are served locally rather than generating upstream queries to
>>>>> the NS of the TLD and thus mitigating the amount of upstream queries to
>>>>> authoritative servers and speed up lookups but also to enhance privacy
>>>>> for client queries.
>>>>>
>>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20181128/25d4f930/attachment.htm>
More information about the Unbound-users
mailing list