Subject: [DNSOP] Closing out issues in draft-ietf-dnsop-resolver-priming

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 15 Oct 2015 17:06:11 -0700

<secretary hat on>

Greetings. The WG has a draft, draft-ietf-dnsop-resolver-priming, which 
has somewhat fallen off the table, and it is time to bring it back. The 
draft has two identified open issues, and the authors would like the WG 
to clear those up before issuing a new draft, and then hopefully going 
to Working Group Last Call. Because the draft is expired, to review it, 
please see:
   https://tools.ietf.org/html/draft-ietf-dnsop-resolver-priming-05

The two open issues are in Section 4:

4.  Requirements for Root Name Servers and the Root Zone

    The operational requirements for root name servers are described in
    [RFC2870].  This section specifies additional guidance for the
    configuration of and software deployed at the root name servers.

    All DNS root name servers need to be able to provide for all
    addresses of all root name servers.  This can easily achieved by
    keeping all root name server names in a single zone and by making 
all
    root name servers authoritative for that zone.

    If the response packet does not provide for more than 512 octets due
    to lack of EDNS0 support, A RRSets SHOULD be given preference over
    AAAA RRSets when filling the additional section.

    [[Issue 1: EDNS0 is used as an indication of AAAA understanding on
    the side of the client.  What to do with payload sizes indicated by
    EDNS0 that are smaller than 1024, is open to discussion.  At the 
time
    of writing, some root name servers will fill the additional section
    with all available A RRSets, only adding some AAAA RRSets, when
    queried over IPv4 without EDNS0.  Other servers will deliver more
    AAAA RRSets, therefore withholding some A RRSets completely
    [RFC4472].]]

    To ensure equal availability the A and AAAA RRSets for the root name
    servers' names SHOULD have identical TTL values at the authoritative
    source.

    [[Issue 2: Do the TTLs for the root NS RRSet and address RRSets in
    the root and the ROOT-SERVERS.NET. zones need to be aligned?  In 
real
    life responses, the address RRSet's TTL values vary by name server
    implementation.  Is this diversity we can live with?  Should the
    authoritative source prevail?  Is it therefore a protocol issue
    rather than an operational choice of parameters?]]

The question at this point is: what should we do about each issue? 
Specific wording is appreciated.

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Fri, 16 Oct 2015 15:06:04 +1100

In message <[email-masked]>, "Paul Hoffman" writ
>     AAAA RRSets when filling the additional section.

I would recommend that the transport family used to make the query
should be the determining factor for which additional records are
dropped.

* A query over IPv6 gets AAAA records in preference to A records.
* A query over IPv4 gets A records in preference to AAAA records.

If we want to treat these additional records as glue then TC=1
should be set but the response should also be as fully populated
as possible.  Then client that:
* support TCP will get the full response over TCP.
* that only support UDP will get what they can from the truncated
  response.  They will be doing this for other responses.
* Those behind broken firewalls that block TCP out loose but they
  loose anyway on other queries where the response has TC=1.

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Tony Finch <[email-masked]>
Date: Fri, 16 Oct 2015 11:04:48 +0100

> should be the determining factor for which additional records are

I was going to make the same point :-)

> >     What to do with payload sizes indicated by
> >     EDNS0 that are smaller than 1024, is open to discussion.

Do the same thing with or without EDNS0.

> >     At the time
> >     queried over IPv4 without EDNS0.

They have the same behaviour (prioritize A) when queried on IPv6.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Lundy, Fastnet, Irish Sea: Northeast 4 or 5. Slight or moderate, but smooth or
slight in Irish Sea. Fair. Good.

---

From: "宋林健" <[email-masked]>
Date: Fri, 16 Oct 2015 21:20:22 +0800

FYI. I once proposed this in draft-davey-sunset4-ipv6onlydns-00.

3.2.  IPv6-aware DNS Referral Response Mechanism

In section 2.2, due to the limitation of DNS referral response size,it may occur that when new NS server updated to IPv6, the address cannot be carry in the referral response in the first place without EDNS0 support.  It may deliver the incomplete view of IPv6 Internet to IPv6 only recursive server and IPv6-only users.  For example, the Root zone and any zones with more than 9-10 authority server may face the problem.

One intuitive thinking is that if the query is on IPv6 connection, the IPv6 addresses should be carried with high priority in DNS response if there is not enough room for all the NS RR.  For example, as a key internet public services, IPv6 addresses of root name servers will be entirely contained in the referral response over IPv4 address information in dual-stack environment.

Davey
-----
Sent from my phone 

---Original---
From: "Tony Finch"<[email-masked]>
Date: 2015/10/16 18:04:48
To: "Mark Andrews"<[email-masked]>;
Cc: "dnsop WG"<[email-masked]>;"Paul Hoffman"<[email-masked]>;
Subject: Re: [DNSOP] Closing out issues in draft-ietf-dnsop-resolver-priming

Tony.

---

From: Shane Kerr <[email-masked]>
Date: Fri, 16 Oct 2015 16:18:31 +0200

Paul,

Thanks for not letting this document die. :)

On Thu, 15 Oct 2015 17:06:11 -0700

>    https://tools.ietf.org/html/draft-ietf-dnsop-resolver-priming-05

I have separate issue, which is this text:

    The priming query MUST be sent over UDP (section 6.1.3.2 of
    [RFC1123]).

This seems like a super-strong recommendation that doesn't actually
help anything in operation.  Further, it seems to conflict with a
general desire to make TCP the equal of UDP in DNS.

Cheers,

--
Shane

---

From: Bob Harold <[email-masked]>
Date: Fri, 16 Oct 2015 10:24:59 -0400

On Thu, Oct 15, 2015 at 8:06 PM, Paul Hoffman <[email-masked]> wrote:

> draft has two identified open issues, and the authors would like the WG to
> clear those up before issuing a new draft, and then hopefully going to
> Working Group Last Call. Because the draft is expired, to review it, please
> see:
>    keeping all root name server names in a single zone and by making all
>    EDNS0 that are smaller than 1024, is open to discussion.  At the time
>    the root and the ROOT-SERVERS.NET. zones need to be aligned?  In real
> The TTL's are part of the zone, transferred from the master, and should
not vary by name server, if I understand correctly.

Does DNSSEC signing not cover the important glue records?  If we could get
them signed, I think it would be more secure, but it might be too late for
a change like that.

As for whether the parent and child agree on the TTL's is a separate
issue.  I believe that the child TTL's usually overwrite the parent TTL's
in a resolver's cache.

-- 
Bob Harold

---

From: "Joe Abley" <[email-masked]>
Date: Fri, 16 Oct 2015 10:27:27 -0400

> 4.  Requirements for Root Name Servers and the Root Zone

I think it might be worth stepping up a level here and understanding 
what this document can reasonably specify.

2870 has long been recognised to be obsolete. The direction for fixing 
that (which, who knows, might actually result in action at some point) 
can be summarised as the union of draft-iab-2870bis (currently approved 
for BCP, sitting in the RFC Editor queue) and RSSAC-001 (currently 
waiting for 2870bis to be published).

The approach being taken is that the IETF provides protocol-level 
requirements, and RSSAC documents the operational expectations that are 
reasonable to have of root server operators.

Analogously, and relevant to this document, the contents of the root 
zone, the names of root servers, and the operational practicalities of 
the ROOT-SERVERS.NET zone (contents, and where it is hosted) are 
currently managed by the IANA Functions Operator under contract. RSSAC 
is currently working on analysis and advice to ICANN on the question of 
whether the current naming scheme could be improved upon.

This document, I believe, needs some revision to make sure it stays on 
the right side of the line between technical policy (from the IETF), 
administrative policy (from the IANA Functions Operator) and operational 
policy (from the root server operators, as documented by RSSAC).

> configuration of and software deployed at the root name servers.

I think this document needs to be clear that the requirements it is 
imposing on the system as a whole are protocol-level requirements, and 
not operational or administrative.

I am deliberately not suggesting edits to the current text or responding 
to the two issues you highlighted in this message; I think it's 
important to get consensus first about the scope of guidance that this 
document can provide.

To be clear, I think it's important and necessary that the priming 
process be documented; I just think we need to be careful that we do it 
from a protocol perspective.

Joe

---

From: Paul Vixie <[email-masked]>
Date: Fri, 16 Oct 2015 08:35:30 -0700

Shane Kerr wrote:
> ...

i do not share, or approve of, any such "general desire". i think the
text is correct as written.

-- 
Paul Vixie

---

From: 神明達哉 <[email-masked]>
Date: Fri, 16 Oct 2015 09:48:44 -0700

At Fri, 16 Oct 2015 08:35:30 -0700,

> text is correct as written.

Although the existence of the "general desire" might be debatable, I
think Shane has a valid point.  The requirement level of the TCP
support has been already tightened in RFC5966 (from a SHOULD in
RFC1123 to REQUIRED), so it doesn't make much sense to me to use a
MUST in this document referring to the older RFC.  At the very least,
if we want to keep the MUST, there should be a different reason than
the reference to RFC1123.

--
JINMEI, Tatuya

---

From: "Darcy Kevin (FCA)" <[email-masked]>
Date: Fri, 16 Oct 2015 17:07:27 +0000

Let's see, millions of full-service resolvers, times the packet-count differential between UDP and TCP, times the average reload/restart frequency of those full-service resolvers per day/week/month. Can't a case be made from sheer volume?

Sorry for bringing math into the discussion.

									- Kevin

-----Original Message-----
From: DNSOP [mailto:[email-masked]] On Behalf Of ????
Sent: Friday, October 16, 2015 12:49 PM
To: Paul Vixie
Cc: Shane Kerr; dnsop WG; Paul Hoffman
Subject: Re: [DNSOP] Closing out issues in draft-ietf-dnsop-resolver-priming

> text is correct as written.

Although the existence of the "general desire" might be debatable, I think Shane has a valid point.  The requirement level of the TCP support has been already tightened in RFC5966 (from a SHOULD in
RFC1123 to REQUIRED), so it doesn't make much sense to me to use a MUST in this document referring to the older RFC.  At the very least, if we want to keep the MUST, there should be a different reason than the reference to RFC1123.

--
JINMEI, Tatuya

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 16 Oct 2015 10:15:45 -0700

On 16 Oct 2015, at 10:07, Darcy Kevin (FCA) wrote:

> Let's see, millions of full-service resolvers, times the packet-count 
> differential between UDP and TCP, times the average reload/restart 
> frequency of those full-service resolvers per day/week/month. Can't a 
> case be made from sheer volume?

The root operators have shown no concern about legitimate resolvers 
asking a lot more queries. Given that using TCP for priming helps 
mitigate an injection attack, and given one extra round trip would be 
less than 1% of the expected load from these resolvers, the "sheer 
volume" seems trivial.

> Sorry for bringing math into the discussion.

No need to apologize. If you disagree with my calculations above, that's 
fine, but if you agree with them, then allowing TCP for priming queries 
will lead to an insignificant increase in traffic to servers that have 
said they are able to handle the normal requests just fine.

--Paul Hoffman

---

From: "Joe Abley" <[email-masked]>
Date: Fri, 16 Oct 2015 13:58:00 -0400

On 16 Oct 2015, at 13:15, Paul Hoffman wrote:

> mitigate an injection attack,

Have we characterised this attack at all?

We're talking principally about a risk to resolvers that prime but don't 
validate, right?

Joe

---

From: Paul Vixie <[email-masked]>
Date: Fri, 16 Oct 2015 18:30:52 +0000

On Friday, October 16, 2015 13:58:00 Joe Abley wrote:
> > asking a lot more queries.

i am a root operator and i reject your characterization of my position.

i don't want tcp tried first, ever. i understand that tcp would be tried 
first, for new-fangled clients who want to try to negotiate persistent tcp. 
but that should not include the priming query, because root name servers are 
expected to have a large number of rdns servers to serve, and tcpcb's will 
always be finite.

> > Given that using TCP for priming helps

given that tcp is often blocked by firewalls since udp mostly just works and 
has always been tried first, i think that leaning on tcp to help with a 
priming injection attack has a low success likelihood. let's get the injection 
attack solved in other ways, for example, using dns cookies.

-- 
Paul

---

From: Shane Kerr <[email-masked]>
Date: Fri, 16 Oct 2015 20:42:02 +0200

Joe,

On Fri, 16 Oct 2015 13:58:00 -0400

> Have we characterised this attack at all?

Seems like quite an easy attack at first blush. One could send a
constant stream of priming answers to resolvers since they would get
made once a day.

While the chance of poisoning any one resolver with such a response is
low, the impact is catastrophic to a non-validating resolver, as an
attacker basically owns your view of the Internet at that point. For
resolvers that do validate, the only issue is information leakage that
a random party can see all of your root queries (or possibly a DoS). 

> We're talking principally about a risk to resolvers that prime but don't 

This draft also says that you MUST NOT set the DO bit on priming
queries, so any resolver following this draft isn't validating.

While a resolver could validate the NS RRSET, as you know the
ROOT-SERVERS.NET domain is not signed, so the A and AAAA records
(what you really care about) cannot be validated.

I know there is discussion about signing the root servers somehow, so
perhaps a resolver that cares could someday validate the priming
query... but we should probably remove the MUST NOT text around the DO
bit then, perhaps replacing it with a SHOULD recommending validation.

Cheers,

--
Shane

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 16 Oct 2015 11:47:54 -0700

> i am a root operator and i reject your characterization of my 

I meant the root operators as a group, not every single person who works 
for or with a rootop.

> expected to have a large number of rdns servers to serve, and tcpcb's 

Are you arguing for a special case of "TCP to authoritative servers is 
fine, but not for the root servers"? If so, that's an interesting 
discussion for draft-ietf-dnsop-5966bis, which is still in WG Last Call.

> priming injection attack has a low success likelihood.

If a recursive resolver is behind a firewall that blocks TCP, the 
priming query will time out and they will use UDP.

> let's get the injection

If you believe that the extra CPU required for a root server to support 
https://tools.ietf.org/html/draft-ietf-dnsop-cookies-05 is less of a 
threat to the operations of the root server than that of persistent TCP 
connections, it would be great to see a write-up on that. The 
intelligent use of state for TCP seems to be similar to that for 
cookies, but comes with some major advantages. If rootops as a group 
support cookies instead of TCP, that's valuable information, but we 
haven't heard that yet.

--Paul Hoffman

---

From: Paul Vixie <[email-masked]>
Date: Fri, 16 Oct 2015 18:54:32 +0000

> discussion for draft-ietf-dnsop-5966bis, which is still in WG Last Call.

no. as i wrote above, i just don't want tcp tried first for priming, no matter 
what tcp session persistency specifications may evolve separately. therefore 
the text in the current version of the draft is fine by me.

> priming query will time out and they will use UDP.

well, sure. but there's no reason to risk that timeout. we know udp is going 
to work, and, we know we have to secure udp against insertion attacks using 
something other than source port randomization. dns cookies are a given, from 
the point of view that this priming rfc will live in. so there's no need for 
tcp in priming, and definitely no cause to risk a timeout or to create even a 
temporary state burden on the root name servers during priming.

> connections, it would be great to see a write-up on that.

i hadn't mentioned cpu load. i'm talking about state load. cpu is very easy to 
upgrade, whereas tcp state blob storage, not so easy.

> The

the rootops as a whole don't, and won't, take a position on matters of this 
sort. this would be a matter for the rssac caucus to discuss and address. (the 
rootops are members of the rssac caucus, along with a lot of other people.)

-- 
Paul

---

From: "Joe Abley" <[email-masked]>
Date: Fri, 16 Oct 2015 15:06:50 -0400

> constant stream of priming answers to resolvers since they would get

The successful attacks like this that I've seen rely upon being able to 
trigger a particular query from a resolver so that you can bombard it 
with responses in the hope of matching a query id. If there's no viable 
trigger (unless you can exploit a software defect and trigger a restart) 
the attack seems harder.

> a random party can see all of your root queries (or possibly a DoS).

Agreed, that the impact could be high if an attack is successful. My 
questions are principally about the probability of success, I guess.

> (what you really care about) cannot be validated.

Right, and I think that's only a big problem for validators if the key 
assets you are relying upon (the answers that end users are using the 
DNS to fetch) are for qnames like L.ROOT-SERVERS.NET, which outside 
operational troubleshooting seems unlikely to be true.

An end-user looking for answers about ISC.ORG or PAYPAL.COM are going to 
be protected so long as there are signatures all the way down to those 
zones, regardless of what junk they receive from their priming query. 
Protected from junk, that is, not protected from unavailability.

> bit then, perhaps replacing it with a SHOULD recommending validation.

The last time I did any thinking about this, presupposing widespread 
DNSSEC deployment by zone maintainers and widespread validation, there 
was no obvious benefit to security to be found in signing the 
ROOT-SERVERS.NET zone or RRSets returned in a priming response. There 
was, however, the potential for greatly enlarged priming responses.

I appreciate that this draft says you MUST NOT set DO=1 on priming 
queries, but the reality is that everybody does.

Joe

---

From: Shane Kerr <[email-masked]>
Date: Fri, 16 Oct 2015 22:21:02 +0200

Joe,

On Fri, 16 Oct 2015 15:06:50 -0400

> questions are principally about the probability of success, I guess.

Yes, that's the question. :)

I think it depends on whether an attacker is interested in attacking a
specific resolver or whether they are content to fish.

You can't trigger the query, but you know for certain the exact query
that will be made 1x per day by almost every recursive resolver on the
Internet. Given that there are reportedly 20 million *open* resolvers on
the Internet, the chance of being able to exploit *some* resolver based
on priming queries seems actually pretty good.
 
> Right, and I think that's only a big problem for validators if the
> key assets you are relying upon (the answers that end users are using
> the DNS to fetch) are for qnames like L.ROOT-SERVERS.NET, which
> outside operational troubleshooting seems unlikely to be true.
> 
> An end-user looking for answers about ISC.ORG or PAYPAL.COM are going
> to be protected so long as there are signatures all the way down to
> those zones, regardless of what junk they receive from their priming
> query. Protected from junk, that is, not protected from
> unavailability.

Good point. As I mentioned the risk to validating resolvers is just
information leakage (or DoS). But both of those could be avoided by
validating the priming query, so why not?
 
> > I know there is discussion about signing the root servers somehow,
> > so perhaps a resolver that cares could someday validate the priming
> > query... but we should probably remove the MUST NOT text around the
> > DO bit then, perhaps replacing it with a SHOULD recommending
> > validation.
> 
> DNSSEC deployment by zone maintainers and widespread validation,
> there was no obvious benefit to security to be found in signing the 

I really don't understand the phobia about enlarging priming responses.
It's practically another argument to use TCP for this so we don't have
to worry. ;)

> queries, but the reality is that everybody does.

Which makes me think this should be changed.

Cheers,

--
Shane

---

From: "Darcy Kevin (FCA)" <[email-masked]>
Date: Fri, 16 Oct 2015 20:36:05 +0000

It would be wise to get a clear statement of preference from the Internet root operators on this, but don't forget that whatever gets defined in IETF standards, and implemented in leading DNS software packages, also affects private enterprises too. Many of us run internal roots and I, for one, don't want to see an influx of traffic and/or spiky saturation of bandwidth, because priming suddenly morphed from UDP to TCP in the latest software update.

														- Kevin
-----Original Message-----
From: DNSOP [mailto:[email-masked]] On Behalf Of Shane Kerr
Sent: Friday, October 16, 2015 4:21 PM
To: Joe Abley
Cc: dnsop WG
Subject: Re: [DNSOP] Closing out issues in draft-ietf-dnsop-resolver-priming

Joe,

On Fri, 16 Oct 2015 15:06:50 -0400
"Joe Abley" <[email-masked]> wrote:

> The successful attacks like this that I've seen rely upon being able 
> to trigger a particular query from a resolver so that you can bombard 
> it with responses in the hope of matching a query id. If there's no 
> viable trigger (unless you can exploit a software defect and trigger a 
> restart) the attack seems harder.
> 
> > While the chance of poisoning any one resolver with such a response 
> > is low, the impact is catastrophic to a non-validating resolver, as 
> > an attacker basically owns your view of the Internet at that point. 
> > For resolvers that do validate, the only issue is information 
> > leakage that a random party can see all of your root queries (or possibly a DoS).
> 

I think it depends on whether an attacker is interested in attacking a specific resolver or whether they are content to fish.

You can't trigger the query, but you know for certain the exact query that will be made 1x per day by almost every recursive resolver on the Internet. Given that there are reportedly 20 million *open* resolvers on the Internet, the chance of being able to exploit *some* resolver based on priming queries seems actually pretty good.
 
> >> We're talking principally about a risk to resolvers that prime but 
> >> don't validate, right?
> >

Good point. As I mentioned the risk to validating resolvers is just information leakage (or DoS). But both of those could be avoided by validating the priming query, so why not?

I really don't understand the phobia about enlarging priming responses.
It's practically another argument to use TCP for this so we don't have to worry. ;)

Cheers,

--
Shane

---

From: "Joe Abley" <[email-masked]>
Date: Fri, 16 Oct 2015 17:18:05 -0400

On 16 Oct 2015, at 16:36, Darcy Kevin (FCA) wrote:

> It would be wise to get a clear statement of preference from the 
> Internet root operators on this, but don't forget that whatever gets 
> defined in IETF standards, and implemented in leading DNS software 
> packages, also affects private enterprises too. Many of us run 
> internal roots and I, for one, don't want to see an influx of traffic 
> and/or spiky saturation of bandwidth, because priming suddenly morphed 
> from UDP to TCP in the latest software update.

Let's make sure we put this in perspective, though -- how often do your 
resolvers restart? If it's once per few months to apply a kernel patch, 
then we're talking about far less traffic than your printers, phones and 
laptops are spewing every second onto the network with mDNS (or ARP, 
even :-)

Real root servers deal with internet-scale numbers of resolvers. It 
seems unlikely you have that problem in your campus network.

Joe

---

From: "Darcy Kevin (FCA)" <[email-masked]>
Date: Fri, 16 Oct 2015 22:11:47 +0000

I agree, the priming volume for a private enterprise is on a much smaller scale than the public Internet. But, at the same time, a notable difference between priming and normal DNS traffic (or mDNS, or ARP, etc.) is that priming traffic is more likely to traverse WAN links (because, unlike the public Internet, the root-server pool is typically a fairly *centralized* subset of all the published nameservers in the enterprise, since root servers generally only live in datacenters or "major" sites). WAN bandwidth cost-efficiencies haven't kept pace with other areas of information technology. This can, of course, be optimized using techniques like authoritative-nameserver Anycast, but, to be honest, not all organizations have the technological wherewithal to implement that.

As for how much priming traffic... what if an organization wanted to implement full-service resolvers on all of its endpoints (e.g. to provide "end-to-end" DNSSEC coverage)? Endpoints reboot or restart *a*lot*. When you have tens of thousands, or hundreds of thousands of endpoints that could prime several times a day, and priming is TCP instead of UDP, that might make such an approach cost-prohibitive. IMO, the desire to achieve some artificial "parity" between transport protocols, for priming, shouldn't displace security-enhancing approaches like end-to-end DNSSEC, into the "economically infeasible" category.

I admit, I haven't worked out the economics of this down to the last penny. I'm still more of a technologist than a businesscritter. But I see a lot of potential downside in allowing TCP priming and, frankly, the arguments for it, seem to be rather fluffy (parity, really?)

										- Kevin

-----Original Message-----
From: Joe Abley [mailto:[email-masked]] 
Sent: Friday, October 16, 2015 5:18 PM
To: Darcy Kevin (FCA)
Cc: dnsop WG
Subject: Re: [DNSOP] Closing out issues in draft-ietf-dnsop-resolver-priming

> from UDP to TCP in the latest software update.

Let's make sure we put this in perspective, though -- how often do your resolvers restart? If it's once per few months to apply a kernel patch, then we're talking about far less traffic than your printers, phones and laptops are spewing every second onto the network with mDNS (or ARP, even :-)

Real root servers deal with internet-scale numbers of resolvers. It seems unlikely you have that problem in your campus network.

Joe

---

From: 神明達哉 <[email-masked]>
Date: Fri, 16 Oct 2015 18:34:40 -0700

At Fri, 16 Oct 2015 17:07:27 +0000,
"Darcy Kevin (FCA)" <[email-masked]> wrote:

> Let's see, millions of full-service resolvers, times the
> packet-count differential between UDP and TCP, times the average
> reload/restart frequency of those full-service resolvers per
> day/week/month. Can't a case be made from sheer volume?

I've not checked the validity of the math, but even if that's valid, I
believe a SHOULD is enough for such a purpose.  Sane implementations
would honor that, and insane implementations would do whatever they
want whether it's a SHOULD or MUST.

> > >     The priming query MUST be sent over UDP (section 6.1.3.2 of

My interpretation of this was that since the support for TCP was a
SHOULD in section 6.1.3.2 of RFC1123 trying TCP could result in an
interoperability problem (hence the MUST).  And what I tried to say is
that now that the support for TCP is a REQUIRED this MUST looks like a
'super-strong recommendation'.

--
JINMEI, Tatuya

---

From: Suzanne Woolf <[email-masked]>
Date: Sat, 17 Oct 2015 05:02:39 -0400

Joe,

Thanks for laying this out.

All,

Joe’s correct here. 2870bis obsoletes 2870, quite deliberately. (http://datatracker.ietf.org/doc/draft-iab-2870bis/ <http://datatracker.ietf.org/doc/draft-iab-2870bis/>, it’s not long.) And RSSAC 001 (https://www.icann.org/en/system/files/files/rssac-001-draft-02may13-en.pdf, which is marked “draft” because it’s waiting on 2870bis) discusses resource expectations and other operational requirements.

The scoping issue Joe points out wasn’t immediately obvious when I re-read resolver-priming after not looking at it for awhile, but times have changed since it was written; 2870bis came about partly because there are now places and mechanisms for ICANN and RSSAC to publish their own information about what ICANN and the root server operators actually do.

Can we refocus specifically on what the DNS protocol requires in priming queries and responses for them to serve the purpose, and where it might be silent or ambiguous? Assumptions about operational factors such as resource constraints need to be clearly separated from protocol-level analysis.

thanks
Suzanne

> On Oct 16, 2015, at 10:27 AM, Joe Abley <[email-masked]> wrote:
> 
> 
> 
> I think it might be worth stepping up a level here and understanding what this document can reasonably specify.
> 
> 2870 has long been recognised to be obsolete. The direction for fixing that (which, who knows, might actually result in action at some point) can be summarised as the union of draft-iab-2870bis (currently approved for BCP, sitting in the RFC Editor queue) and RSSAC-001 (currently waiting for 2870bis to be published).
> 
> The approach being taken is that the IETF provides protocol-level requirements, and RSSAC documents the operational expectations that are reasonable to have of root server operators.
> 
> Analogously, and relevant to this document, the contents of the root zone, the names of root servers, and the operational practicalities of the ROOT-SERVERS.NET zone (contents, and where it is hosted) are currently managed by the IANA Functions Operator under contract. RSSAC is currently working on analysis and advice to ICANN on the question of whether the current naming scheme could be improved upon.
> 
> This document, I believe, needs some revision to make sure it stays on the right side of the line between technical policy (from the IETF), administrative policy (from the IANA Functions Operator) and operational policy (from the root server operators, as documented by RSSAC).
> 
> So, for example:
> 
> I think this document needs to be clear that the requirements it is imposing on the system as a whole are protocol-level requirements, and not operational or administrative.
> 
> I am deliberately not suggesting edits to the current text or responding to the two issues you highlighted in this message; I think it's important to get consensus first about the scope of guidance that this document can provide.
> 
> To be clear, I think it's important and necessary that the priming process be documented; I just think we need to be careful that we do it from a protocol perspective.
> 
> 
> Joe
>