Subject: [DNSOP] RFC7720 and AXFR

From: "A. Schulze" <[email-masked]>
Date: Sun, 28 Oct 2018 13:32:51 +0100

Hello,

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 update, RFC 7720 (DNS Root Name Service Protocol and Deployment Requirements)
don't even mention AXFR at all.
All I found is https://tools.ietf.org/html/rfc7720#section-2

	o MUST implement core DNS [RFC1035] and clarifications to the DNS [RFC2181].

Is AXFR a strict requirement for root-servers today?

Andreas

---

From: Mukund Sivaraman <[email-masked]>
Date: Sun, 28 Oct 2018 18:43:18 +0530

> Is AXFR a strict requirement for root-servers today?

There's no requirement for AXFR and some root letters don't serve
AXFR. E.g., L and M don't whereas F does.

		Mukund

---

From: Jaap Akkerhuis <[email-masked]>
Date: Sun, 28 Oct 2018 14:24:38 +0100

> AXFR. E.g., L and M don't whereas F does.

For AXFR from L, see <https://www.dns.icann.org/services/axfr/>

	jaap

---

From: Evan Hunt <[email-masked]>
Date: Sun, 28 Oct 2018 16:44:42 +0000

On Sun, Oct 28, 2018 at 01:32:51PM +0100, A. Schulze wrote:
> The update, RFC 7720 (DNS Root Name Service Protocol and Deployment
> Requirements) don't even mention AXFR at all.  All I found is
> https://tools.ietf.org/html/rfc7720#section-2
> 

As a relatively new consideration, root zone local mirroring (RFC 7706)
depends on at least a subset of root servers being able to provide the
zone via AXFR. The configuration examples in the appendix specify B, F,
G, and K.

I've been assured by ISC folks that we'll always serve AXFR on F, but I
don't know if that commitment is in writing, nor whether the other roots
that currently support it have made any promises to keep doing so.

IMHO it would be nice if all 13 letters provided AXFR service, but at a
minimum we it's important for *some* of them to do so.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Grant Taylor <[email-masked]>
Date: Sun, 28 Oct 2018 11:05:17 -0600

On 10/28/2018 10:44 AM, Evan Hunt wrote:
> zone via AXFR.

Does root zone local mirroring require that the zone comes from the 
lettered root servers themselves?  Or could it come from another server 
with the root zone?  Possibly a server that one or more operators set up 
specifically for the purpose?

-- 
Grant. . . .
unix || die

---

From: Paul Vixie <[email-masked]>
Date: Sun, 28 Oct 2018 10:14:58 -0700

Evan Hunt wrote:
...
> minimum we it's important for *some* of them to do so.

while i agree with you (and i'm the one who set F's policy, back in the 
day), it's important to recognize achievements and advances where they 
have occurred. ICANN has "put something in writing" as you say:

https://www.dns.icann.org/services/axfr/

while RFC 7706 is terrible engineering and the IETF should be ashamed of 
publishing it, i think the least we can do is acknowledge that ICANN 
operates (and promises to continue operating) AXFR servers for the root 
zone. see again URL above. there is no need to make production AXFR 
queries for the root zone from "real" root servers any more.

-- 
P Vixie

---

From: "A. Schulze" <[email-masked]>
Date: Sun, 28 Oct 2018 18:20:44 +0100

Am 28.10.18 um 18:14 schrieb Paul Vixie:
> there is no need to make production AXFR queries for the root zone from "real" root servers any more.

I agree to separate production and AXFR services.
A formal statement of ICANN *which is not limited to l.root-servers.net.* would make things much more clear.

Andreas

---

From: Evan Hunt <[email-masked]>
Date: Sun, 28 Oct 2018 17:46:41 +0000

> specifically for the purpose?

You're right, it could, and I'd forgotten earlier that the appendix
does also mention lax.xfr.dns.icann.org and iad.xfr.dns.icann.org.

However, the root servers are the root servers. We all know A through M by
heart, and resolvers have their addresses built in and kept up to date.
Seems like a useful thing to leverage, if possible.

---

From: Marc Groeneweg <[email-masked]>
Date: Mon, 29 Oct 2018 13:36:46 +0000

I hear a use-case for draft-wessels-dns-zone-digest

On 28/10/2018, 18:55, "DNSOP on behalf of Evan Hunt" <[email-masked] on behalf of [email-masked]> wrote:

    

    _______________________________________________
    DNSOP mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/dnsop

---

From: Petr Špaček <[email-masked]>
Date: Mon, 29 Oct 2018 14:49:19 +0100

> A formal statement of ICANN *which is not limited to l.root-servers.net.* would make things much more clear.

Well, AXFR is not strictly necessary.

E.g. implementation of RFC 7706-like feature in Knot Resolver pulls zone
file from a HTTPS URL so it can reuse any CDN you like (or not).

After all 7706 implementation is just an optimization so it might use
non-DNS service if desired and nothing bad would happen if it is not
available.

(It is important to note that our implementation imports data from zone
file into cache so it will simply expire and naturally fallback to full
recursion if subsequent refresh attemps fail.)

-- 
Petr Špaček  @  CZ.NIC

---

From: "A. Schulze" <[email-masked]>
Date: Mon, 29 Oct 2018 16:51:08 +0100

> file from a HTTPS URL so it can reuse any CDN you like (or not).

Well, good point!

unbound behave similar.

So it would be simply some homework for ICANN to provide the zones in a stable manner.
I don't know if that's maybe already the case for lax.xfr.dns.icann.org and iad.xfr.dns.icann.org.

Out job is provide example configurations for knot resolver and unbound
and probably other resolver...

On the long term this could motivate more admins to apply RFC7706
(Decreasing Access Time to Root Servers by Running One on Loopback)

Anyone from ICANN to take that job?

Andreas

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 31 Oct 2018 15:39:01 -0700

> minimum we it's important for *some* of them to do so.

Note about a project of mine that offers TSIG protected AXFRs and DNS
notifications, unlike directly AXFRing from random root letters:

https://localroot.isi.edu/

I haven't advertised this too widely yet, but there are a number of
people using it already.

Note that it also dumps out configuration for all the root letters that
do support AXFRs (and from which I've gotten their explicit permission
to do so).  The root identifiers supporting AXFR today (some of whom
added it specifically because of wanting to support this project)
include B, C, D, F, G, and K.  Plus ICANN has their AXFR addresses, as
previously mentioned, at lax.xfr.dns.icann.org and xfr.cjr.dns.icann.org .

-- 
Wes Hardaker
USC/ISI