1.7.3 - root zone transfer and resolving SLD of delegated TLD

[Wouter Wijngaards]

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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20181126/c64a6bae/attachment.bin>