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

From: Davey Song <[email-masked]>
Date: Sat, 6 Dec 2014 15:03:44 +0800

Mark, thank you for your comments. Sorry for the late response. Please see
inline.

On Fri, Nov 28, 2014 at 6:14 AM, Mark Andrews <[email-masked]> wrote:

>
> In message <[email-masked]>, Paul Hoffman
> writes
> :
> > 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 we
> > lcome!
> >
> > 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:
> >
> >    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 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.
>

As Paul Hoffman said, EDNS0 (or IPv6 with larger MTU) is orthogonal to TCP
which are both designed for larger packets.

EDNS0 has some problems in reality which is is not easy to solve : 1)
penetration of its deployment (around 65%?, no response and misbehave in
authority server side); 2) unexpected IP-level fragmentation cause by
middle-box/firewall (10% in recent work:
http://www.cs.ru.nl/~rijswijk/pub/ieee-commag-dnssec-2014.pdf)

In RFC1035,  datagrams (UDP) are preferred for queries due to their lower
overhead and better performance. Virtual circuits(TCP) is required for
reliable transfer, like Zone refresh activities. In fact, this draft
propose that the priming exchange also require reliable transfer via TCP by
default, given that the truncation(&signing) dose not work for referral
response which is very import for Priming exchange.

Surly, It is fully aware that TCP is more cost than UDP. But the cost can
be estimated and controlled in the case of priming exchange.  In addition
it is possible that effort can be made into the optimization of TCP support
in current DNS implementation.

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.

I agree with the argument in the IEEE measurement paper. Given the
long-tail feature of deployment for both EDNS0 and IPv6, there alwasy a
small percentage of  users would have connectivity issues, it is clear that
we cannot rely on resolver/firewall operators alone to tackle this issue.

 Adoption of any new proposal always has its difficulty. It is not cost
free. So we hope to bring as little changes as possible to address the
issues.

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: Sat, 6 Dec 2014 15:16:04 +0800

On Fri, Nov 28, 2014 at 11:17 PM, Paul Hoffman <[email-masked]>
wrote:

> 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),
> >
> > 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.
>
> 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'm not sure I got your meaning by saying "*or* to try on TCP initially" .
Dose this mean you agree we can initiate TCP before UDP/EDNS0 or the hint
to send TCP/UDP query at the same time like the "happy eyeballs" mechanism
in dual stack ?

You see if the resolve use EDNS0 to initiate the priming query, it is much
less possible to use TCP as a backup.

> 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

---

From: "Guangqing Deng" <[email-masked]>
Date: Sun, 7 Dec 2014 10:40:35 +0800

Interesting research questions! For DNS root service, the number of and the load balance among root severs are of importance, just as said before. And the globally geographical distribution of those root servers seems also important. To answer these research questions, it seems that first we should learn more about the Internet, such as the AS level topology, the RTT between ASs, the efficiency of anycast mechanisms, et al. It seems that to answer these DNS related questions, we should not only understand the DNS protocols themselves but also the Internet network where the DNS resides in. 

Guangqing Deng
cnnic 

From: Paul Vixie
Date: 2014-11-28 15:21
To: Davey Song
CC: dnsop
Subject: Re: [DNSOP] Fwd: I-D Action: draft-song-dnsop-tcp-primingexchange-00.txt

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