Subject: Re: [DNSOP] DNSSEC in draft-ietf-dnsop-resolver-priming

From: Shane Kerr <[email-masked]>
Date: Thu, 18 Feb 2016 12:06:16 +0100

Duane,

At 2016-01-26 22:32:45 +0000
"Wessels, Duane" <[email-masked]> wrote:

> > On Jan 23, 2016, at 2:25 PM, Matthäus Wander <[email-masked]> wrote:
> > 
> > 
> > There's another issue: once root-servers.net is signed, the priming
> > response will contain RRSIG in the ADDITIONAL section.  
> 
> Indeed.  According to my simple test if root-servers.net is signed (the
> same way as the root zone), the response size jumps quite a bit:
> 
> 
> EDNS0?  UDPsize  DO=  RSN signed?  resp size
> ------  -------  ---  -----------  ---------
>   n        -      -        n         492-512
>   y       4096    0        n             755
>   y       4096    1        n             913
>   y       8192    1        y            4081
> 
> And these sizes could increase if two remaining letters decide to add AAAA records.

This means that the section talking about the EDNS reassembly size
could become outdated:

   The recursive resolver SHOULD use EDNS0 [RFC6891] for priming queries
   and SHOULD announce and handle a reassembly size of at least 1024
   octets [RFC3226].  Doing so allows responses that cover the size of a
   full priming response (see Section 4.2).

I guess a new RFC can be rolled if root-servers.net is signed, but
we could just future-proof it now and recommend a larger size?

Of course, if the result is larger than 4096 - the most common value
for EDNS right now IIRC - then maybe we should just start recommending
TCP right away? (My colleague Davey Song actually has an expired draft
saying just that - draft-song-dnsop-tcp-primingexchange - but I think
that a single sentence in the priming draft saying something like "if
the DO bit is set, then TCP SHOULD be used, since a UDP response may
be truncated" is enough).

Personally I think TCP for root priming makes complete sense, since root
priming traffic is a small fraction of a percent of both root server
traffic and resolver queries. (In fact this is a subset of the general
set of queries where "if you expect truncation, just start with TCP".
That's a possibly useful optimization that probably nobody has bothered
with because truncation is very rare.)

Cheers,

--
Shane

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 18 Feb 2016 22:18:14 +0000

> On Feb 18, 2016, at 3:06 AM, Shane Kerr <[email-masked]> wrote:
> 
> Duane,
> 

I took a look at some data to see if priming queries truly are a small
fraction.  From what I see, about 3.5 to 4.0% of root server traffic is
priming queries.  I have a "second opinion" analysis running at DNS-OARC
but that is taking longer, so if it indicates anything different I'll
follow up.

I guess I'm a little hesitant here because in an earlier discussion on this
document we talked about saying "resolvers SHOULD send DO when priming"
and if we add "SHOULD use TCP when DO is set" then TCP sort of becomes
the default for all priming queries.  Unless and until the root-servers.net
zone is signed, the priming response doesn't really need TCP because it can
entirely fit in an unfragmented UDP packet.

DW

---

From: Shane Kerr <[email-masked]>
Date: Mon, 22 Feb 2016 17:04:01 +0100

Duane,

At 2016-02-18 22:18:14 +0000

> but that is taking longer, so if it indicates anything different I'll

Just for clarification, does this mean 3.5% to 4.0% of all root server
traffic or 3.5% to 4.0% of "non-junk" root server traffic?

I ask because I am assured that 90% of root server traffic is junk. If
you are talking about 3.5% to 4.0% of all root traffic, then this means
that more than 1/3 of "real" traffic is root priming, which seems
really high to me.

If you're talking bout 3.5% to 4.0% of non-junk traffic, then it's
something like 0.4% of all traffic, which is still more than I would
expect, but not shockingly so.
 
> I guess I'm a little hesitant here because in an earlier discussion
> on this document we talked about saying "resolvers SHOULD send DO
> when priming" and if we add "SHOULD use TCP when DO is set" then TCP
> sort of becomes the default for all priming queries.  Unless and
> until the root-servers.net zone is signed, the priming response
> doesn't really need TCP because it can entirely fit in an
> unfragmented UDP packet.

Let me turn this around... why would you not use TCP for root priming?

One concern might be that root servers are easier to DoS via TCP
exhaustion, causing priming to fail. Are there other issues?

Cheers,

--
Shane

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 22 Feb 2016 18:09:05 +0000

> On Feb 22, 2016, at 8:04 AM, Shane Kerr <[email-masked]> wrote:
> 
> Duane,
> 

Of all root server traffic.

> that more than 1/3 of "real" traffic is root priming, which seems

I think some priming queries could also be considered junk.  For example,
repeated within a short amount of time, or within the amount of time that
you'd expect the response to be cached.  Unfortunately I don't have numbers
to report at this time.

> exhaustion, causing priming to fail. Are there other issues?

Noting that the "you" in your question is sort of ambiguous, the reasons
people give for "why not" are just the usual ones that we're all pretty
well aware of.  On the client side: latency and middleware blockage.  On
the server side: additional state.

Again, I feel like we're only considering to suggest TCP as a default for
priming because root-servers.net *might* be signed, but to me there is
a lot of uncertainty around that and we shouldn't necessarily recommend
TCP by default at this time.  But if we do end up recommending TCP for
root priming, I think we need input from the root server operators first.

DW