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. > >
signature.asc
Description: OpenPGP digital signature
