as the root zone is supporting AXFR/IXFR and in order not only to mitigate the amount of upstream queries to authoritative servers and speed up lookups but also to enhance privacy for client queries I am facilitating queries for delegated TLDs via auth-zone:.
What I am struggling with is name:, particularly understanding:
pertaining to that part of the namespace. The authority zone with the name closest to the name looked up is used.
With the root zone containing various delegated TLD namespaces (https://www.iana.org/domains/root/dB) I am not sure what name: is supposed to be in order to resolve SLD of a delegated TLD’s?
Tried name: . and then ran dig from the cli, utilizing the local copy of the root zone (transfer worked and zonefile: is present), but the SLD of the delegated TLD does not resolve, e.g.:
I notice that for these 2 zones, you've only listed one master. If this
master is unavailable, or stops providing XFR, I don't know how unbound
behaves, and what its failure mode is. The unbound.conf man page doesn't
describe what happens in this condition.
If unbound just waits like a regular secondary, then it may be several
hours or days until the zone expires (based on SOA timers), and your
copy of unbound will be using old data.
This is where unbound needs improvement, with 2 things:
1. document very clearly what unbound's behaviour is when all masters of
a zone become unavailable; and
2. if unbound really behaves like a regular secondary and waits for the
zone to expire based on the SOA record, then it's a poor choice. IMHO,
when unbound is unable to refresh a zone, it should immediately discard
it, and do normal recursive lookups for it. This would be far more
resilient.
And all of this should be documented in the man page. I often find that
manuals are very good at describing how to configure things, but they
don't tell the operator what to expect and what to do when things go
wrong. We operators end up learning the hard way.
> when unbound is unable to refresh a zone, it should immediately discard
> it, and do normal recursive lookups for it. This would be far more
> resilient.
As far as I know, this is the behaviour og unbound.
> And all of this should be documented in the man page. I often find that
> manuals are very good at describing how to configure things, but they
> don't tell the operator what to expect and what to do when things go
> wrong. We operators end up learning the hard way.
I agree that manual pages are a poor replacement for something like
an operational manual/functional specification.
The reason is a more broad problem: not all nameservers for these zones provide AXFR.
Maybe because RFC 2870 (Root Name Server Operational Requirements) say:
2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer,
queries from clients other than other root servers.
The reason is a more broad problem: not all nameservers for these zones provide AXFR.
Maybe because RFC 2870 (Root Name Server Operational Requirements) say:
2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer,
queries from clients other than other root servers.
Well, the servers for in-addr.arpa and ip6.arpa are NOT root name
servers, so RFC 2870 wouldn't apply to them. However, RFC 2870 is also
outdated, and its successor, RFC 7720 does not explicitly forbid zone
transfers, because there's no strong reason to, especially when the
zones are NSEC-signed, and can be enumerated trivially.
However, one should not rely on zone transfers being available all the
time, and in the case of your configuration, with just one server for
in-addr.arpa and ip6.arpa, it's fragile.
(at least for me) it's possible to fetch in-addr.arpa and ip6.arpa
from both servers lax.xfr.dns.icann.org and iad.xfr.dns.icann.org
via IPv4 and IPv6.
As Paul Vixie pointed out, it's wise to separate production an AXFR service.
an updated unbound configuration file may now look like this:
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.”
Setting it to no is defeating that purpose as a query does not resolve the SLD either:
;; 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.
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?
I notice that for these 2 zones, you've only listed one master. If this
master is unavailable, or stops providing XFR, I don't know how unbound
behaves, and what its failure mode is. The unbound.conf man page doesn't
describe what happens in this condition.
If unbound just waits like a regular secondary, then it may be several
hours or days until the zone expires (based on SOA timers), and your
copy of unbound will be using old data.
And it turns out the code in unbound did not check for the expired zone,
but it did keep track of the expiry timer. So I added code to give
SERVFAIL when the zone is expired. If fallback is enabled, instead of a
SERVFAIL it fetches from the upstream.
Likely before the zone is expired the rrsigs may expiry and then the
fallback could also activate. It also allows older serial numbers as a
zone update when the zone is expired.
Fixed the code to actually give failure for expired zones and documented
what it does. I think discarding the zone as soon as an update fetch
fails is too fast, so I did not go that far. But I fixed the expiry to
actually expire the zone at some point.
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://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?
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.
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.
I can appreciate if you are tired of, and thus refrain from, responding further in light of my continued ignorance.
What I am not understanding is that forward and recursing are conflicting since I would have considered forwarding being part of recursing.
The issue to me as simple user seems rather that the forward-zone name is limited to . and therein somehow conflicting with auth-zone name .
Or else forward-zone name being a domain name but it can hardly be expected having to list every TLD there is such as .com .net .gov and so forth (“Define them for other names, and that should work for those subzones.”)
Perhaps if there was instead a logic for forward-zone name: .* it would solve the matter comprehensively for all TLD and subdomains.
I do appreciate all the effort being put into unbound and I am happy with deploying the application just in this case of the “hyperlocal” concept its usability does not appeal really.
Having to chose between complicating matters with stub-zone and DoT I have opted for the latter and dropped the idea of hyperlocal (auth-zone name: .).
I can appreciate if you are tired of, and thus refrain from, responding
further in light of my continued ignorance.
We make our tools for knowledgeable users, also because the education
part is very hard. There are other places, and people, to get
information about how it all really works. But let me still try to
answer the questions. Probably in ways that make you ask more ...
What I am not understanding is that forward and recursing are
conflicting since I would have considered forwarding being part of
recursing.
The difference is that forward is: send full query, get the answer.
For full-recursion: send parts, get referrals to other authoritative
servers, ask again there, until there is an answer.
If you enabled both, and unbound would perform full lookups to its
internal copy of the root zone. This then results in a list of TLD
servers to contact. But then it ignores that list, because, for TLDs,
it sends the full query to your configured DoT upstream forward server.
Then that upstream forward query would be the full query. Just like it
would have sent without the local copy of the root.
So your solution to turn off the local copy of the root, seems to have
resulted in the behaviour you want from enabling both. Unbound sends
the full query to the upstream DoT server. And then uses that answer.
The local copy of the root is useful for full recursion, not forwarding,
setups, where the first referral lookups to the root servers are omitted
with a local copy. This is both faster and has privacy benefits.
I am trying hard with the education to become a knowledgeable user but I am afraid that my pea sized brain is perhaps impeding the process a bit Since you stated earlier: “There is an example in the example.conf for RFC7706 functionality for the root.” and thus I just looked into unbound-1.8.2rc1\doc\example.conf.in and the only 3 RFC references I could trace are unrelated to 7706. Also looked for such file at but without success. The configuration examples listed in RFC7706/7706bis-00 are for Unbound 1.4 in conjunction with NSD 4 and thus not applicable to running only unbound. Am I missing something about that example.conf? Sure it does, and appreciate your continued patience and support! I reckon that last bit is what confusing me - why the resolver would issue a full query upstream (forward DoT) and not just for the bits that are missing instead? Plus reading from 7706bis-00#section-1 - "recursive resolver software such as Unbound will need to be able to talk to an authoritative server (such as NSD) running on the same host. " It was my impression that Unbound handles the part with auth-zone or is that where stub-zone comes in? The speed and privacy benefits of the hyperlocal concept is what caused me to start this thread and I still would like very much deploy it but without having to give up on DoT and a curated list of upstream resolver.
Reckon I got it (hyperlocal) working now that is unless misinterpreting the log and the shorter response times.
It was mentioned in this thread earlier twice already (and I dismissed it) to have fallback-enabled: yes.
Finally that amounts to:
Since you stated earlier: “There is an example in the example.conf for RFC7706 functionality for the root.” and thus I just looked into unbound-1.8.2rc1\doc\example.conf.in and the only 3 RFC references I could trace are unrelated to 7706. Also looked for such file at but without success. The configuration examples listed in RFC7706/7706bis-00 are for Unbound 1.4 in conjunction with NSD 4 and thus not applicable to running only unbound. Am I missing something about that example.conf? Sure it does, and appreciate your continued patience and support! I reckon that last bit is what confusing me - why the resolver would issue a full query upstream (forward DoT) and not just for the bits that are missing instead? Plus reading from 7706bis-00#section-1 - "recursive resolver software such as Unbound will need to be able to talk to an authoritative server (such as NSD) running on the same host. " It was my impression that Unbound handles the part with auth-zone or is that where stub-zone comes in? The speed and privacy benefits of the hyperlocal concept is what caused me to start this thread and I still would like very much deploy it but without having to give up on DoT and a curated list of upstream resolver.