Subject: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt

From: Paul Hoffman <[email-masked]>
Date: Fri, 4 Jul 2014 13:50:03 -0700

Greetings. Warren and I have done a major revision on this draft, narrowing the design goals, and presenting more concrete proposals for how the mechanism would work. We welcome more feedback, and hope to discuss it in the WG in Toronto.

--Paul Hoffman

Begin forwarded message:

> From: [email-masked]
> Subject: I-D Action: draft-wkumari-dnsop-dist-root-01.txt
> Date: July 3, 2014 at 2:17:46 PM PDT
> To: [email-masked]
> Reply-To: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>        Title           : Securely Distributing the DNS Root
>        Authors         : Warren Kumari
>                          Paul Hoffman
> 	Filename        : draft-wkumari-dnsop-dist-root-01.txt
> 	Pages           : 9
> 	Date            : 2014-07-03
> 
> Abstract:
>   This document recommends that recursive DNS resolvers get copies of
>   the root zone, validate it using DNSSEC, populate their caches with
>   the information, and also give negative responses from the validated
>   zone.
> 
>   [[ Note: This document is largely a discussion starting point. ]]
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-dist-root/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-wkumari-dnsop-dist-root-01
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-wkumari-dnsop-dist-root-01

---

From: Joe Abley <[email-masked]>
Date: Sat, 5 Jul 2014 12:11:02 -0400

Hi Paul, Warren,

On 4 July 2014 at 16:50:08, Paul Hoffman ([email-masked]) wrote:

> Greetings. Warren and I have done a major revision on this draft, narrowing the design  
> goals, and presenting more concrete proposals for how the mechanism would work. We welcome  
> more feedback, and hope to discuss it in the WG in Toronto.

I think there is much in the language of this draft that could be tightened up, but this is an idea for discussion so I'll avoid a pedantic line-by-line dissection. But I can give you the full pedantry if you like :-)

On the pros and cons, however (crudely pasted below), see below.

TL;DR: there are way more cons than pros to this proposal. The pros listed are weak; the cons listed are serious. I don't see a net advantage to the DNS (or to perceived performance of the DNS for any client) here. This proposal, if implemented, would represent non-trivial additional complexity with minimal or no benefit. I am not in favour of it, if that's not obvious.

As noted previously, I am not against documenting and discussing the merits of slaving the root zone on resolvers (in some fashion). My preference would be for a draft called something like "draft-ietf-dnsop-slaving-root-on-resolvers-harmful", which could borrow much of your section 5.1 and 5.2 to make its argument.

I remain very much *not* in favour of making changes to the DNS specification that don't have a clear benefit to balance their costs.

---

5.1.  Pros

   o  Junk queries / negative caching - Currently, a significant number
      of queries to the root servers are "junk" queries.  Many of these
      queries are TLDs that do not (and may never) exist in the root
      Another significant source of junk is queries where the negative
      TLD answer did not get cached because the queries are for second-
      level domains (a negative cache entry for "foo.example" will not
      cover a subsequent query for "bar.example").

I think a better way to accommodate the second point is to implement qname minimisation in recursive server logic.

I don't know that the first point is much of a pro. Root server operators need to provision significant spare capacity in order to accommodate flash crowds and attack traffic, and compared to that spare capacity the volume of junk queries is extremely small. There's no obvious operational benefit to root server operators in reducing their steady-state query load (in fact, it would make it harder in some cases to obtain the exchange point capacity you need to accommodate flash crowds, on exchanges where higher-capacity ports are reserved for those that have demonstrable need based on steady-state traffic.)

I'm also a little concerned about the word "junk". It's a pejorative term that implies assumptions about the intent of the original query. If my intent is to confirm that a top-level label doesn't exist, then "BLAH/IN/SOA" is a perfectly reasonable query for me to send to a root server. We might assume that a query "Joe's iPhone/IN/SOA" sent to a root server is not reasonable, but we're only assuming; we don't actually have a way of gauging the actual intent with any accuracy.

   o  DoS against the root service - By distributing the contents of the
      root to many recursive resolvers, the DoS protection for customers
      of the root servers is significantly increased.  A DDoS may still
      be able to take down some recursive servers, but there is much
      more root service infrastructure to attack in order to be
      effective.  Of course, there is still a zone distribution system
      that could be attacked (but it would need to be kept down for a
      much longer time to cause significant damage, and so far the root
      has stood up just fine to DDoS.

If I was to paraphrase this advantage with malicious intent :-), you mean that "we don't have to rely upon the root server system to continue to perform under attack, because we don't need the root server system any more, although we do need the new bits of the root server system we are specifying, and if those bits are not available we do need the conventional root server system after all, but that's probably ok because the root server system is pretty resilient". That sounds a bit circular.

   o  Small increase to privacy of requests - This also removes a place
      where attackers could collect information.  Although query name
      minimization also achieves some of this, it does still leak the
      TLDs that people behind a resolver are querying for, which may in
      itself be a concern (for example someone in a homophobic country
      who is querying for a name in .gay).

There's an implication here that a recursive resolver sending a query to a root server is potentially impinging upon the privacy of its anonymous clients. I find that a bit difficult to swallow.

I'm surprised not to see "improves performance for clients" in this list, on the general principle that every cache miss that triggers a query to a root server will take longer than consulting a pre-fetched root zone. I'm glad about that, though, since I think that performance improvement is (a) minuscule in normal operation, affecting 1/BIGNUM clients who expose a cache miss and (b) also achievable in the steady state by resolvers that perform cache pre-fetching (e.g. hammer-like behaviour).

My overall summary for 5.1 is that there's no clear benefit in performance, reliability or stability from making this change.

5.2.  Cons

   o  Loss of agility in making root zone changes - Currently, if there
      is an error in the root zone (or someone needs to make an
      emergency change), a new root zone can be created, and the root
      server operators can be notified and start serving the new zone
      quickly.  Of course, this does not invalidate the bad information
      in (long TTL) cached answers.  Notifying every recursive resolver
      is not feasible.  Currently, an "oops" in the root zone will be
      cached for the TTL of the record by some percentage of servers.
      Using the technique described above, the information may be cached
      (by the same percentage of servers) for the refresh time + the TTL
      of the record

A new root zone is published usually two (but sometimes more) times per day. The semantics specified in the draft for refreshing a local copy of the root zone say "keep re-using the copy you have until it expires". If I assume that "expire" means "survives beyond SOA.EXPIRE seconds of when we originally fetched it", then there's the potential for stale data to be published for a week plus however old the originally-retrieved file was (which is difficult to determine, in contrast to the traditional root zone distribution scheme). I think this disadvantage is more serious than is presented.

   o  No central monitoring point - DNS operators lose the ability to
      monitor the root system.  While there is work underway to
      implement better instrumentation of the root server system, this
      (potentially) removes the thing to monitor.

In fact there's exactly the same ability to monitor the root server system; it's just that the data available through such monitoring will be different (as you point out in the second sentence). OK, this one is a bit pedantic.

   o  Increased complexity in nameserver software and their operations -
      Any proposal for recursive servers to copy and serve the root
      inherently means more code to write and execute.  Note that many
      recursive resolvers are on inexpensive home routers that are
      rarely (if ever) updated.

You don't require universal deployment for this scheme to work, so the long tail of DNS software upgrades is arguably not  great concern. I think the increased complexity in operations is significant, though. My observation is that people already have enough difficulty troubleshooting DNS problems, and adding in a brand new set of services for root zone distribution that also need to be considered (potentially a set of services that are not subject to the same internal and external scrutiny of root server operations, and which are potentially operated by people that are even less familiar and easy to reach than root server operators are) is only going to make things worse.

If there was a significant benefit to performance or reliability to balance that increased operational complexity, I might see a reason to do it. I don't see that benefit, though.

   o  Changes the nature and distribution of traffic hitting the root
      servers - If all the "good" recursive resolvers deploy root
      copying, then root servers end up servicing only "bad" recursive
      resolvers and attack traffic.  The roots (could) become what AS112
      is for RFC1918.

The difference is that queries directed at AS112 servers are definitively junk. They are requests for names that cannot exist with global uniqueness, since they correspond to infratructure that is not globally unique. By contrast, the root servers will always receive queries that are important to answer (from an end-user's perspective), even if the proportion of such queries declines following the unexpected and optimistic changes in resolver behaviour implied in that paragraph.

Architecturally, I don't think you improve the quality of a service by reducing the impact of failure and giving the operators busy-work to fill their time.

Joe

---

From: Paul Vixie <[email-masked]>
Date: Sat, 05 Jul 2014 09:27:21 -0700

Joe Abley wrote:
> ...

i am +1 to joe's comments above and analysis elided. i consider joe's
response to be at least as good as the "because" i owe DRC after my
first short answer to the -00 version of this draft. however, i want to
add two other countervailing points.

first, this approach was tried in freebsd, when doug barton (then
freebsd's BIND9 maintainer) made it the default. all hell broke loose
due to changes in firewall config. debugging cost was maximized, and the
debugging skills were minimized. this config was removed with prejudice.
this experience, where freebsd users are actually among the smartest of
all dns users, should serve as a warning sign to others: "abandon hope
all ye who enter here." so, joe's recommendation that this draft be
retitled and rekerned to be
"draft-ietf-dnsop-slaving-root-on-resolvers-harmful" resonates very
strongly with me.

second, this approach asks millions or tens of millions of rdns servers
to change their config in order to actually scale the capacity of the
root. (so, high cost and low benefit, as joe said.) the reason i
proposed a radically different solution in my ICANN ITI contribution
(now described at
http://tools.ietf.org/html/draft-lee-dnsop-scalingroot-00) is to allow a
few dozen to a few hundred self selected highly skilled and motivated
network-level admins to scale the capacity of the root for everyone.
it's a plain hierarchical solution allowing the operators of any
loopback network on any host, or any LAN segment, or any campus,
corporate, or ISP network to add root name service as a local
capability; it also allows unlimited scale at the global BGP layer. it
is patterned after the success of AS112. it is apolitical since existing
rootops are also expected to participate.

vixie

---

From: Ralf Weber <[email-masked]>
Date: Mon, 7 Jul 2014 00:52:40 +0200

Moin!

> As noted previously, I am not against documenting and discussing the merits of slaving the root zone on resolvers (in some fashion). My preference would be for a draft called something like "draft-…
Oh like draft-ietf-dnsop-reflectors-are-evil that became RFC5358, but still hasn't stopped Google and others offering open resolving service to the internet. Granted there are a lot of open DNS proxies out there that should be taken down, but I assume there are some companies offering resolving services that are valuable to Internet users.

> I remain very much *not* in favour of making changes to the DNS specification that don't have a clear benefit to balance their costs.
I think there is a difference between the precise specification and what you can do with your DNS software. While it may not be within the spec you can setup an auth server today that slaves the root zone and use a stub on your resolver to point to that root zone. That's how I run my setup at home because I don't want to my queries to be part of the DITL collection and I know that others do that because they have very bad connectivity to the root servers and in general. 

I think if we think of the resolver having another auth root server at localhost the logic is easier to understand makes much more sense as DNSSEC protections would kick in even if someone managed to inject a bad zone. 

The draft doesn't require every resolver to slave the zone, but merly is an information that this is a possible way to do it and I assume that large resolver operators would benefit from it and the CPEs you mention that even haven't implemented EDNS0 wouldn't matter anyway.

It in the end of course comes down to do we want to document what is out there  anyway or do we want to hide our heads in the sand. Especially for an operational group I would prefer the former.

So long
-Ralf

---

From: Mark Andrews <[email-masked]>
Date: Mon, 07 Jul 2014 10:40:20 +1000

In message <[email-masked]>, Joe Abley writes
:
> I think there is much in the language of this draft that could be 
> tightened up, but this is an idea for discussion so I'll avoid a pedantic 
> line-by-line dissection. But I can give you the full pedantry if you like 
> :-)
> 
> TL;DR: there are way more cons than pros to this proposal. The pros 
> listed are weak; the cons listed are serious. I don't see a net advantage 
> to the DNS (or to perceived performance of the DNS for any client) here. 
> This proposal, if implemented, would represent non-trivial additional 
> complexity with minimal or no benefit. I am not in favour of it, if 
> that's not obvious.
> 
> As noted previously, I am not against documenting and discussing the 
> merits of slaving the root zone on resolvers (in some fashion). My 
> preference would be for a draft called something like 
> "draft-ietf-dnsop-slaving-root-on-resolvers-harmful", which could borrow 
> much of your section 5.1 and 5.2 to make its argument.
> 
> I remain very much *not* in favour of making changes to the DNS 
> specification that don't have a clear benefit to balance their costs.
> 
> ---
> 
> 5.1. Pros
> 
> I think a better way to accommodate the second point is to implement 
> qname minimisation in recursive server logic.

When you can get rid of all the servers in the world which followed
RFC 2535 which return NXDOMAIN for empty non terminal qname
minimisation and this sort of logic will be viable though it won't
do anywhere as near as good a job as having a local copy of the
root zone.

> I don't know that the first point is much of a pro. Root server operators 
> need to provision significant spare capacity in order to accommodate 
> flash crowds and attack traffic, and compared to that spare capacity the 
> volume of junk queries is extremely small. There's no obvious operational 
> benefit to root server operators in reducing their steady-state query 
> load (in fact, it would make it harder in some cases to obtain the 
> exchange point capacity you need to accommodate flash crowds, on 
> exchanges where higher-capacity ports are reserved for those that have 
> demonstrable need based on steady-state traffic.)

But there is big benefit to cache operators.  The bigger the client base
the bigger the benefit.
 
> I'm also a little concerned about the word "junk". It's a pejorative term 
> that implies assumptions about the intent of the original query. If my 
> intent is to confirm that a top-level label doesn't exist, then 
> "BLAH/IN/SOA" is a perfectly reasonable query for me to send to a root 
> server. We might assume that a query "Joe's iPhone/IN/SOA" sent to a root 
> server is not reasonable, but we're only assuming; we don't actually have 
> a way of gauging the actual intent with any accuracy.
> 
> If I was to paraphrase this advantage with malicious intent :-), you mean 
> that "we don't have to rely upon the root server system to continue to 
> perform under attack, because we don't need the root server system any 
> more, although we do need the new bits of the root server system we are 
> specifying, and if those bits are not available we do need the 
> conventional root server system after all, but that's probably ok because 
> the root server system is pretty resilient". That sounds a bit circular.
> 
> There's an implication here that a recursive resolver sending a query to 
> a root server is potentially impinging upon the privacy of its anonymous 
> clients. I find that a bit difficult to swallow.

Given the intelligence that root server operators have glenned in the past
there is a degree of credability here.

> I'm surprised not to see "improves performance for clients" in this list, 
> on the general principle that every cache miss that triggers a query to a 
> root server will take longer than consulting a pre-fetched root zone. I'm 
> glad about that, though, since I think that performance improvement is 
> (a) minuscule in normal operation, affecting 1/BIGNUM clients who expose 
> a cache miss and (b) also achievable in the steady state by resolvers 
> that perform cache pre-fetching (e.g. hammer-like behaviour).
> 
> My overall summary for 5.1 is that there's no clear benefit in 
> performance, reliability or stability from making this change.
> 
> 5.2. Cons
> 
> A new root zone is published usually two (but sometimes more) times per 
> day. The semantics specified in the draft for refreshing a local copy of 
> the root zone say "keep re-using the copy you have until it expires". If 
> I assume that "expire" means "survives beyond SOA.EXPIRE seconds of when 
> we originally fetched it", then there's the potential for stale data to 
> be published for a week plus however old the originally-retrieved file 
> was (which is difficult to determine, in contrast to the traditional root 
> zone distribution scheme). I think this disadvantage is more serious than 
> is presented.

Slaves perform refresh queries every 30 minutes (refresh = 1800).
Oops actually clear up faster with slaves than without as many of
the responses are now direct to stub rather than cached responses
which have much higher TTLs.

If one was really worried one could keep a log of the last 24 hours
of zone tranfers and issue a NOTIFY to all of the sources that
transfered the zone.  Normal refresh logic would then kick in for
a large percentage of slaves.  This is permitted by the RFC's.
Machines are actually good at doing this sort of thing.

This is actually a pro not a con.

> In fact there's exactly the same ability to monitor the root server 
> system; it's just that the data available through such monitoring will be 
> different (as you point out in the second sentence). OK, this one is a 
> bit pedantic.
> 
> You don't require universal deployment for this scheme to work, so the 
> long tail of DNS software upgrades is arguably not great concern. I think 
> the increased complexity in operations is significant, though. My 
> observation is that people already have enough difficulty troubleshooting 
> DNS problems, and adding in a brand new set of services for root zone 
> distribution that also need to be considered (potentially a set of 
> services that are not subject to the same internal and external scrutiny 
> of root server operations, and which are potentially operated by people 
> that are even less familiar and easy to reach than root server operators 
> are) is only going to make things worse.

In the 10+ years I have been slaving the root zone I have not once needed
to trouble shoot it.  Trouble shooting a slaving the root is no different
to trouble shooting any other slave zone.

I call this one FUD.
 
> If there was a significant benefit to performance or reliability to 
> balance that increased operational complexity, I might see a reason to do 
> it. I don't see that benefit, though.
> 
> The difference is that queries directed at AS112 servers are definitively 
> junk. They are requests for names that cannot exist with global 
> uniqueness, since they correspond to infratructure that is not globally 
> unique. By contrast, the root servers will always receive queries that 
> are important to answer (from an end-user's perspective), even if the 
> proportion of such queries declines following the unexpected and 
> optimistic changes in resolver behaviour implied in that paragraph.
> 
> Architecturally, I don't think you improve the quality of a service by 
> reducing the impact of failure and giving the operators busy-work to fill 
> their time.

Root servers end up servicing mostly SOA/IXFR queries from updated
recursive servers.  46 of these a day which say "up-to-date" along
with 2 "IXFR/AXFR" responses which actually transfer zone content
which fall into a 30 minute window after each zone update. 

They also deal with all the legacy recursive server traffic.  This
traffic as exactly the same ratio of "junk" queries as today's
traffic does.

Changing the traffic patterns at the root is neutral.  It is neither
good nor bad.

> Joe
> 
> 
> _______________________________________________
> 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: Paul Vixie <[email-masked]>
Date: Sun, 06 Jul 2014 21:14:16 -0700

i am not joe, but i strongly +1'd his response on this thread, so i'm
putting my oar back into the water now.

Mark Andrews wrote:
> In message <[email-masked]>, Joe Abley writes:
>>
>> 5.1. Pros
>>
> minimisation and this sort of logic will be viable

query minimization is very much worth having for its own sake. RFC 2535
style authorities were never numerous. we can cope.

>  though it won't

there are far more errors encountered below .com or .de than by their
siblings in the root. any argument in favour of wide scale slaving of
the root zone begs the question, why not every tld and every pseudo-tld
(such as no-ip.org)? the root isn't special in regards to a goal of
preventing junk queries. that's why query minimization is the preferred
solution to this problem.

> there is a degree of credability here.

if it were possible to put in place agreements between the root name
server operators and the internet community, one of the things i'd ask
for is a "no data mining" rule. that is, i would want to be sure that
verisign's security business was in no way commercially advantaged by
its exclusive access to the a/j root query stream (or the .com query
stream). alas, that's the third rail of internet politics, and i have no
wish to place a moist body part up against it.

to your actual point, query minimization is the solution to data leaks
into root, and tld, and pseudo-tld authorities. slaving the root zone
only solves this problem for the root name server operators, who are
nowhere near our full problem statement with regard to long-qname
surveillance.

> This is actually a pro not a con.

right now, root name servers are part of an explicit, hand-maintained
NOTIFY tree. thus, all internet actions depending on root zone content
have up-to-the-minute data if not up-to-the-second data in many cases.
we should treat this as an invariant, which means any IETF
recommendation for root zone slave service should include an explicit
NOTIFY tree, though i doubt it can be either "hand maintained" as the
current one is nor "remember everybody who has fetched it and NOTIFY all
of them" as you suggest. (since many RDNS servers are behind firewalls
or NAT or both, it's fair to say that most could never hear a NOTIFY.)

i like the cost and complexity and likely error rate of an explicit
NOTIFY tree involving a few thousand anycast slaves each operated by
someone who knows the technology and is aware of their role in the
system, far more than i like the cost and complexity and likely error
rate of an explicit NOTIFY tree involving tens of millions of RDNS
systems mostly operated by people who do not understand the issues and
have no idea what their role in the system is.

thus my preference for the root server anycast proposal first described
in 2005 at

    https://ss.vix.su/~vixie/alternate-rootism.pdf

and then described again this year for the ICANN ITI panel report (see
section 9.4) at

    https://www.icann.org/en/system/files/files/report-21feb14-en.pdf

and then described again this week for the IETF DNSOP wg at

    https://tools.ietf.org/id/draft-lee-dnsop-scalingroot-00.txt

briefly, it means recommending hierarchical anycast root service be
deployed on loopback networks, LANs, campus networks, ISP's, and
globally, by anyone with motivation and capacity, including the existing
root name server operators. a small number (a few hundred or a few
thousand) such root anycast operators would have global impact on root
zone content reachability.

> to trouble shooting any other slave zone.

mark, you have in the last ten years debugged somebody else's DNSSEC
configuration error with two or three "dig" commands that i would never
have thought of and could not have interpreted as you did. and i used to
be smart. therefore any statement of the form "mark andrews finds this
easy and has never had a problem with it" is to me neither indicative
nor dispositive.

vixie

---

From: Mark Andrews <[email-masked]>
Date: Mon, 07 Jul 2014 15:26:02 +1000

> style authorities were never numerous. we can cope.

Even with query minimization you will still gets lots of junk queries
to the roots.

> solution to this problem.

The root scales at present.

> nowhere near our full problem statement with regard to long-qname

query minimization only addresses part of the issue, usually that
of having .corp in a search list (or similar) when not talking to
a recursive server with a .corp configured.  It does not address
the issue of stub resolvers appending "." to single labels when
searching.

> or NAT or both, it's fair to say that most could never hear a NOTIFY.)

Today if the root gets stuffed content it takes 2 days to clear
from the system.  With slave copies of the root only using SOA
timers it would take 30 minutes to clear to bad data.  By the time
you get around to publishing a "flush your cache" notice and having
even a small percentage know with current procedures the bad data
is gone with slaves.

> easy and has never had a problem with it" is to me neither indicative

The key words was "not once needed to trouble shoot".

> vixie
> 
> --------------060203040002090505050401
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> 
> <html><head>
> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
> </head><body bgcolor="#FFFFFF" text="#000000">i am not joe, but i 
> strongly +1'd his response on this thread, so i'm putting my oar back 
> into the water now.<br>
> <br>
> Mark Andrews wrote:
> <blockquote cite="mid:[email-masked]" 
> type="cite">
>   <pre wrap="">In message <a class="moz-txt-link-rfc2396E" href="mailto:etPan
> [email-masked]">&lt;etPan.53b82396.4353d0cd.38df@
> walrus.hopcount.ca&gt;</a>, Joe Abley writes:
> </pre>
>   <blockquote type="cite"><pre wrap="">
> 
> 5.1. Pros
> 
> </pre></blockquote>
>   <pre wrap=""><!---->
> minimisation and this sort of logic will be viable</pre>
> </blockquote>
> <br>
> <span>query minimization is very much worth having for its own sake. RFC
>  2535 style authorities were never numerous. we can cope.<br>
>   <br>
> </span>
> <blockquote cite="mid:[email-masked]" 
> type="cite">
>   <pre wrap=""> though it won't
> root zone.</pre>
> </blockquote>
> <br>
> solution to this problem.<br>
> <br>
> <blockquote cite="mid:[email-masked]" 
> type="cite">
>   <pre wrap="">
> ...
> 
> <blockquote type="cite"><span><pre wrap="">There's an implication here that a
>  recursive resolver sending a query to 
> clients. I find that a bit difficult to swallow.</pre></span></blockquote>
> </pre>
>   <pre wrap=""><!---->Given the intelligence that root server operators have 
> glenned in the past
> there is a degree of credability here.</pre>
> </blockquote>
> <br>
>  wish to place a moist body part up against it.<br>
> <br>
> surveillance.<br>
> <br>
> <blockquote cite="mid:[email-masked]" 
> type="cite">
>   <pre wrap="">
> 
> 
> <blockquote type="cite"><span><pre wrap="">A new root zone is published usual
> ly two (but sometimes more) times per 
> is presented.</pre></span></blockquote>
> </pre>
>   <pre wrap=""><!---->
> This is actually a pro not a con.</pre>
> </blockquote>
> <br>
> or NAT or both, it's fair to say that most could never hear a NOTIFY.)<br>
> <br>
> have no idea what their role in the system is.<br>
> <br>
> in 2005 at<br>
> <br>
> &nbsp;&nbsp;&nbsp; <a class="moz-txt-link-freetext" href="https://ss.vix.su/~
> vixie/alternate-rootism.pdf">https://ss.vix.su/~vixie/alternate-rootism.pdf</
> a><br>
> <br>
> section 9.4) at<br>
> <br>
> &nbsp;&nbsp;&nbsp; <a class="moz-txt-link-freetext" href="https://www.icann.o
> rg/en/system/files/files/report-21feb14-en.pdf">https://www.icann.org/en/syst
> em/files/files/report-21feb14-en.pdf</a><br>
> <br>
> and then described again this week for the IETF DNSOP wg at<br>
> <br>
> &nbsp;&nbsp;&nbsp; <a class="moz-txt-link-freetext" href="https://tools.ietf.
> org/id/draft-lee-dnsop-scalingroot-00.txt">https://tools.ietf.org/id/draft-le
> e-dnsop-scalingroot-00.txt</a><br>
> <br>
> zone content reachability.<br>
> <br>
> <blockquote cite="mid:[email-masked]" 
> type="cite">
>   <pre wrap="">
> 
> to trouble shooting any other slave zone.</pre>
> </blockquote>
> <br>
> nor dispositive.<br>
> <br>
> vixie<br>
> <blockquote cite="mid:[email-masked]" 
> type="cite">
> 
> </blockquote>
> </body></html>
> 
> --------------060203040002090505050401--
> 
> 
> --===============1618732303828035307==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============1618732303828035307==--
>

---

From: Terry Manderson <[email-masked]>
Date: Sun, 6 Jul 2014 22:41:42 -0700

Hi Paul,

No oars - just a bit of a broken paddle.

On 7/07/2014 2:14 pm, "Paul Vixie" <[email-masked]> wrote:

>have up-to-the-minute data if not up-to-the-second data in many cases. we
>should treat this as an invariant, which means
> any IETF recommendation for root zone slave service should include an
>explicit NOTIFY tree, though i doubt it can be either "hand maintained"
>as the current one is nor "remember everybody who has fetched it and
>NOTIFY all of them" as you suggest. (since many
> RDNS servers are behind firewalls or NAT or both, it's fair to say that
>most could never hear a NOTIFY.)

Terry thinking aloud: it might be palatable to have a automated
registration process where a 'root zone enabled resolver' registers with a
'zone distribution service' and issue a keep-alive, such that the ZDS
might be able to issue a notify (of sorts) to the resolver..

But getting ahead of myself, the underlying issue of zone freshness (as
I've mentioned before) is my break-point. And the environment we have now
simply doesn't help that, inclusive of NAT effects.

><https://ss.vix.su/~vixie/alternate-rootism.pdf>

(btw this needs to be http, https asks for auth!)

><https://www.icann.org/en/system/files/files/report-21feb14-en.pdf>
>
><https://tools.ietf.org/id/draft-lee-dnsop-scalingroot-00.txt>

I'm not going to make statements of the above on technical feasibility,
but I am more than concerned about: (sec 3.) The proposed architecture is
strongly based on the widely deployed DNSSEC.  .. not that is based on
DNSSEC, the premise of 'widely', and that serves as a unilateral go signal.

I would suggest that timing might well be the impeding factor here. I
still see some 6-10K queries/per sec (diurnal pattern) on L-root without
the DO bit set. That isn't insignificant as L is only 1 of the 13. So
while 'widely deployed' could be argued (23K-31K qps with DO bit) I think
'near pervasive' is the buy-in point. I might well be with you if the
omission of the DO bit was at similar or lower levels as the v6 query rate
- 2k qps, non-dirurnal. ;)

Or maybe the new service addressees in scalingroot-00 MUST only answer to
DNSSEC queries..but that is a stretch IMHO.

Cheers
Terry

---

From: David Conrad <[email-masked]>
Date: Mon, 7 Jul 2014 12:27:36 -0700

Joe,

I was in the middle of a long, extremely eloquent point-by-point rebuttal when I realized it was pointless: we're approaching the draft from completely different directions and I strongly doubt anything I might say might change your mind. 

However, I did want to focus on one point.  To quote a bit of your message:

> There's no obvious operational benefit to root server operators [...]

I do not believe the draft is about improving life for the root server operators. That might be a side benefit in that it would reduce the noise root server operators have to wade through, but it isn't the primary goal. I see the primary benefit being a way of addressing what I consider a fundamental flaw in the historical DNS operational architecture. Specifically, the DNS operational infrastructure is a bit like 6to4: it relies on the kindness of strangers who may or may not have any incentive to ensure the service is provided in the best possible way. 

This draft attempts to document a way in which organizations can choose to be the masters of their own fate when it comes to root name service instead of relying on a set of 12 (or 11, depending on your point of view) volunteers who upgrade or not, buy capacity or not, deploy IPv6 or not, deploy anycast or not, etc., based on their own internal rationales and justifications.  Further, it is opt-in: if you're perfectly happy with the existing system, no one is forcing you, as a resolver operator, to slave the root zone.

In my mind, this is a much more scalable, resilient, robust, and even rational (from the perspective of the operation of critical infrastructure) system that the current root service architecture.

Regards,
-drc

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 7 Jul 2014 15:44:56 -0400

Hi,

On Mon, Jul 07, 2014 at 12:27:36PM -0700, David Conrad wrote:
> 
> This draft attempts to document a way in which organizations can
> choose to be the masters of their own fate when it comes to root
> name service instead of relying on a set of 12 (or 11, depending on
> your point of view) volunteers who upgrade or not, buy capacity or
> not, deploy IPv6 or not, deploy anycast or not, etc., based on their
> own internal rationales and justifications.  Further, it is opt-in:
> if you're perfectly happy with the existing system, no one is
> forcing you, as a resolver operator, to slave the root zone.
> 
> In my mind, this is a much more scalable, resilient, robust, and
> even rational (from the perspective of the operation of critical
> infrastructure) system that the current root service architecture.

Perhaps.  I haven't myself made up my mind about this draft, partly
because I think the situation is somewhat more complicated than you
suggest above.  It's true that the draft sort of allows an operator to
be master of its own fate.  But it does require -- and indeed, the
coherence (however loose) of the DNS requires -- that one fall back to
asking a "real" root server in the event one isn't up to date.

Now, the problem is that the root server operations are organized
according to the work needed.  That is, many of the server operators
seem to do a pretty good job of ensuring capacity for their actual
loads.  If the proposals in this draft are widely adopted, that will
by definition change the profile of the traffic the root servers see,
and that will mean that such potential traffic will not be considered
in the planning by root server operators.  This may not be a fatal
flaw (probably it isn't), but it does worry me a little.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: David Conrad <[email-masked]>
Date: Mon, 7 Jul 2014 12:47:03 -0700

Paul,

On Jul 6, 2014, at 9:14 PM, Paul Vixie <[email-masked]> wrote:
> there are far more errors encountered below .com or .de than by their siblings in the root. any argument in favour of wide scale slaving of the root zone begs the question, why not every tld and every pseudo-tld (such as no-ip.org)? the root isn't special in regards to a goal of preventing junk queries.

The operators of the authorities for .com and .de and others have a natural incentive to augment their systems to deal with issues such as errors or DDoS or whatever.  As we have seen multiple times in the past, most individual root operators simply do not have this incentive. 

> that's why query minimization is the preferred solution to this problem.

This isn't either/or.

> right now, root name servers are part of an explicit, hand-maintained NOTIFY tree. thus, all internet actions depending on root zone content have up-to-the-minute data if not up-to-the-second data in many cases. we should treat this as an invariant,

I'm a bit (ok, a lot) skeptical of this claim, particularly given arguments made by some root server operators during the ICANN root scaling discussions about having instances at the end of long, thin, and fragile pipes and thus the size of the root zone must be limited.

However, ignoring that, one key point of slaving the root is that folks who do slave the root are accepting the responsibility to keep it up to date.  Failure to do so only impacts their own customer base. This is a self-correcting problem -- get too stale and your (presumably paying) customer scream at you (cue Vijay Gill's talk on the cost of customer calls in relation to the profit that customer will bring over their lifetime of being a customer).  As a customer, you can also always choose to run your own resolver (which is, of course, the right answer for other reasons).

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Mon, 7 Jul 2014 15:03:55 -0700

Andrew,

On Jul 7, 2014, at 12:44 PM, Andrew Sullivan <[email-masked]> wrote:
> It's true that the draft sort of allows an operator to

If you're defining a "real" root server to include the "zone delivery servers", I'd agree, however I feel the "zone delivery servers" have sufficiently different performance requirements as to put them in a different class than the name servers that respond to non-XFR queries.

> according to the work needed.[...] If the proposals in this draft are widely adopted, that will

Joe has already indicated that the normal query flow is essentially inconsequential in relation to capacity planning for the root server operators since they have to build based on DDoS/flash crowd loads, not on steady state.

Regards,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Mon, 07 Jul 2014 16:36:38 -0700

>> that's why query minimization is the preferred solution to this problem.

are you proposing to solve problem A (junk queries at the root) and
problem B (junk queries at tld's and pseudo-tld's) using different
mechanisms? why is the cost of a second mechanism worth paying, if a
single mechanism would solve both problems?

granted, we can solve any given problem in any number of ways including
one, or more than one. but what's our incentive to pay more than we have to?

> ... one key point of slaving the root is that folks who do slave the root are accepting the responsibility to keep it up to date.  Failure to do so only impacts their own customer base. This is a self-correcting problem -- get too stale and your (presumably paying) customer scream at you ...

my experience has been that when dns doesn't work the call reporting
this can go just about anywhere. if i could be sure that the first call
from most users would go to the actual person who had the power to fix
whatever caused the call, i'd certainly make that a primary design
assumption.

put it the other way. as a domain holder, i'd like the system
recommended by IETF whereby my delegation data is distributed to be as
error-unlikely as possible. if you give me a vote, wearing my domain
holder hat, i will pick "please tell the small number of people who want
to run root anycast nodes to do so" rather than "please tell the large
number of RDNS operators to slave the root". this is me wanting,
selfishly, uptime and a low number of dependencies and
state-permutations. but i consider myself to be representative of other
domain holders in this regard, so it could be worth paying attention to
my selfish desires this time.

vixie

---

From: David Conrad <[email-masked]>
Date: Mon, 7 Jul 2014 17:55:36 -0700

On Jul 7, 2014, at 4:36 PM, Paul Vixie <[email-masked]> wrote:
> are you proposing to solve problem A (junk queries at the root) and problem B (junk queries at tld's and pseudo-tld's) using different mechanisms? why is the cost of a second mechanism worth paying, if a single mechanism would solve both problems?

Query minimization and slaving the root focus on solving different problems. For example, query minimization does nothing to reduce systemic vulnerability to DoS.  Both should probably be done. 

> put it the other way. as a domain holder, i'd like the system recommended by IETF whereby my delegation data is distributed to be as error-unlikely as possible.

As a user of the Internet, I'd like the system recommended by the IETF to scale in the face of ISPs being unable to address DoS in any effective way.  The root of the DNS, concentrated in the hands of 24 (still not 26, sigh) IP addresses, is and always has been non-scalable -- we just didn't have a zillion botnet zombies rubbing our noses in it. Worse the existing system relies on the goodwill and potentially unbounded donation of resources from folks who aren't paid to provide the service. When you, I, and the Internet were younger, this (arguably) made sense but the Internet has changed (not to mention you and I). Slaving the root means the folks who are getting paid to provide domain resolution service to their customers are no longer dependent on the kindness of strangers, the single point of failure represented by the real-time query response requirement of root servers can be avoided, latency is reduced for queries for non-existant names, and information leakage can be minimized.

The main argument against slaving the root I've seen appears to me to be FUD: "people running resolvers are too stupid to configure slaving the root correctly so root data will go stale!" (paraphrased).  I've no doubt some folks will get it wrong, however again, this is a self-correcting problem that impacts a fraction of the Internet at large. If nothing else, repeated failure of a resolver operator to fix their slave configuration will result either in migration to folks who can get it right or people running their own resolvers.  Seems like a win to me.

Regards,
-drc

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 8 Jul 2014 07:02:02 +0200

On 8 jul 2014, at 02:55, David Conrad <[email-masked]> wrote:

> The main argument against slaving the root I've seen appears to me to be FUD: "people running resolvers are too stupid to configure slaving the root correctly so root data will go stale!" (paraphrased).

I am a bit disappointed that you David do summarize the arguments against this proposal in this way. Several various weaknesses of the proposal have been explained at several occasions (although of course also them with a bit of hand waving), and they are definitely not "fud" and definitely not limited to people making mistakes.

What I have recommended Warren to do is to properly list the arguments, make a proper analysis (an attack tree would be one good start) because my largest fear is that the various issues that might look like weaknesses of the proposal must be analyzed, and that they are not.

I have at least heard:

- Recovery process when bad data end up in the resolver (cache v.s. auth)

- Routing issues (which is what I see the largest burden of a root server operator)

- Lack of DNSSEC validation

- The fact not all data in the root zone is signed

- Political/regulative implications (to ensure a different TA is used than ICANN)

- Lack of legal protection of the root zone itself

...and possibly more.

...and of course a combination of these.

Once again, this is such a large issue that I would prefer a bit better arguments than what is demonstrated here.

Yes, I know you wrote in affection, but let this remind all of us that we can do better.

Ok?

    Patrik

---

From: David Conrad <[email-masked]>
Date: Mon, 7 Jul 2014 23:22:35 -0700

Patrik,

On Jul 7, 2014, at 10:02 PM, Patrik Fältström <[email-masked]> wrote:
> I am a bit disappointed that you David do summarize the arguments against this proposal in this way.

Sorry to disappoint you by stating how the main arguments against the draft appear to me.

> What I have recommended Warren to do is to properly list the arguments, make a proper analysis (an attack tree would be one good start) because my largest fear is that the various issues that might…

I'm sure Warren will do an outstanding job if he chooses to obey your recommendation.

> - Lack of legal protection of the root zone itself

Do you believe the current system addresses these concerns? If so, how?

> - Recovery process when bad data end up in the resolver (cache v.s. auth)

As I've pointed out, if bad data is being served to clients of a resolver, those affected can call up their resolver operator and demand they fix it. Since the users of the resolver may actually be paying customers, there might even be a chance that the resolver operator will listen.

What would be the recovery process if the existing root server system distributed bad data?  If "I" root started serving bad data, how would anyone non-technical know even who to call?  Assume they know how to call their ISP's help desk and that help desk is able to figure out it is the "I" root server that is serving the bad data. How will that help desk implement a fix on the "I" root server? What is the likely timeframe from detection of problem to fix compared to the slaving the root scenario?

More generally, what recourse does _anyone_ have if a root server operator (say) chooses not to upgrade bandwidth to their root when it drops the majority of queries? Or goes off the air for a few days? Or doesn't deploy IPv6? 

> - Routing issues (which is what I see the largest burden of a root server operator)

Must have missed this one and am unsure what it means in this context. What routing issues were asserted that resolver operators that slave the root are going to have?  It would seem to me that the slaving the root approach can vastly simplify the routing (no need for inter-AS anycast) so I must be missing something.

> - Political/regulative implications (to ensure a different TA is used than ICANN)

I'm confused. Did you mean to stop someone from using a different TA? What's to stop someone from doing that now?

> ...and possibly more.

Yes, perhaps there are more and perhaps if Warren obeys your recommendation, they'll be discovered. However, as many people have pointed out, _people are already slaving the root_ and oddly disaster has not befallen the Internet (or the customers of the folks that are slaving the root) as yet. Quoting Ralf Weber:

"The draft doesn't require every resolver to slave the zone, but merly is an information that this is a possible way to do it and I assume that large resolver operators would benefit from it [...] It in the end of course comes down to do we want to document what is out there  anyway or do we want to hide our heads in the sand. Especially for an operational group I would prefer the former."

> Once again, this is such a large issue that I would prefer a bit better arguments than what is demonstrated here.

Actually, since it is opt-in, it doesn't seem to be that large of an issue to me, but perhaps that's because I'm not a root server operator and have no particular interest in maintaining the status quo.

> Yes, I know you wrote in affection, but let this remind all of us that we can do better.

Undoubtedly "we" can.

Regards,
-drc

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 8 Jul 2014 08:39:01 +0200

> Sorry to disappoint you by stating how the main arguments against the draft appear to me.

That I understand, and I myself react like that regarding arguments both in favor and against the proposal. One could say the discussion is a typical non-constructive IETF discussion which too many are.

> Do you believe the current system addresses these concerns? If so, how?

The discussion about these things, and the differences between a cache and authoritative server I would like to have in a room where people are not shouting at each other. There are differences, and you know that as well as I.

> As I've pointed out, if bad data is being served to clients of a resolver, those affected can call up their resolver operator and demand they fix it. Since the users of the resolver may actually be…

The market economy forces fixing things is correct. What I was thinking of is for example the difference between restarting a caching resolver and re-priming an auth server. Sure, everyone can learn both recovery mechanisms, but "restart your server" is quite simple task. Once again, I want the arguments listed.

> What would be the recovery process if the existing root server system distributed bad data?  If "I" root started serving bad data, how would anyone non-technical know even who to call?  Assume they…

You here list a few to me different problems. If people get wrong data from the IP address of "I" they call Netnod.

> More generally, what recourse does _anyone_ have if a root server operator (say) chooses not to upgrade bandwidth to their root when it drops the majority of queries? Or goes off the air for a few…

That is, as you know, also an "interesting" discussion.

> Must have missed this one and am unsure what it means in this context. What routing issues were asserted that resolver operators that slave the root are going to have?  It would seem to me that the…

What I want to have examined is how to ensure the right data is coming to whoever wants it, and who is responsible to clean up when there are issues.

Today, as you say yourself, the responsibility is on the root server operators.

> I'm confused. Did you mean to stop someone from using a different TA? What's to stop someone from doing that now?

I see it as a big difference between having auth data (explicitly changed) within a difficult democracy and having caches of the data. Sure, some of them have already implemented what you talk about but having IETF explicitly saying auth data is coming from recursive resolvers will from my point of view drastically increase the amount of blocked DNS traffic across the global Internet and that will indeed impact network neutrality.

> "The draft doesn't require every resolver to slave the zone, but merly is an information that this is a possible way to do it and I assume that large resolver operators would benefit from it [...]…

I am not talking about situations where good people slave the root zone. I am talking about disaster recovery.

> Actually, since it is opt-in, it doesn't seem to be that large of an issue to me, but perhaps that's because I'm not a root server operator and have no particular interest in maintaining the status…

I do not see it as opt-in. Definitely not. I see this draft be a tool that is used to force opt in to a different root zone than what ICANN is managing. A very effective tool regarding fragmenting the Internet.

And having an incoming CTO of ICANN requesting fragmentation of the Internet actually worries me a bit.

Because of this, I think it must proven that increased deployment of this technology will not increase fragmentation of the Internet.

>> Yes, I know you wrote in affection, but let this remind all of us that we can do better.

Are you sure?

;-)

   Patrik

---

From: 🔒 Roy Arends <[email-masked]>
Date: Tue, 8 Jul 2014 12:40:14 +0100

Hiya,

I really like this idea. Many ISPs already do this, (including some high profile public recursives, like Google and OpenDNS), because it simply makes sense: It reduces latency for the end user, reduces outbound traffic overhead, eliminates an attack vector.

This specific document shouldn’t be a discussion point at all. Folks are doing this right now. What we need is a BCP that describes: IFF you are going to do it, here is how.

I would also like to see some facilitation around this as well: a notify service of new versions, a zone distribution service (xfer service), possibly out of ICANN or VeriSign.

Personally, I’m interested in what operators of large recursives have to say about this. 

Hope this helps.

Roy

> On 04 Jul 2014, at 21:50, Paul Hoffman <[email-masked]> wrote:
>

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 8 Jul 2014 08:03:36 -0400

> Personally, I’m interested in what operators of large recursives have to say about this. 

Roy 
you hit the nail on the head, this is a no brainer as a BCP. 

The contents of this draft may or may not be right at this point but we need a BCP that explains how to do this and the pitfalls to be aware off. 
For an DNS resolution provider that elects to  there are two ways to do it, 
	forward zone 
	local authoritative zone. 
both should be allowed, this document seems “bind” specific that it assumes that the recursive resolver can be both authoritative and recursive which is not a requirement. 

There is no need that every recursive resolver at a Resolution Provider have a copy of the root zone only that the resolvers know the “local root servers”. 

In my mind this is not that far off from Anycast root servers i.e. additional server placed closer to the query generators.
The big difference is in management and control. 
The root server operators believe (correctly) that they provide valuable service and are critical to the operation of the internet, They also believe that having
close control over all root servers is essential. 
A number of people over the years have said that the current model is not the only possible way to provide the same service just as well, 
further diversification of root server services  is enabled by DNSSEC. 

The open question is does the promotion of this type of service create any NEW attacks agains the CONTENT of the root zone,
 i.e. would this have made the it possible/easier for Turkey to restrict access to  Google and Twitter? 

The technical question that needs to be answered what is the safest way to distribute the root zone and locally validate it before making it available on the 
“local root servers”. In my mind the answer Notify and incremental XFR with stronger protections. 

I think the answer is NO thus I support the promotion of a BCP on “locally provided root servers”. 

	Olafur

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 8 Jul 2014 10:08:03 -0400

Colleagues,

We have two drafts on the general topic of wider distribution for the root zone, and the draft agenda says we'll devote some time to both of them.

The drafts discuss different methods, which may or may not be complementary, each having strengths and weaknesses to consider. It's no surprise that people have strong feelings about them.

To me at least, one important question is what problem we're seeking to solve, or document existing solutions for? I'm not suggesting a full requirements analysis, and I think there is a fairly simple underlying problem statement to be had (at least one!), but I'd like to take a step back from the specifics for a moment: we have now one document that some people seem to want to call a BCP and others want labeled strictly cautionary, and another document that we still haven't really looked at. I'd like to see as much agreement as possible, or at least as much clarity as possible, on how we'll judge what work we want to commit to as the WG: do we want a BCP out of this? a document describing methods, without judgment? a suggestion for IANA or others, which of course they can take or not? All of those things?

The kernel of a problem statement to me looks like: A few hundred root name servers behind a handful of IP addresses for a network of millions of servers used by billions of people constitutes a weakness; reliable access to the contents of the root zone should be more widely available. What people seem to want to discuss is how to scale the existing capacity within the constraints provided by the protocol, resource availability, and prevalent operational models.

If that's a reasonable question, pros and cons of a given solution spin out from there. 

Please review both drafts, discussion welcome here and at IETF 90.

best,
Suzanne

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Jul 2014 07:18:17 -0700

> - Recovery process when bad data end up in the resolver (cache v.s. auth)

That's the "cache has gone stale" issue that David raised. It is dealt with in the current draft. There is no other way for "bad data" to be in the cache other than by having it come from a signed root zone that has changed.

> - Routing issues (which is what I see the largest burden of a root server operator)

The draft does not impose any "routing issue" on the root. In fact, it says that the signed root might be gotten from entities that are not root zone operators.

> - Lack of DNSSEC validation

The draft says repeatedly that the information is only entered if it is DNSSEC validated. If you can find any sentence in the draft that says differently, I'll fix it immediately.

> - The fact not all data in the root zone is signed

That is a statement with no effect. If the data is not signed when it is retrieved from the signed root zone, it will be unsigned when retrieved using normal queries to the root zone.

> - Political/regulative implications (to ensure a different TA is used than ICANN)

That is a statement with no effect. Nothing in the draft changes the TA used to validate the root zone, so a validating recursive resolver acts identically whether it uses the mechanism or not.

> - Lack of legal protection of the root zone itself

Please try to explain this. The root zone operators current serve the root zone signed with DNSSEC. This draft doesn't change that, so there are no new legal implications.

> ...and possibly more.

That is not helpful.

> ...and of course a combination of these.

Umm, that is not helpful either.

> Once again, this is such a large issue that I would prefer a bit better arguments than what is demonstrated here.

The reason that there are not arguments in the -01 draft to deal with your issues above is that they seem unrelated to the draft. It is hard to have a section that says "Someone objected that this does X, but they are wrong" that has a finite length.

> Yes, I know you wrote in affection, but let this remind all of us that we can do better.

Sure, but bringing up issues that are just as true whether or not the draft is implemented is not "doing better". Having a list of issues that come from what the draft changes would be great: we can deal with those.

--Paul Hoffman

P.S. None of the above relates to Joe's big issue, which is that implementing the draft doesn't help anyone much. To me, that's a much more valid (and measurable) criticism than anything on the list above.

---

From: Tony Finch <[email-masked]>
Date: Tue, 8 Jul 2014 16:14:22 +0100

Ralf Weber <[email-masked]> wrote:
>
> I think if we think of the resolver having another auth root server at
> localhost the logic is easier to understand makes much more sense as
> DNSSEC protections would kick in even if someone managed to inject a bad
> zone.

I think that is too simplistic: simply slaving the root zone doesn't give
you any good way to detect or recover from a corrupted zone transfer. By
the time normal DNSSEC validation has detected any problems it is too
late.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
FitzRoy: Northerly 4 or 5, increasing 6 or 7 in south, perhaps gale 8 later in
southeast. Moderate, becoming moderate or rough in south. Fair. Good.

---

From: Jim Reid <[email-masked]>
Date: Tue, 8 Jul 2014 16:29:54 +0100

On 8 Jul 2014, at 16:14, Tony Finch <[email-masked]> wrote:

> simply slaving the root zone doesn't give you any good way to detect or recover from a corrupted zone transfer.

If that's a credible threat/risk, there are ways to mitigate it. Perhaps v2 of this draft could discuss these.

FWIW in playing with DNS for 20-odd years, I've never come across an actual example of zone transfer corruption, either in the protocol or the underlying TCP transport. That doesn't mean it can't happen of course. The risks are close to zero IMO. Which doesn't necessarily mean they should be ignored.

---

From: Ralf Weber <[email-masked]>
Date: Tue, 8 Jul 2014 17:31:52 +0200

Moin!

> the time normal DNSSEC validation has detected any problems it is too
Why you can still use 13 other real root servers to try from. And once this is know you just can tell the auth server portion to slave the zone again. But granted a validation after the transfer would be a good thing.

So long
-Ralf

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Jul 2014 08:38:06 -0700

> the time normal DNSSEC validation has detected any problems it is too

Can you give a scenario where that second sentence is true? That is, if a validating recursive resolver retrieves the entire signed zone, validates the contents, and then puts all of the contents in the cache, how can some problem happen "too late"?

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Tue, 8 Jul 2014 16:40:39 +0100

Jim Reid <[email-masked]> wrote:
> > simply slaving the root zone doesn't give you any good way to detect
> > or recover from a corrupted zone transfer.
>

-01 already does: it requires the slave to validate the entire zone before
putting it into service, and it requires fallback to "legacy" non-slave
resolution.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shannon, Rockall: Northwest backing south or southwest, 4 or 5, occasionally 6
at first in east Shannon. Moderate, becoming slight or moderate in north
Rockall. Rain later. Good, occasionally poor later.

---

From: Tony Finch <[email-masked]>
Date: Tue, 8 Jul 2014 16:45:29 +0100

Paul Hoffman <[email-masked]> wrote:
> Can you give a scenario where that second sentence is true? That is, if
> a validating recursive resolver retrieves the entire signed zone,
> validates the contents, and then puts all of the contents in the cache,
> how can some problem happen "too late"?

If you do that (i.e. if you do what your draft specifies rather than what
Ralf suggested) then you aren't simply slaving the zone (you are
validating it too) and you aren't doing normal per-query on-demand DNSSEC
validation.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking: Variable 4 becoming north 5 to 7. Slight becoming moderate. Fog
patches then rain. Moderate or good, occasionally very poor at first.

---

From: George Michaelson <[email-masked]>
Date: Wed, 9 Jul 2014 03:50:29 +1200

are you saying that to pre-validate signed materials along a trust chain
outside some immediate context (x) is inherently invalid? whats the limit
on x? seconds? microseconds?

don't all cacheing resolves cache common path trust checks under the TTL of
the elements along the path anyway?

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Jul 2014 08:55:58 -0700

> validating it too) and you aren't doing normal per-query on-demand DNSSEC

Just to be clear: you are saying that what we actually say to in the draft doesn't have the "too late" issue you refer to above, correct?

--Paul Hoffman

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 8 Jul 2014 18:00:32 +0200

Note that I only listed a hand full of issues I immediately think of that I think needs to be compared and evaluated. Like Suzanne wrote. In some cases there is no difference between an auth server and cache, in other cases there might be.

> On 8 jul 2014, at 16:18, Paul Hoffman <[email-masked]> wrote:
> 

Not all data in a signed zone is signed. But I appreciate you say you feel you have been thinking about it.

My point is that I really really really want to know that the unsigned info in a signed zone is NOT treated differently in an auth server than a cache.

Once again, I list questions.

> The draft does not impose any "routing issue" on the root. In fact, it says that the signed root might be gotten from entities that are not root zone operators.

I understand my statement was weird. Today when clients get "weird responses" they look where they get the response from, identify one of the 13 ip addresses and contact the root server that quite often do various monitoring and protection of the routing of that very IP address. I.e. responding to DNS queries is one thing, managing one of the key ip addresses is another.

Yes, I understand that is not really an issue if the resolver is auth for the root zone.

> The draft says repeatedly that the information is only entered if it is DNSSEC validated. If you can find any sentence in the draft that says differently, I'll fix it immediately.

How is that policed?

Yes, people can say that "that already happens" which of course is true. But I see a difference between recommending this and just making it possible, from the IETF.
> That is a statement with no effect. If the data is not signed when it is retrieved from the signed root zone, it will be unsigned when retrieved using normal queries to the root zone.

See above.

> That is a statement with no effect. Nothing in the draft changes the TA used to validate the root zone, so a validating recursive resolver acts identically whether it uses the mechanism or not.

Not really.

If you are auth, then queries by definition do not "leak" to a place where a different TA is needed.

> Please try to explain this. The root zone operators current serve the root zone signed with DNSSEC. This draft doesn't change that, so there are no new legal implications.

The root server operators (at least for example the three outside of the US) have an MOU with ICANN that say we will serve the zone ICANN serves. Where is the same protection between end users in $state using $isp under $regulative_policy that the same zone is served?

In this case I want $state to have for example have signed a treaty saying the root zone is not to be modified.

> That is not helpful.

Well, I was responding to drc that wrote something in affect, and my intention was to show a subset of issues to address and look at, as a longer list that what drc listed.

> Umm, that is not helpful either.

That was to protect myself. For example, the fact not everything in the root zone is signed, ability to sign and produce a new root server with new TA with not a complete root zone in $state under some interesting $regulation. Possibly using the same (or different ip addresses) than what is used today.

I hope proponents of this proposal can explain why this is different than an alternate root.

> Sure, but bringing up issues that are just as true whether or not the draft is implemented is not "doing better". Having a list of issues that come from what the draft changes would be great: we ca…

Understood. Once again, I responded more to the mail from drc than address the draft per se.

   Patrik

---

From: Tony Finch <[email-masked]>
Date: Tue, 8 Jul 2014 17:01:40 +0100

Paul Hoffman <[email-masked]> wrote:
>
> Just to be clear: you are saying that what we actually say to in the
> draft doesn't have the "too late" issue you refer to above, correct?

Right.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Dover, Wight: Variable 4 becoming northwest 4 or 5, occasionally 6 later.
Slight, becoming slight or moderate. Showers. Good.

---

From: Tony Finch <[email-masked]>
Date: Tue, 8 Jul 2014 17:03:09 +0100

> on x? seconds? microseconds?

I'm sorry I can't parse that.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Tue, 8 Jul 2014 17:06:46 +0100

Roy Arends <[email-masked]> wrote:
>
> I would also like to see some facilitation around this as well: a notify
> service of new versions, a zone distribution service (xfer service),
> possibly out of ICANN or VeriSign.

Does it need a notification service when the zone update period (every 12
hours ish) is much longer than the refresh period (30 minutes)?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Hebrides, Bailey: Variable 4, becoming southeasterly 4 or 5 later in west
Bailey. Slight or moderate, becoming slight in Hebrides. Mainly fair. Good,
occasionally poor.

---

From: Jim Reid <[email-masked]>
Date: Tue, 8 Jul 2014 17:15:11 +0100

> putting it into service, and it requires fallback to "legacy" non-slave

Indeed. But you seemed to be implying that those provisions were insufficient or defective. Oh well.

FWIW I wonder if "MUST validate" is good enough when there's no mention of the One True Trust Anchor which presumably should be used for that. Would out-of-band validation (handwave!) such as rsync over SSH be OK?

---

From: Joe Abley <[email-masked]>
Date: Tue, 8 Jul 2014 12:17:59 -0400

Hi Roy!

On 8 July 2014 at 7:40:22, 🔒 Roy Arends ([email-masked]) wrote:

> I really like this idea. Many ISPs already do this, (including some high profile public  
> recursives, like Google and OpenDNS), because it simply makes sense: It reduces latency  
> for the end user, reduces outbound traffic overhead, eliminates an attack vector.
>  
> This specific document shouldn’t be a discussion point at all. Folks are doing this right  
> now. What we need is a BCP that describes: IFF you are going to do it, here is how.

As I discussed with Warren back when he was still at the pre-typing, thinking stage on this draft, I agree with you. I think documenting the trade-offs and giving advice to people who have decided to slave the root themselves is valuable. (I proposed something like "slaving-root-considered-harmful" in my review last week, which with hindsight was a bit hysterical. I like the idea of writing a document that describes how, with current code and in the current operational landscape people could do this.

The document under discussion specifies protocol-level changes for resolvers, however, and goes further than simply providing analysis and recommendations about how people could make sure they don't shoot themselves in the foot.

Perhaps a way forward here is to reign in the current effort and constrain it to the best way of using a local copy of the root zone on a resolver today, with no protocol or specification changes to resolvers. Once we've identified the best such configuration and have identified any operational concerns with it, we will be in a much better position to consider changes to the resolver spec and/or new root zone distribution mechanisms to make it better.

Joe

---

From: George Michaelson <[email-masked]>
Date: Wed, 9 Jul 2014 04:22:56 +1200

whats the issue with the cycle time to validate whats in a blob you fetch,
against fetching the elements inside that blob on demand and processing
them?

what do you think DNS implementors do with the DS/DNSKEY validations they
perform along the FQDN each time? do you think they always throw away all
acquired knowledge to the root?

ps I tried google translate. it worked fine.

zeg je dat te pre-valideren ondertekend materialen langs een trust
chain buiten aantal onmiddellijke context (x) is inherent ongeldig?
Wat is de limiet op x? seconden? microseconden?

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Jul 2014 09:29:30 -0700

> Note that I only listed a hand full of issues I immediately think of that I think needs to be compared and evaluated. Like Suzanne wrote. In some cases there is no difference between an auth server…

Section 4 of our draft lists two very distinct possibilities for how the validating recursive resolver responds to cached information about the root: continue to act like a cache (do not set the AA bit), or as an authoritative slave (turn on the AA bit for answers for root zone info).

It sounds like you are only considering the second possibility, and that you consider that risky. If so, instead of attacking the entire draft, maybe just attack that one possible choice. If others agree with you, then that second option can be removed. I simply do not see how a validating recursive resolver that pulls in the entire root zone and validates it before putting it in the cache, and then responds exactly as if it had queried each record in the root, has any of the issues you are hammering on, particularly the "political" ones.

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Tue, 8 Jul 2014 17:33:03 +0100

Olafur Gudmundsson <[email-masked]> wrote:
>
> this document seems “bind” specific that it assumes that the recursive
> resolver can be both authoritative and recursive which is not a
> requirement.

You can't implement this draft's validation and fallback requirements just
by configuring BIND, so I think all name server software will need
significant improvements.

Tony.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Jul 2014 09:33:17 -0700

On Jul 8, 2014, at 9:15 AM, Jim Reid <[email-masked]> wrote:

> FWIW I wonder if "MUST validate" is good enough when there's no mention of the One True Trust Anchor which presumably should be used for that.

If a message (in this case, an RRset) is signed with a public key, the validator needs to use that exact public key to validate. There is no other option.

> Would out-of-band validation (handwave!) such as rsync over SSH be OK?

No. That would only validate the integrity of the data, not the origin.

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Tue, 8 Jul 2014 17:44:02 +0100

> against fetching the elements inside that blob on demand and processing

Time is not the issue.

Ralf seemed to be suggesting that lazy validation is OK, where you simply
slave the root zone locally and point a normal validating resolver at it.
If you do that then you don't have a sensible way to recover from a
corrupt transfer, because you will only discover it is bust when you are
processing a query and that's a bad time to try re-doing the transfer.

Maybe it would be OK if the resolver was configured to use the real root
servers as a fallback in case the local copy gets corrupted.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Cromarty, Forth: Variable 3 becoming northwest 4 or 5, occasionally 6 later.
Slight, becoming slight or moderate. Thundery showers and fog patches at
first. Moderate or good, occasionally very poor at first.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 8 Jul 2014 12:44:22 -0400

> significant improvements.

I agree with you that just configuring “Some off the shelf name server” is not enough but 
wether that should be built into Authoritative server or is a stand-alone tool  should be left 
each implementation. 

	Olafur

---

From: David Conrad <[email-masked]>
Date: Tue, 8 Jul 2014 11:30:30 -0700

Patrik,

On Jul 7, 2014, at 11:39 PM, Patrik Fältström <[email-masked]> wrote:
> One could say the discussion is a typical non-constructive IETF discussion which too many are.

Seems like it has been (mostly) a constructive discussion to me.

> Because of this, I think it must proven that increased deployment of this technology will not increase fragmentation of the Internet.

I'll admit I'm quite surprised and disappointed in your response here.  I hope you'll forgive me if I choose not to respond to you further on this thread.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 8 Jul 2014 11:51:45 -0700

Paul,

On Jul 8, 2014, at 7:18 AM, Paul Hoffman <[email-masked]> wrote:
> None of the above relates to Joe's big issue, which is that implementing the draft doesn't help anyone much. To me, that's a much more valid (and measurable) criticism than anything on the list above.

I believe section 5.1 discusses the benefits in a reasonable way, although perhaps more could be explained about the reduced latency aspects. Perhaps unsurprisingly, I might add a bit on responsiveness, i.e., having incentive to improve infrastructure or respond to problems based on the fact that direct/paying customers will scream at you if you don't.

However, I suspect whether or not you believe those benefits provide sufficient help depends largely on your belief about the existing infrastructure and how that infrastructure will scale in the future. Fortunately, the draft is not demanding the existing infrastructure be dismantled so people with differing opinions can choose to implement what they believe is best.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 8 Jul 2014 12:17:07 -0700

> Perhaps a way forward here is to reign in the current effort and constrain it to the best way of using a local copy of the root zone on a resolver today, with no protocol or specification changes t…

+1

Perhaps two drafts, one as Joe describes above.  The second, perhaps being Experimental, discussing thoughts on resolver modifications or novel zone distribution mechanisms?

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 8 Jul 2014 12:17:07 -0700

+1

Regards,
-drc

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 8 Jul 2014 15:24:47 -0400

> Perhaps two drafts, one as Joe describes above.  The second, perhaps being Experimental, discussing thoughts on resolver modifications or novel zone distribution mechanisms?

The AS112-like paradigm proposed in draft-lee-dnsop-scalingroot-00.txt also deserves review and comment.

(I've got no opinion on this, yet, as co-chair or root server operator or anything else, beyond "it should be discussed openly, with an eye on technical/operational means of making DNS resolution for internet users work/scale better.")

thx,
Suzanne

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 8 Jul 2014 21:48:36 +0200

> Seems like it has been (mostly) a constructive discussion to me.

Now yes, I completely agree!

> I'll admit I'm quite surprised and disappointed in your response here.  I hope you'll forgive me if I choose not to respond to you further on this thread.

That is completely understood, and excuses are not needed, if you forgive me ;-)

I was, as you saw, surprised myself over your words in the mail I responded to.

   Patrik

---

From: Terry Manderson <[email-masked]>
Date: Tue, 8 Jul 2014 17:46:25 -0700

On 9/07/2014 5:17 am, "David Conrad" <[email-masked]> wrote:

>> Perhaps a way forward here is to reign in the current effort and
>>constrain it to the best way of using a local copy of the root zone on a
>>resolver today, with no protocol or specification changes to resolvers.
>>Once we've identified the best such configuration and have identified
>>any operational concerns with it, we will be in a much better position
>>to consider changes to the resolver spec and/or new root zone
>>distribution mechanisms to make it better.
>
>+1
>
>Perhaps two drafts, one as Joe describes above.  The second, perhaps
>being Experimental, discussing thoughts on resolver modifications or
>novel zone distribution mechanisms?

That works for me, I think there is a natural inheritance there that will
certainly help scope the problem statement and the requirements of the
second document, so please do "A" and then work on "B" as Joe suggests.

Cheers,
Terry