With hyperlocal (RFC7706) requiring the root zone DNS server ip addresses listed as master in auth-zone and since this information is already provided (and automatically updated) in root-hints would it not make sense to utilise it for RFC7706 in auth-zone, something like?:
auth-zone:
name: .
master: path/to/root-hints
This way whenever an ip in root-hints gets updated it is available for RFC7706 too. Of course I do not know whether parsing those ip from root-hint is feasible and how much it would bloat the code and the ratio/cost of coding/testing effort vs. actual user benefit/advantage.
1. Not all the root servers provide zone transfer. It would be pointless
for unbound to add them to the list of masters, when XFR from several of
them will just fail continuously.
2. Even if this were implemented, it would only be useful for the root
zone. However, the "auth-zone" feature can work for any zone at any
level in the DNS tree. Therefore, adding code to look at the hints for
just the root zone is a very special case, and does not deserve the
extra code.
as master in auth-zone and since this information is already provided (and
automatically updated) in root-hints would it not make sense to utilise it for
RFC7706 in auth-zone, something like?:
auth-zone:
name: .
master: path/to/root-hints
not all root servers allow zone transfers so you don't
want to list them all as masters.
I did send an example unbound config for review to the DNSOP mailing list:
With hyperlocal (RFC7706) requiring the root zone DNS server ip addresses listed
please don't use the term "hyperlocal" (reasoning: Paul Hoffman - RFC7706bis author -
asked for not using it in the RFC7706 context at the last IETF103 DNSOP see the Q&A section of his
presentation [https://www.youtube.com/watch?v=g0Sz7gziUW0&feature=youtu.be&t=5015](https://www.youtube.com/watch?v=g0Sz7gziUW0&feature=youtu.be&t=5015) )
as master in auth-zone and since this information is already provided (and
automatically updated) in root-hints would it not make sense to utilise it for
RFC7706 in auth-zone, something like?:
auth-zone:
name: .
master: path/to/root-hints
not all root servers allow zone transfers so you don't
want to list them all as masters.
I did send an example unbound config for review to the DNSOP mailing list:
[https://mailarchive.ietf.org/arch/msg/dnsop/KLJFVjgALzvjZY0F0aZjFhE60LQ](https://mailarchive.ietf.org/arch/msg/dnsop/KLJFVjgALzvjZY0F0aZjFhE60LQ)
To my understanding the quotes (“”) in the syntax are not required. It works as well without and unbound-checkconf does claim any error for a syntax without the quotes.
Your understanding is wrong. Where does it say in that web page, that
all servers permit zone transfer? Please show me the actual words that
say this.
Can you please re-read RFC 7706, and understand it fully? It explains
exactly which root name servers _currently_ provide zone transfer, along
with the important warning that the zone transfer service can go away at
any time.
To my understanding ([http://www.dns.icann.org/services/axfr/](http://www.dns.icann.org/services/axfr/)) all servers do
permit zone transfer except l.root-servers.net
Thus continuous fail from several does not seem likely.
Your understanding is wrong. Where does it say in that web page, that
all servers permit zone transfer? Please show me the actual words that
say this.
It does not but it explicitly states which server does not permit transfer and thus logic would be that other servers neither permitted would be listed accordingly, respectively that any other server not explicitly listed is permitted.
And if that is not the case then it might be a bit of an oversight or just me over-expecting.
The sample is using URL instead of ip addresses and thus have to be resolved
first. Should not the relevant ip being stated instead?
This sample uses unbounds "master" directive with hostnames instead of IP addresses
with the following motivation/reasoning:
- it is unlikely that operators will update that config sample once they added it
- root server hostnames are expected to change less often (ever?) than their IP addresses
- unbound ships builtin hints data
Open question:
If a lot of operators deploy above sample, will b.root-servers.net have to handle most requests
or will unbound choose a random/the fastest server? (we should avoid putting all the load on one)
When I was in the team that operated that service there we went to
some lengths to emphasise that it was not a supported, production,
operational service but rather a convenient troubleshooting and
diagnostic tool provided on a best-effort basis.
(I think it's actually xfr.lax.dns.icann.org; there was a companion
service xfr.cjr.dns.icann.org. They served not just the root zone but
every infrastructure/community zone that ICANN hosted, like
ROOT-SERVERS.NET, ARPA, IN-ADDR.ARPA, URI.ARPA, etc, etc.)
This may be perfectly fine for your purposes (and of course the
disposition of those services might have changed during the 800 years
I've been away) but I thought I'd mention it.
// The traditional root hints mechanism. Use this, OR the slave zones below.
zone "." { type hint; file "/usr/local/etc/namedb/named.root"; };
/* Slaving the following zones from the root name servers has some
significant advantages:
1. Faster local resolution for your users
2. No spurious traffic will be sent from your network to the roots
3. Greater resilience to any potential root server failure/DDoS
On the other hand, this method requires more monitoring than the
hints file to be sure that an unexpected failure mode has not
incapacitated your server. Name servers that are serving a lot
of clients will benefit more from this approach than individual
hosts. Use with caution.
To use this mechanism, uncomment the entries below, and comment
the hint zone above.
As documented at http://dns.icann.org/services/axfr/ these zones:
"." (the root), ARPA, IN-ADDR.ARPA, IP6.ARPA, and a few others
are available for AXFR from these servers on IPv4 and IPv6:
xfr.lax.dns.icann.org, xfr.cjr.dns.icann.org
*/
/*
zone "." {
type slave;
file "/usr/local/etc/namedb/slave/root.slave";
masters {
192.0.32.132; // lax.xfr.dns.icann.org
2620:0:2d0:202::132; // lax.xfr.dns.icann.org
192.0.47.132; // iad.xfr.dns.icann.org
2620:0:2830:202::132; // iad.xfr.dns.icann.org
};
notify no;
};
pkg info bind911
bind911-9.11.3_1
Name : bind911
Version : 9.11.3_1
Installed on : Thu Apr 19 14:14:06 2018 CEST
Origin : dns/bind911
Architecture : FreeBSD:11:amd64
Prefix : /usr/local
Categories : net dns ipv6
Licenses : MPL20
Maintainer : mat@FreeBSD.org
WWW : https://www.isc.org/software/bind
Comment : BIND DNS suite with updated DNSSEC and DNS64
I'd have to check the source (of 9.12 or 9.13) to see if anything has changed in that text.