Subject: [DNSOP] draft-ietf-dnsop-root-loopback-01

From: [email-masked]
Date: Wed, 25 Mar 2015 14:19:44 +0900 (JST)

Sorry for most of the following comments on
draft-ietf-dnsop-root-loopback-01 applicable to its appendices.

It is better to describe that the update of the zone can be delayed a
little bit as no NOTIFY message is sent to the root-on-loopback.

In Appendix A, the root servers listed allow AXFR currently, but I am
afraid they don't guarantee it in the future. It may be necessary to
confirm it with the operator of each root server listed.

In Appendix B, most of the IP addresses of the root DNS servers are
anycasted. They are not suitable for the target to pull the zone data
in AXFR over TCP.

Also it must be noted that these addresses may change over time (while
the frequency is not high), it may need to give a warning to
periodically check if the addresses are valid. Generating the
configuration after priming query? (this is a joke)

IMHO, it may necessary to establish an infrastructure to distribute
root zone in scalable/reliable manner.

-- Akira Kato

---

From: Tony Finch <[email-masked]>
Date: Wed, 25 Mar 2015 11:07:56 +0000

> little bit as no NOTIFY message is sent to the root-on-loopback.

The root zone's refresh timer is 30 minutes, and its update interval is
about 12 hours. So the delay is very small.

> anycasted. They are not suitable for the target to pull the zone data

False. Anycast works fine over TCP - see Akamai, Cloudflare, etc.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southwest Forties, Cromarty, Forth, Tyne, Dogger: Variable 4 becoming
southerly or southeasterly 4 or 5, occasionally 6 later. Slight becoming
moderate. Showers. Good, occasionally moderate.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 25 Mar 2015 07:36:39 -0500

> little bit as no NOTIFY message is sent to the root-on-loopback.

Good point; added.

> confirm it with the operator of each root server listed.

The appendix already says:

      It is crucial to note that none of the above services are guaranteed
      to be available. It is possible that ICANN or some of the root server
      operators will turn off the AXFR capability on the servers listed above.

Asking any operator to guarantee something in the future doesn't mean they actually will do so, so this warning is more appropriate.

> anycasted. They are not suitable for the target to pull the zone data

Fully disagree. AXFR of the root zone over TCP over anycast works just fine in all our testing. As Tony Finch points out, it works well in the current Internet.

> periodically check if the addresses are valid.

Is the above warning not sufficient?

> Generating the

Feel free to create such an infrastructure. After it is in place, we can update this document. In the meantime, this document describes a practice that many operators are already using quite successfully.

--Paul Hoffman

---

From: Jared Mauch <[email-masked]>
Date: Wed, 25 Mar 2015 08:42:15 -0400

> On Mar 25, 2015, at 8:36 AM, Paul Hoffman <[email-masked]> wrote:
> 

I have a minor nit for consideration: the examples should also include IPv6 loopback ::1 as well.

- Jared

---

From: [email-masked]
Date: Wed, 25 Mar 2015 23:01:59 +0900 (JST)

From: Paul Hoffman <[email-masked]>
Subject: Re: [DNSOP] draft-ietf-dnsop-root-loopback-01
Date: Wed, 25 Mar 2015 07:36:39 -0500

> Asking any operator to guarantee something in the future doesn't mean they actually will do so, so this warning is more appropriate.

Sorry, I missed the paragraph.

> Fully disagree. AXFR of the root zone over TCP over anycast works just fine in all our testing. As Tony Finch points out, it works well in the current Internet.

I don't think Akamai uses anycast, but it answers "suitable"
non-anycast IP address in DNS query depending on the source address.
I don't know if such ISPs still exist, but when we started Anycast, it
was reported that some ISPs did per-packet load balancing.  The root
zone grows over time in almost monotonous manner and longer TCP
sessions (especially over narrow bandwidth circuits) could break due
to routing change. I'd appreciate if you can add my concern to the
text.

> Is the above warning not sufficient?

OK

> Feel free to create such an infrastructure. After it is in place, we can update this document. In the meantime, this document describes a practice that many operators are already using quite succes…

Publishing XML/JSON/YAML encoded root zone via CDN? I don't know who should
pay the cost.

-- Akira Kato

---

From: George Michaelson <[email-masked]>
Date: Wed, 25 Mar 2015 09:08:14 -0500

kato san, what is the statistical likelihood of a routing break happening
at a specific anycast node, during the life of a TCP session, and whats the
consequence?

likelihood: it depends on the frequency of A/I XFR, the volume of query,
and the frequency of routing break

consequence: the TCP session dies and the client re-tries Which will
connect to another anycast node and continue.

I believe the frequency is going to be down below 1% and probably below
0.001% as orders of magnitude. I suspect it is no worse and no more likely
than A/I XFR long held TCP, and breaking routing in the current model.

I don't believe the consequence is severe because the global applicability
of a single update fail is that you had to retry

-G

On Wed, Mar 25, 2015 at 9:01 AM, <[email-masked]> wrote:

> > Asking any operator to guarantee something in the future doesn't mean
> they actually will do so, so this warning is more appropriate.
>
> > Fully disagree. AXFR of the root zone over TCP over anycast works just
> fine in all our testing. As Tony Finch points out, it works well in the
> current Internet.
>
> > Feel free to create such an infrastructure. After it is in place, we can
> update this document. In the meantime, this document describes a practice
> that many operators are already using quite successfully.
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 25 Mar 2015 09:16:25 -0500

> I have a minor nit for consideration: the examples should also include IPv6 loopback ::1 as well.

Of what operational value is that? (This is a serious question.)

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Wed, 25 Mar 2015 14:31:45 +0000

[email-masked] <[email-masked]> wrote:
> was reported that some ISPs did per-packet load balancing.

If they do that they will utterly wreck the performance of unicast TCP,
which generally does not cope well with out-of-order packets.

> The root zone grows over time in almost monotonous manner and longer TCP
> sessions (especially over narrow bandwidth circuits) could break due to
> routing change.

That's also true for unicast TCP since BGP's typical convergence times are
not much longer than TCP connection timeouts.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
North Fisher: Easterly 5 to 7, occasionally gale 8, perhaps severe gale 9
later. Rough or very rough. Rain or snow. Moderate, occasionally very poor.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 25 Mar 2015 07:46:11 -0700

> Tony Finch <mailto:[email-masked]>
> Wednesday, March 25, 2015 4:07 AM

nevertheless it's good to describe it. 30 minutes is, and 12 hours
certainly is, longer than the usual delay seen by the NOTIFY-speaking
servers.
> False. Anycast works fine over TCP - see Akamai, Cloudflare, etc.

it's not "false". most routing changes are path changes not outright
withdrawals of the last available path. i would like to see kato's
concern added to the document, since anycast tcp is in truth and in fact
less stable than unicast tcp, and the more so depending on the width of
the anycast footprint.

-- 
Paul Vixie

---

From: "John Levine" <[email-masked]>
Date: 25 Mar 2015 14:52:17 -0000

>I have a minor nit for consideration: the examples should also include IPv6

I'm with Paul -- every host handles 127/8 loopback addresses and
there's no need to use anything else for purely internal
communication.

Note that this has no effect on whether anything else in your DNS
setup supports v6.

R's,
John

---

From: Paul Vixie <[email-masked]>
Date: Wed, 25 Mar 2015 07:57:45 -0700

> Wednesday, March 25, 2015 7:31 AM

and yet, in a UDP-first UDP-mostly or even UDP-only operating
environment, that assumption has been sound. if we're about to make it
unsound then we have to say so.
> not much longer than TCP connection timeouts.

there is no convergence any more. the diameter and surface area of the
bgp cloud has for some years now been such that some packets always go
awry (either routed suboptimally, or sent to the dead packet office).
short tcp sessions which don't go idle or for which responder-close is a
well-understood and widely-expected condition, are not affected by this.
axfr of the root zone, even at current sizes before the monotonous
growth kato has described, is not a short enough to fit this envelope. i
think the document has to mention this.

-- 
Paul Vixie

---

From: Jared Mauch <[email-masked]>
Date: Wed, 25 Mar 2015 11:02:23 -0400

> On Mar 25, 2015, at 10:16 AM, Paul Hoffman <[email-masked]> wrote:
> 

This is somewhat of a religious thing for me, but:

a) vendors respond to behaviors documented in RFCs when RFPs/RFIs are issued
b) IP packets are generally assumed to be version 4 by most people, getting in the habit of documenting the behavior of both isn’t really that hard.  We need to get into the habit of putting v6 examples in documents, it’s 2015.
c) people copy examples forever, having good well-documented examples for both are important.

- Jared

---

From: George Michaelson <[email-masked]>
Date: Wed, 25 Mar 2015 10:09:58 -0500

On Wed, Mar 25, 2015 at 9:57 AM, Paul Vixie <[email-masked]> wrote:
> Tony Finch

I think thats an interesting, and valid point. We've had the luxury of
assuming a very high percentage of all DNS except zone tx is UDP, and
packet order issues have largely been ignored because they were lost in
noise. Now we're exposed to the consequence of flows, packet trains, and
its probably true that TCP out of order delivery is going to hit us.

I say this, because I have been exposed to precisely this cost from a DC
which is doing what Tony describes, and I can see of the order 10x less
throughput from DE to AU compared to DE to US, because of this problem in
file transfers, because they use odd BGP routing and load management. split
path is hard on TCP if the packet order gets tossed.

-G

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 25 Mar 2015 10:39:29 -0500

> anycasted. They are not suitable for the target to pull the zone data

I still disagree with the statement that these are "not suitable", given that they work fine almost all the time. Proposed addition to alleviate your concern:

      AXFR transfer over TCP to addresses that are likely to be anycast (as the the ones
      above are) may have transfer problems different than AXFR over UDP.

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Wed, 25 Mar 2015 15:53:27 +0000

Paul Hoffman <[email-masked]> wrote:
>
> I still disagree with the statement that these are "not suitable", given
> that they work fine almost all the time. Proposed addition to alleviate
> your concern:
>
>       AXFR transfer over TCP to addresses that are likely to be anycast
>       (as the the ones above are) may have transfer problems different
>       than AXFR over UDP.

I think you mean "common queries over UDP" since AXFR over TCP isn't a
thing :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Biscay: North 4 or 5, backing southwest 5 to 7. Moderate or rough. Showers,
rain later. Moderate or good.

---

From: [email-masked]
Date: Thu, 26 Mar 2015 00:58:34 +0900 (JST)

From: Paul Hoffman <[email-masked]>
Subject: Re: [DNSOP] draft-ietf-dnsop-root-loopback-01
Date: Wed, 25 Mar 2015 10:39:29 -0500

>       above are) may have transfer problems different than AXFR over UDP.

Thanks, Paul. As George suggested, when one AXFR trial fails due to
route flaps, it will try another, and I understand that a single
transient TCP failure may not be a serious problem. I am happy with
the proposed text addition at this moment. If I happen to have data, I
will write again.

-- Akira Kato
P.S.
As the root zone is signed by NSEC rather than NSEC3, zone enumaration
over UDP is possible :-)

---

From: Evan Hunt <[email-masked]>
Date: Wed, 25 Mar 2015 16:06:58 +0000

> I think you mean "common queries over UDP" since AXFR over TCP isn't a

Or rather AXFR over UDP isn't. TCP is mandatory for *XFR.

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

---

From: Tony Finch <[email-masked]>
Date: Wed, 25 Mar 2015 16:16:42 +0000

> Or rather AXFR over UDP isn't. TCP is mandatory for *XFR.

Um yes! Muphry's law of Internet corrections strikes again.
(Thanks also to Ray who spotted the same mistake.)

Tony.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 25 Mar 2015 14:18:59 -0500

> Or rather AXFR over UDP isn't. TCP is mandatory for *XFR.

Where is that requirement made? The only thing I see in RFC 5936 is that AXFR over UDP is not defined.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Wed, 25 Mar 2015 15:30:53 -0400 (EDT)

> Where is that requirement made? The only thing I see in RFC 5936 is that AXFR over UDP is not defined.

https://tools.ietf.org/html/rfc5936#section-2

 	An important aspect to keep in mind is that the definition of AXFR is
 	restricted to TCP [RFC0793] (see Section 4 for details).

Paul

---

From: Evan Hunt <[email-masked]>
Date: Wed, 25 Mar 2015 19:32:51 +0000

> AXFR over UDP is not defined.

My mistake:  After reviewing the specs, AXFR over UDP is not defined but
IXFR is permitted as long as the entire response fits in a single message.

(BIND doesn't allow it for either one, and I conflated that implementation
decision with a requirement, oops.)

---

From: [email-masked]
Date: Thu, 26 Mar 2015 04:33:41 +0900 (JST)

From: Paul Hoffman <[email-masked]>
Subject: Re: [DNSOP] draft-ietf-dnsop-root-loopback-01
Date: Wed, 25 Mar 2015 14:18:59 -0500

> Where is that requirement made? The only thing I see in RFC 5936 is that AXFR over UDP is not defined.

Section 4.3.5 of RFC1034 says: "Because accuracy is essential, TCP or
some other reliable protocol must be used for AXFR requests."

-- Akira Kato

---

From: [email-masked]
Date: Thu, 26 Mar 2015 04:49:55 +0900 (JST)

From: [email-masked]
Subject: Re: [DNSOP] draft-ietf-dnsop-root-loopback-01
Date: Thu, 26 Mar 2015 04:33:41 +0900 (JST)

> some other reliable protocol must be used for AXFR requests."

The current root zone size in the wire format is 539,248 byte. Provided
if MTU is 1500, it consists of 367 fragments in UDP. Even if AXFR over
UDP is allowed, it may not be practical to assume such number of fragments
get delivered without any packet loss especially over a satellite link
which is an use case of the draft. Retries could also be fail in this
case.

-- Akira Kato

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 26 Mar 2015 05:14:48 +0900

Kato san;

> which is an use case of the draft. Retries could also be fail in this

Are you talking about jumbogram capable satellite link with
link layer fragmentation?

Then, the fragmentation mechanism should support SACK like
mechanism.

					Masataka Ohta

---

From: [email-masked]
Date: Thu, 26 Mar 2015 05:23:29 +0900 (JST)

From: [email-masked]
Subject: Re: [DNSOP] draft-ietf-dnsop-root-loopback-01
Date: Thu, 26 Mar 2015 04:49:55 +0900 (JST)

> which is an use case of the draft. Retries could also be fail in this

Sorry, I forgot that maximum message size of UDP was 65535. So
discussion of AXFR over UDP doesn't make sense as long as we are
talking about the root zone.

-- Akira Kato