Subject: [DNSOP] Fwd: I-D Action: draft-song-dnsop-tcp-primingexchange-00.txt

From: Davey Song <[email-masked]>
Date: Thu, 27 Nov 2014 03:18:20 +0800

Hi folks, I just post a draft on Priming Exchange over TCP. Comments are
welcome!

regards,
Davey

---------- Forwarded message ----------
From: <[email-masked]>
Date: Thu, Nov 27, 2014 at 3:02 AM
Subject: I-D Action: draft-song-dnsop-tcp-primingexchange-00.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : Using TCP by Default in Root Priming Exchange
        Authors         : Linjian Song
                          Di Ma
        Filename        : draft-song-dnsop-tcp-primingexchange-00.txt
        Pages           : 10
        Date            : 2014-11-26

Abstract:
   DNS payload size limitation constrains operational and policy choice
   for many years.  It is become increasingly notable in IPv6 transition
   and DNSSEC development, specifically during Priming Exchange process.
   Given that the load of priming exchange on the root system is
   relatively low, this memo proposes using TCP by default in Priming
   Exchange between resolver and root server.  This approach is aiming
   to treat Priming Exchange as a special process which brings a little
   change to the current root system and provide solution to the long-
   term problems.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-song-dnsop-tcp-primingexchange/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-song-dnsop-tcp-primingexchange-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Paul Vixie <[email-masked]>
Date: Wed, 26 Nov 2014 18:41:39 -0800

> Davey Song <mailto:[email-masked]>
> Wednesday, November 26, 2014 11:18 AM
> Hi folks, I just post a draft on Priming Exchange over TCP. Comments
> are welcome!

davey, your abstract says "DNS payload size limitation constrains
operational and policy choice for many years." your document does not
give any examples of specific operational or policy constraints caused
by this limitation.

today a priming query returns 755 octets of udp payload without dnssec,
or 913 octets of udp payload with dnssec. what's missing?

if EDNS is not used then TC=1 will cause TCP fallback, thus giving us
either one round trip for EDNS, or four round trips (one TC=1 UDP, then
three for TCP) for non-EDNS. in your model, we would always use three
round trips. what does this optimize for?

your reference to [I-D.lee-dnsop-scalingroot] is in error. that draft
specifies two NS RR's, each having one A RR and one AAAA RR. thus, a
priming response from an authority server using that approach would fit
easily in 512 octets (without EDNS), with or without DNSSEC.

you wrote:

>    The author of this memo is the advocate for DNS over TCP, especially
>    on the very occasions when it is needed.  In this memo, the priming
>    exchange is identified as one of these occasions.

you have nowhere shown cause why root priming would be one of those
occasions.

you wrote:

>    From the technical point of view, the number of NS server should be
>    treated as a parameter of the root system, rather than a constant
>    making the root server as some kind of rare resource of Internet
>    which only incurs constant disputes with Internet governance issue. 

you say "from a technical point of view" but then you give a completely
non-technical reason. this makes your intent difficult to understand.

later you say "Without actions above, be aware of the large possibility
of risk due to truncated UDP packets or fragmentation", but you give no
specific examples. what risks do you know of -- and are we facing them
today?

in your listing of pro's and con's for this proposal, you note as a "pro":

>    1)Adding full A/AAAA address of Root server in priming response,
>    which will enhance the resiliency of Root system for IPv6 users,
>    especially under the consideration of IPv6-only deployment
>    [I-D.song-sunset4-ipv6only-dns]. 

i am appending below my signature a priming query performed just now,
using EDNS and DNSSEC. as you will see, all IPv6 addresses are present,
and there is plenty of room for additional addresses.

with specific reference to your mention of "constant disputes with
Internet governance issue", the only constantly disputed internet
governance issue i am aware of in the area of DNS root name service is
the desire by several national governments around the world to have a
root name server "letter" of their own, for prestige reasons. i usually
dismiss this as crazy talk, as you know. if however that is one of your
concerns, then i suggest you address it as a policy matter and not as a
technical matter. if someone told you that more countries can't have
their own "root name server letter" because root DNS priming queries
don't use TCP by default, then i would appreciate knowing exactly who
said it, and in what context, and when.

-- 
Paul Vixie

re:

; <<>> DiG 9.10.1b1 <<>> @f.root-servers.net +dnssec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45593
;; flags: qr aa rd; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 25
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION:
.                       518400  IN      NS      k.root-servers.net.
.                       518400  IN      NS      f.root-servers.net.
.                       518400  IN      NS      j.root-servers.net.
.                       518400  IN      NS      i.root-servers.net.
.                       518400  IN      NS      a.root-servers.net.
.                       518400  IN      NS      d.root-servers.net.
.                       518400  IN      NS      m.root-servers.net.
.                       518400  IN      NS      g.root-servers.net.
.                       518400  IN      NS      e.root-servers.net.
.                       518400  IN      NS      b.root-servers.net.
.                       518400  IN      NS      l.root-servers.net.
.                       518400  IN      NS      c.root-servers.net.
.                       518400  IN      NS      h.root-servers.net.
.                       518400  IN      RRSIG   NS 8 0 518400
20141203170000 20141126160000 22603 .
KdqZRoBzFv8Uzh6jksly2gCNGzaJtqa4c3P8LScFLQiPSh/pZ8DP+/Zb
pIIEYBON23y2cQBQF0KrFbOr3nlVHieYTSP76Y6VBPRa11V7f8GVrC47
bKdCULo5esc1u6C7OOCerLrXabP1UNdGq0SWfIXnyquJ6fhBVn0rt6jv jCw=

;; ADDITIONAL SECTION:
a.root-servers.net.     3600000 IN      A       198.41.0.4
a.root-servers.net.     3600000 IN      AAAA    2001:503:ba3e::2:30
b.root-servers.net.     3600000 IN      A       192.228.79.201
b.root-servers.net.     3600000 IN      AAAA    2001:500:84::b
c.root-servers.net.     3600000 IN      A       192.33.4.12
c.root-servers.net.     3600000 IN      AAAA    2001:500:2::c
d.root-servers.net.     3600000 IN      A       199.7.91.13
d.root-servers.net.     3600000 IN      AAAA    2001:500:2d::d
e.root-servers.net.     3600000 IN      A       192.203.230.10
f.root-servers.net.     3600000 IN      A       192.5.5.241
f.root-servers.net.     3600000 IN      AAAA    2001:500:2f::f
g.root-servers.net.     3600000 IN      A       192.112.36.4
h.root-servers.net.     3600000 IN      A       128.63.2.53
h.root-servers.net.     3600000 IN      AAAA    2001:500:1::803f:235
i.root-servers.net.     3600000 IN      A       192.36.148.17
i.root-servers.net.     3600000 IN      AAAA    2001:7fe::53
j.root-servers.net.     3600000 IN      A       192.58.128.30
j.root-servers.net.     3600000 IN      AAAA    2001:503:c27::2:30
k.root-servers.net.     3600000 IN      A       193.0.14.129
k.root-servers.net.     3600000 IN      AAAA    2001:7fd::1
l.root-servers.net.     3600000 IN      A       199.7.83.42
l.root-servers.net.     3600000 IN      AAAA    2001:500:3::42
m.root-servers.net.     3600000 IN      A       202.12.27.33
m.root-servers.net.     3600000 IN      AAAA    2001:dc3::35

;; Query time: 34 msec
;; SERVER: 2001:500:2f::f#53(2001:500:2f::f)
;; WHEN: Thu Nov 27 02:21:54 UTC 2014
;; MSG SIZE  rcvd: 913

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 27 Nov 2014 08:05:00 -0800

On Nov 26, 2014, at 11:18 AM, Davey Song <[email-masked]> wrote:
> Hi folks, I just post a draft on Priming Exchange over TCP. Comments are welcome!

The proposed solution is not needed as long as the resolver that using the priming exchange can fall back to TCP. A different approach to the document would be:

   Motivation: The root zone is longer than 512 octets,
   so responses to priming queries are truncated.

   Requirement: All resolvers that perform priming
   queries MUST be able to use TCP as specified in
   RFC 1035 when performing the priming query.

That should be an RFC of less than two pages, and would not involve making priming queries special enough to require a protocol change for them.

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Fri, 28 Nov 2014 09:14:34 +1100

In message <[email-masked]>, Paul Hoffman writes
:
> The proposed solution is not needed as long as the resolver that using the pr
> iming exchange can fall back to TCP. A different approach to the document wou
> ld be:
> 
> That should be an RFC of less than two pages, and would not involve making pr
> iming queries special enough to require a protocol change for them.
> 
> --Paul Hoffman
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

Additionally you may as well just implement EDNS.  The IPv6 response
won't be fragmented as it is < 1280 bytes and the IPv4 response is
unlikely to be fragmented as it is < 1500 bytes.  If you are making
DNS queries over IPv6 you are already required to support EDNS as
it is a node requirement.

All the root servers support EDNS as that is a prerequisite for
DNSSEC and if the firewall in front of your recursive server doesn't
it needs to be replaced if it can't support a 15 year old extension
to the protocol.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Davey Song <[email-masked]>
Date: Fri, 28 Nov 2014 14:32:56 +0800

Thanks Paul. Please see the reply in line.

On Thu, Nov 27, 2014 at 10:41 AM, Paul Vixie <[email-masked]> wrote:

>
>
>   Davey Song <[email-masked]>
> operational and policy choice for many years." your document does not give
> any examples of specific operational or policy constraints caused by this
> limitation.
>

I try to address the constraints in  section 2, see  "2. Operational and
policy constraints with Priming Exchange" . Actually, I start to study the
constraint from your draft (draft-ietf-dnsop-respsize-15)

> today a priming query returns 755 octets of udp payload without dnssec, or
> 913 octets of udp payload with dnssec. what's missing?
>

If a priming query only contains the existing NS/A/AAAA RRset of root zone,
and do not sign for A/AAAARRset, it will be OK,  given UDP fragmentaion
dose not happen.  But if it constrains the operational possibility for the
root zone operator who want to address issue in section2.2 and section 2.3.

> three for TCP) for non-EDNS. in your model, we would always use three round
> trips. what does this optimize for?
>

In you draft (draft-ietf-dnsop-respsize-15)  ,it mentioned "Note that
truncation of the additional data section might not be signaled via the TC
bit since additional data is often optional (see discussion in Appendix B
of [RFC4472]).". I execute "dig . ns  +noedns @l.root-servers.net " on my
desktop and receive a reply packets (<512bytes) without truncated. So in
that case the resolver will not issue any other AAAA query. it  lose other
AAAA records.

As to the optimization,  Fast open TCP (dickinson-dnsop-5966-bis,
ietf-tcpm-fastopen) may helps in that case  involving only 1 or 2 rounds
trips. it need more work to test Fast open TCP to check whether (or to what
extent) it can relieve the constraints described in section 2.

> easily in 512 octets (without EDNS), with or without DNSSEC.

Yes. It's my problem. "13 to millions" is not your word in the draft. I
should be more precise.

> occasions

you wrote:
> later you say "Without actions above, be aware of the large possibility of
> risk due to truncated UDP packets or fragmentation", but you give no
> using EDNS and DNSSEC. as you will see, all IPv6 addresses are present, and
> there is plenty of room for additional addresses.
>
> governance issue i am aware of in the area of DNS root name service is the
> desire by several national governments around the world to have a root name
> server "letter" of their own, for prestige reasons. i usually dismiss this
> as crazy talk, as you know. if however that is one of your concerns, then i
> suggest you address it as a policy matter and not as a technical matter.
> if someone told you that more countries can't have their own "root name
> server letter" because root DNS priming queries don't use TCP by default,
> then i would appreciate knowing exactly who said it, and in what context,
> and when.
>
>
 I try to express the idea: is there any possibility that if we can breaks
the rareness of Root servers. The arguments and disputes will cease
accordingly. Actually  this idea is out of the scope of this draft.

--

---

From: Paul Vixie <[email-masked]>
Date: Thu, 27 Nov 2014 23:21:22 -0800

Davey Song wrote:
>  I try to express the idea: is there any possibility that if we can
> breaks the rareness of Root servers. The arguments and disputes will
> cease accordingly. Actually  this idea is out of the scope of this draft. 

i think there is an interesting research question here: how many root
name servers is too many, and what are the limitations, and what is the
optimal number of root name servers?

for example, if 13 is good, would 130 (10X) or 1300 (100X) be better?
even with 1300 root name servers, the fallback to TCP after TC=1 in a
priming query (even with EDNS) would only add one extra round trip over
the three that are required to run a TCP query. since priming queries
are uncommon, i still don't see why that first round trip is worth avoiding.

RDNS servers who perform round trip measurements to each potential name
server for each zone cut would have a lot more state to maintain, but
that state would not be large by today's standards (DNSSEC signatures
have bloated RDNS memory footprints far more, without concern.)

however, the systemic complexity of all those RDNS servers performing
all those measurements seems like cause for concern. with 1300 root name
servers, it would take 1300 referrals for any given RDNS server to learn
which root name server was closest to it. unless all 1300 of those
servers are widely anycast, then many of those initial 1300 referrals
would have suboptimal round trip times. also with that many servers,
error theory predicts that some number of them will be unreachable,
causing retries that add to the total number of referral events required
to locate the closest (by RTT) root server.

if 1300 is obviously too many, why? what's the optimal number of root
name servers for an RDNS population estimated to be about 40M? does the
optimal number change when some share of root name servers are widely
anycasted?

i share these research questions for four reasons.

first, ZDNS and BII are ideally suited to investigate this matter in
your test bed.

second, there is no evidence at present that "13" is too many or too few
root servers.

third, this line of thinking is what led to my ICANN ITI proposal
involving only two root name server identities, each of which being
massively and hierarchically anycasted.

fourth, because without an answer to these research questions, it's
impossible to evaluate the cost and complexity tradeoff against
increased internet resilience from pursuing your "tcp-primingexchange"
proposal.

-- 
Paul Vixie

---

From: Declan Ma <[email-masked]>
Date: Fri, 28 Nov 2014 15:35:15 +0800

Paul, 

	I go along with the “optimal number of root name servers”. 

	Besides, the distribution of root zone file among the servers with a pleasing latency therefore bears importance.

	Truly an interesting topic for the testbed by ZDNS and BII. 

Declan Ma

ZDNS Ltd.

> 在 2014年11月28日，下午3:21，Paul Vixie <[email-masked]> 写道：
> 
> 
> 
> Davey Song wrote:

---

From: Davey Song <[email-masked]>
Date: Fri, 28 Nov 2014 16:22:03 +0800

On Fri, Nov 28, 2014 at 3:21 PM, Paul Vixie <[email-masked]> wrote:

> At least we can try Fast Open TCP on it to save more round for performance
purpose .

Priming exchange is special because this exchange lead the people to the
unique name space of Internet. If we share the same dream of "One World One
Internet" , any extra effort is deserved to protect its resiliency in IPv6
network(section 2.1), integrity with fully signed(section 2.2) and more NS
server to enable more participation of  CDOs. (section 2.3)

> to locate the closest (by RTT) root server.
The difficulty of comparing 1300 referrals triggers me to think of
introducing special measures to Priming Exchange, such as the mechanism
like CDN/smart DNS to return a set of address (maybe less than 5) best suit
for the resolver.  Well, if that possible, that requirement makes Priming
Exchange more special because it break the  atomic principle of DNS.

> Thanks Paul. our discussion broadens and enrich our thinking on section
2.3 issue. We  will continue working on that to explore the space for
the question and answer .

As to the draft,  be aware the proposal  is not particularly for the root
 NS number issue.   Actually I realized in advance that if section 2.3 is
too controversial I will think of remove or amend it.

Davey

---

From: Paul Vixie <[email-masked]>
Date: Fri, 28 Nov 2014 00:30:36 -0800

> Friday, November 28, 2014 12:22 AM
>
> On Fri, Nov 28, 2014 at 3:21 PM, Paul Vixie <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
> At least we can try Fast Open TCP on it to save more round for
> performance purpose .

if it's a rare query, then what is the payback for the complexity of
treating this query differently from other dns queries?
>  
>
> Priming exchange is special because this exchange lead the people to
> the unique name space of Internet. If we share the same dream of "One
> World One Internet" ,

you know i do.

> any extra effort is deserved to protect its resiliency in IPv6
> network(section 2.1), integrity with fully signed(section 2.2) and
> more NS server to enable more participation of  CDOs. (section 2.3)

with respect to ipv6 support, as marka@isc said, ipv6 nodes must support
edns, and a minimum of 1280 bytes. this means that without truncation or
TCP, all 13 servers can have their AAAA RR's returned in a single round
trip.

with respect to dnssec support, dnssec does not sign glue. there is one
signature, over the NS RRset for the ".", which as shown in my previous
example, fits with all 13 A RR's and 12 AAAA RR's in less than 1000 octets.

with respect to enabling more participation by CDO's, that is not a
technical consideration, but i think you can progress that matter by
modeling the optimal number of root name servers for the expected RDNS
population and the expected AS graph. in other words, if more would be
better for the internet itself, in terms of reliability and performance
and security and resiliency, that is a technical consideration worth
arguing here.

vixie

---

From: Davey Song <[email-masked]>
Date: Fri, 28 Nov 2014 17:25:52 +0800

Hi Paul Hoffman, I appreciate your comments which touches the key point of
my concern.

Yes, two pages is enough to address the problem with your suggestion. It
actually turns off the EDNS0 during Priming Exchange, right ?

On Fri, Nov 28, 2014 at 12:05 AM, Paul Hoffman <[email-masked]>
wrote:

> The proposed solution is not needed as long as the resolver that using the
> priming exchange can fall back to TCP. A different approach to the document
> would be:
>
> That should be an RFC of less than two pages, and would not involve making
> priming queries special enough to require a protocol change for them.
>
> --Paul Hoffman

---

From: Davey Song <[email-masked]>
Date: Fri, 28 Nov 2014 18:48:23 +0800

Oh, I may misunderstood. If you only require resolver able to use TCP , is
there anything new?

As far as I know,  there are three exist  problems in DNS protocol (not
only on Priming exchange),

1)  IP-level udp fregment ( EDNS0 make it more frequently)
2)  No truncation for referral response which cause no TCP fallback for
more AAAA record of NS server(root serve in this case )
3)  No larger size than 1500B for single UDP packets.

I only see TCP can overcome all those problems. and Priming Exchange is the
very occasion to firstly deploy TCP by default with much less price. And it
is promising to become  a start to evaluation of upgrading the whole DNS
system for more reasons like DNS privacy and prevention of DDoS attack.

Davey

On Fri, Nov 28, 2014 at 5:25 PM, Davey Song <[email-masked]> wrote:

>> The proposed solution is not needed as long as the resolver that using
>> the priming exchange can fall back to TCP. A different approach to the
>> document would be:
>>
>> That should be an RFC of less than two pages, and would not involve
>> making priming queries special enough to require a protocol change for them.
>>
>> --Paul Hoffman
>
>
>

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 28 Nov 2014 07:17:26 -0800

On Nov 28, 2014, at 1:25 AM, Davey Song <[email-masked]> wrote:
> Yes, two pages is enough to address the problem with your suggestion. It actually turns off the EDNS0 during Priming Exchange, right ?

No, not at all. EDNS0 is orthogonal to "must be able to use TCP as specified in RFC 1035". EDNS0 is useful, but not required, to get a full priming query back when using TCP.

On Nov 28, 2014, at 2:48 AM, Davey Song <[email-masked]> wrote:
> Oh, I may misunderstood. If you only require resolver able to use TCP , is there anything new?

No, and that's exactly the point.

> As far as I know,  there are three exist  problems in DNS protocol (not only on Priming exchange), 
> 
> 2)  No truncation for referral response which cause no TCP fallback for more AAAA record of NS server(root serve in this case )

None of which matter if the priming query is done over TCP. By saying "must be able to use TCP as specified in RFC 1035", you allow a recursive to start with UDP and try again on TCP if they see a truncated answer, *or* to try on TCP initially. This then becomes a configuration issue.

> I only see TCP can overcome all those problems. and Priming Exchange is the very occasion to firstly deploy TCP by default with much less price. And it is promising to become  a start to evaluation of upgrading the whole DNS system for more reasons like DNS privacy and prevention of DDoS attack.

Maybe have this document stay focused, and do not try to tack the latter on to the former in the document.

--Paul Hoffman