Subject: [DNSOP] "Secure Unowned Hierarchical Anycast Root Name Service - And an Apologia" (circleid)

From: Paul Vixie <[email-masked]>
Date: Fri, 07 Nov 2014 13:19:48 -0800

because of excessive travel, i did not have a chance to help update
draft-lee-dnsop-scalingroot before the cutoff for ietf hawaii. here's
more background on that draft, sent first to my blog because i've heard
from so many policy makers about my radical mention of adding some root
name servers. scalingroot-01 will elide that text.

> In Internet Draft draft-lee-dnsop-scalingroot-00.txt, I described with
> my coauthors a method of distributing the task of providing DNS Root
> Name Service both globally and universally. In this article I will
> explain the sense of the proposal in a voice meant to be understood by
> a policy-making audience who may in many cases be less technically
> adept than the IETF DNSOP Working Group for whom the scalingroot-00
> draft was crafted. I will also apologize for a controversial
> observation concerning the addition of new root name servers, because
> while in truth and in fact I am proposing to add millions of root name
> server operators, I am in no way proposing to add only seven. It's my
> hope that the actual proposal (millions of new root name server
> operators), while having far greater policy implications than the
> non-proposal (adding only seven root name server operators), will be
> uncontroversial when understood in its full context.
>
> ... 

(http://www.circleid.com/posts/20141107_secure_unowned_hierarchical_anycast_root_name_service_and_apologia/)

-- 
Paul Vixie

---

From: Suzanne Woolf <[email-masked]>
Date: Sat, 8 Nov 2014 10:12:49 -0500

Paul,

Thanks for the update.

Do you expect to ask the WG to adopt the revised draft as a WG work item?

---

From: Paul Vixie <[email-masked]>
Date: Sat, 08 Nov 2014 14:37:54 -0800

> Suzanne Woolf <mailto:[email-masked]>
> Saturday, November 08, 2014 7:12 AM
> Paul,
>
> Thanks for the update.
>

yes, definitely. but not in hawaii and not on the basis of the -00 revision.

-- 
Paul Vixie

---

From: "John Levine" <[email-masked]>
Date: 9 Nov 2014 22:57:46 -0000

>(http://www.circleid.com/posts/20141107_secure_unowned_hierarchical_anycast_root_name_service_and_apologia/)

As I understand it, the proposal is to add another root server, the
"X" root, with A and AAAA records pointing at addresses that will
never be globally routed, with an invitation to networks of whatever
size to provide a root running on those addresses visible to hosts on
their own network.

Other than "it would be wrong", what's the practical difference
between that and just running your own server at the addresses of,
say, the B root?  The routes should only be in your own network, and
shouldn't be exported to anyone else, so if BGP signatures make other
people reject your route, that's a feature.  This hack of course has
the advantage that you can do it right now.

R's,
John

---

From: Paul Vixie <[email-masked]>
Date: Sun, 09 Nov 2014 15:10:31 -0800

> John Levine <mailto:[email-masked]>
> Sunday, November 09, 2014 2:57 PM
>

no. nothing like that. i had no idea that the scalingroot-00 draft was
that hard to understand. you have completely misunderstood the real
intent, but, that misunderstanding is almost certainly the fault of the
draft authors.
> the advantage that you can do it right now.

we intend that iana craft a second root zone, published in parallel with
the existing one, each being synchronized in terms of tld content, and
each signed with the then-current iana signing key.

the second one will only have two NS RR's at its apex, not thirteen.

those two NS RR's will each point to one A and one AAAA, in disparite
/24's and /48's. so, four new routing slots will be consumed by this
proposal.

the networks having these new IPv4 and IPv6 addresses will be routed
globally by anyone who cares to, for example by the existing root name
servers.

they can also be routed non-globally by anyone who cares to, for example
into the loopback network of an RDNS server, or into a LAN via its exit
gateway, or into a campus or ISP or region using no-export routing
advertisements.

RDNS operators who want this "alternative IANA root zone" will have to
change their root hints, and will be strongly advised to only do this if
they have DNSSEC validation and root key rollover support.

hopefully that's easier to understand than the draft, or the circleid
article, and i take full responsibility for the in-clarity of both.

-- 
Paul Vixie

---

From: Ralf Weber <[email-masked]>
Date: Sun, 9 Nov 2014 15:30:24 -0800

Moin!

> On 09 Nov 2014, at 15:10, Paul Vixie <[email-masked]> wrote:
> we intend that iana craft a second root zone, published in parallel with the existing one, each being synchronized in terms of tld content, and each signed with the then-current iana signing key.
> 
> those two NS RR's will each point to one A and one AAAA, in disparite /24's and /48's. so, four new routing slots will be consumed by this proposal.
> 
> the networks having these new IPv4 and IPv6 addresses will be routed globally by anyone who cares to, for example by the existing root name servers.
> 
> they can also be routed non-globally by anyone who cares to, for example into the loopback network of an RDNS server, or into a LAN via its exit gateway, or into a campus or ISP or region using no-export routing advertisements.
> 
> RDNS operators who want this "alternative IANA root zone" will have to change their root hints, and will be strongly advised to only do this if they have DNSSEC validation and root key rollover support.
They can do this with today with the current root zone. AXFR it from a root server, serve it and point your root hints to it. Why do you want to complicate this? Wouldn't it be better to implement this loopback root zone in the RDNS software which is I think what Warren proposes (Haven't read the new draft yet)?

Sorry for what may be stupid questions, but I am still trying to understand your proposal and the motivation behind it.

So long
-Ralf
---
Ralf Weber
e: [email-masked]

---

From: "John R Levine" <[email-masked]>
Date: 9 Nov 2014 15:50:20 -0800

> the second one will only have two NS RR's at its apex, not thirteen.

Oh, OK, rereading the Circle ID piece I see that's what you mean, but it's 
not super clear.

It's still not clear to me what the practical advantage of this is over my 
hack of networks inserting their own routes for one of the existing 
servers, other than perhaps that it's easier to diagnose from outside 
what's going on.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 9 Nov 2014 18:58:55 -0500

Hi,

> the second one will only have two NS RR's at its apex, not thirteen.

I didn't understand that, either; I thought what John said was what
you intended.

Doesn't this suffer in terms of robustness?

And isn't there some danger that this "parallel" root becomes an
attractive target for those who want things to be different than
what's in the "official" root?  That is, in effect, isn't this a plain
old alternative root?

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 10 Nov 2014 08:13:14 -0000

>what's in the "official" root?  That is, in effect, isn't this a plain

I would assume the plan is that the clients use DNSSEC to validate
the responses.

This doesn't seem notably less secure than the current scheme, given
how many networks "helpfully" reroute DNS traffic already.  But my
question about why not just hijack the address of an existing root
stands.

R's,
John

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 10 Nov 2014 08:12:13 -0800

> On Nov 10, 2014, at 12:13 AM, John Levine <[email-masked]> wrote:
> 

This happens in China (on CERNET I believe): there are a set of root mirrors that hijack most (but not all) of the root IPs.  As far as we can tell, the servers are legitimate, returning the proper responses, except that the mirror servers don't support DNSSEC.

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: Tony Finch <[email-masked]>
Date: Mon, 10 Nov 2014 16:23:32 +0000

Nicholas Weaver <[email-masked]> wrote:
>
> This happens in China (on CERNET I believe): there are a set of root
> mirrors that hijack most (but not all) of the root IPs.  As far as we
> can tell, the servers are legitimate, returning the proper responses,
> except that the mirror servers don't support DNSSEC.

Those are unusual meanings for "legitimate" and "proper responses"!

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Wight, Portland: Southwest 5 to 7 backing south 6 to gale 8. Moderate or
rough. Thundery showers, rain later. Good, occasionally poor.

---

From: "John R Levine" <[email-masked]>
Date: 10 Nov 2014 10:48:48 -1000

> Those are unusual meanings for "legitimate" and "proper responses"!

Given the extensive use of anycast, these days one has only the vaguest 
idea of who's answering any particular query.  But if DNSSEC says it's 
good, why do you care?

Regards,

---

From: George Michaelson <[email-masked]>
Date: Mon, 10 Nov 2014 11:02:12 -1000

Given the behaviour of unknown algorithm, if the anycast node signs with an
algoritm they can guarantee you don't understand, how did you know DNSSEC
was turned off silently?

ie, downgrade silent response means that an anycast node can mask changes
to the root, because you won't know DNSSEC was disabled.

(happy to be shown this can't happen btw. its the risk I worry about)

On Mon, Nov 10, 2014 at 10:48 AM, John R Levine <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Paul Vixie <[email-masked]>
Date: Mon, 10 Nov 2014 13:28:42 -0800

> Ralf Weber <mailto:[email-masked]>
> Sunday, November 09, 2014 3:30 PM
> Moin!
>
> They can do this with today with the current root zone. AXFR it from a
> root server, serve it and point your root hints to it. Why do you want
> to complicate this?

because right now the people who do this have to pirate the address
space of root name servers, and they have to do it for all of our
addresses. under this proposal, there would be no piracy required, and
there would only be two address blocks per stack (two for v4, two for
v6) to do it for.

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

> Wouldn't it be better to implement this loopback root zone in the RDNS
> software which is I think what Warren proposes (Haven't read the new
> draft yet)?

that rather begs the question, don't you think? i saw warren's draft
after i wrote the section of the ICANN ITI report that covered this
topic, but before we wrote the internet draft on the same topic. if you
want to know "why is this better, or why is it still or also nec'y, or
why do we need both?" then you should ask that.

see: https://www.icann.org/en/system/files/files/report-21feb14-en.pdf
(page 25)
> Sorry for what may be stupid questions, but I am still trying to
> understand your proposal and the motivation behind it.
>
as i wrote to john, the editorial quality of the draft is apparently
quite low, given how much it has been misunderstood. hopefully the
circleid article helps.

see:
http://www.circleid.com/posts/20141107_secure_unowned_hierarchical_anycast_root_name_service_and_apologia/

-- 
Paul Vixie

---

From: Paul Vixie <[email-masked]>
Date: Mon, 10 Nov 2014 13:29:47 -0800

> John R Levine <mailto:[email-masked]>
> Sunday, November 09, 2014 3:50 PM
>
> ...
>
> It's still not clear to me what the practical advantage of this is
> over my hack of networks inserting their own routes for one of the
> existing servers, other than perhaps that it's easier to diagnose from
> outside what's going on.

i think that a recommendable architecture won't involve BGP piracy.

-- 
Paul Vixie

---

From: Paul Vixie <[email-masked]>
Date: Mon, 10 Nov 2014 13:34:05 -0800

> Andrew Sullivan <mailto:[email-masked]>
> Sunday, November 09, 2014 3:58 PM
> Hi,
>
>

yes. parts of the 'net can be made root-serverless by accident this way,
more easily than in the current system, because very few people
currently try to intercept traffic destined for the 13 root name
servers. that risk is part of the cost in any cost-benefit analysis of
the proposal. i expect to mitigate the risk slightly by telling any
given unowned-anycast provider that they should only intercept one of
the two unowned anycast server address blocks, so that if they have an
outage, it will only affect one of the designated servers, leaving open
the likelihood that the other will still be reachable.

> what's in the "official" root? That is, in effect, isn't this a plain

no. any RDNS operator who receives advice on how to change their root
hints to use the unowned-anycast root server addresses will also be told
not to turn this on unless they have also turned on DNSSEC validation
and root key rollover. so, no.

-- 
Paul Vixie

---

From: Paul Vixie <[email-masked]>
Date: Mon, 10 Nov 2014 13:43:58 -0800

> George Michaelson <mailto:[email-masked]>
> Monday, November 10, 2014 1:02 PM
> Given the behaviour of unknown algorithm, if the anycast node signs
> with an algoritm they can guarantee you don't understand, how did you
> know DNSSEC was turned off silently?
>
> ie, downgrade silent response means that an anycast node can mask
> changes to the root, because you won't know DNSSEC was disabled.
>

what would we like to have happen in this case? bind9 has a
must-be-secure option that would transform this into total darkness.
some users would rather be in total darkness when their root service has
been intercepted by non-trusted party. others would rather just go on as
before.

of course, this risk exists today, but at smaller scale because very few
people deliberately advertise root name service prefixes. it's worth
carefully enumerating the desired behaviour, both in case this proposal
goes through, and, even if it doesn't and we keep the status quo.

-- 
Paul Vixie

---

From: Tony Finch <[email-masked]>
Date: Tue, 11 Nov 2014 10:00:15 +0000

> idea of who's answering any particular query.  But if DNSSEC says it's

In the case of these servers, DNSSEC says it is bad, so it is a DoS.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fitzroy: West or southwest 5 to 7, occasionally gale 8. Rough at first in
east, otherwise very rough or high. Thundery showers. Good occasionally poor.

---

From: Tony Finch <[email-masked]>
Date: Tue, 11 Nov 2014 10:31:20 +0000

> algoritm they can guarantee you don't understand, how did you know DNSSEC

Because your trust anchor says the root zone MUST be signed with a
particular key.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher, German Bight: South 4 or 5, backing southeast 5 to 7, perhaps gale 8
later. Slight or moderate, becoming moderate or rough. Showers later. Good
becoming moderate or poor.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 11 Nov 2014 18:14:44 -0500

> yes. parts of the 'net can be made root-serverless by accident this way,

Ok, good, I didn't misunderstand.

> and root key rollover. so, no.

But my point is that it's a different zone.  Once you allow for the
possibility that an apex record could change in this zone, why not
change other records too?  And who gets to control this other zone?
It's no longer "the root zone", by definition.  It's an alternative
zone, it seems to me.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Evan Hunt <[email-masked]>
Date: Wed, 12 Nov 2014 00:11:03 +0000

On Tue, Nov 11, 2014 at 06:14:44PM -0500, Andrew Sullivan wrote:
> change other records too?

Because that's not necessary to address the technical issue this proposal
is intended to address, and t would be undesirable for a host of other
reasons, so, you know, let's not do that.

> And who gets to control this other zone?

Same people that control the root zone now.

> It's no longer "the root zone", by definition.  It's an alternative

Yes, but with changes explicitly limited to the NS RRset, and not
affecting any delegation content.

Of course, this does suggest the idea of simply updating the one-and-only
root zone to contain a single additional NS record:

    .               IN      NS      [a-m].root-servers.net.
    .               IN      NS      local-root.
    local-root.     IN      A       127.12.12.12

On a system that had a server listening and serving root at 127.12.12.12,
a recursive resolver would prefer to use it for root queries because of the
very short RTT.  On a system that didn't, a few queries would be wasted to
determine that the local-root address was nonresponsive, and then the
server would carry on using the traditional roots.  This is kind of a
hybrid of the Lee/Vixie and Kumari/Hoffman mechanisms: ohh lord,
kum-ba-yah. :)

For the record, I'm not comfortable with the Lee/Vixie proposal that new
root server addresses be globally routable and anycasted by anyone who
wants to, but I'd be fine with it if they were localhost addresses, as
above, or reserved nonroutable addresses similar to (but distinct from)
RFC 1918 addresses.  I also think Kumari/Hoffman has most of the same
benefits at lower cost.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 11 Nov 2014 19:51:38 -0500

> reasons, so, you know, let's not do that.

It would be undesirable to you.  It is not plain that it would be
undesirable to all those pony-wanters who would argue that their
"technical issue" should be fixed in this alternative zone too.  We
don't get to lose our innocence a little bit.

> Same people that control the root zone now.

Why?  Who says?  That's just wishing away the layer-9-plus issues this
strategy automatically attracts.  It really is an alternate root, no
matter how hard one cringes from that.  These issues are precisely why
the IAB was so clear on the unique root.  (Full disclosure: I'm on the
IAB now, but I wasn't when that was written.  I'm not, as usual,
writing with an IAB hat on.)

> affecting any delegation content.

Because we say so?  

Best regards,

A
-- 
Andrew Sullivan
[email-masked]

---

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

> Tuesday, November 11, 2014 3:14 PM
>> ... any RDNS operator who receives advice on how to change their root
> But my point is that it's a different zone.

in the formal sense of zone identity, yes. in practical terms, no.
especially not these terms:

> Once you allow for the

that would be outside the scope of this proposal. this proposal is to
have iana create a second root zone stream, identical in all details
(change frequency, TLD presence, TLD NS content, serial number, signing
key) to the one root zone stream we have today, with the one exception
that it would have a different apex NS RRset.

if you'd like to discuss changing other records too, then please make a
proposal to change other records, but in any case please do not
presuppose for the purpose of discussing this proposal, changes, actual
or potential, which are not being proposed.

> And who gets to control this other zone?

as in the proposal, and as clarified here, and as explained in the ICANN
ITI report, and as detailed in the recent circleid article on the topic
of this proposal, IANA must control this root zone just as they control
the current one.

i literally do not know how i can make that point more clearly than i
have done. suggestions are welcome.
> It's no longer "the root zone", by definition.  It's an alternative

that was never the sense of this proposal. have you read all of the
supplementary materials to this thread?

https://www.icann.org/en/system/files/files/iti-report-15may14-en.pdf
(from page 26) 

http://ss.vix.su/~vixie/alternate-rootism.pdf (note, published in 2005)

http://tools.ietf.org/html/draft-lee-dnsop-scalingroot-00

so, to me, the interpretation you claim "seems to [you]" is completely
unintelligible.

i am, and always have been, a single-namespace zealot. "one world, one
internet, one namespace."

-- 
Paul Vixie

---

From: Paul Vixie <[email-masked]>
Date: Tue, 11 Nov 2014 22:26:22 -0800

> Evan Hunt <mailto:[email-masked]>
> Tuesday, November 11, 2014 4:11 PM
> ... For the record, I'm not comfortable with the Lee/Vixie proposal
> that new root server addresses be globally routable and anycasted by
> anyone who wants to, but I'd be fine with it if they were localhost
> addresses, as above, or reserved nonroutable addresses similar to (but
> distinct from) RFC 1918 addresses. I also think Kumari/Hoffman has
> most of the same benefits at lower cost.

the vixie/lee proposal requires global routing in order to support
cooperating rdns operators independent of their topology. a correct rdns
configuration must remain correct even if transplanted to a different
part of the topology. in other words the expectation of global
reachability of the unowned anycast prefixes is not merely
non-accidental, but actually quite deliberate and vital.

i don't know how to answer your discomfort. as you know i was
responsible for f-root's anycast growth for many years; as you may not
know i was responsible for as112's early growth after a bill manning
experiment succeeded. i am now a member of the c-root team. i've been
watching anycast of infrastructure services, both owned and unowned
anycast, for about 15 years. i do not share, nor do i understand, your
discomfort.

-- 
Paul Vixie

---

From: Evan Hunt <[email-masked]>
Date: Fri, 14 Nov 2014 18:33:36 +0000

On Tue, Nov 11, 2014 at 10:26:22PM -0800, Paul Vixie wrote:
> experiment succeeded.

AS112 absolutely proves that unowned anycast can work at scale; that's not
my concern.  But if my neighbor announces a route to the AS112 addresses,
and then misconfigures a server, fills it with lies, or logs all my
queries, the practical effect on me is pretty small: the worst case
scenario I can think of offhand is that somebody gleans information about
my internal network topology that probably wouldn't have been difficult to
guess anyway.

I believe there's more scope for an incompetent or malicious root server
operator to block, surveil, or deceive me, and while there are defenses I
can deploy against some misbehaviors, I think we need to be cautious about
about a potential increase in the number of bad actors and failure modes.

While I don't particularly share Andrew's camel's-nose-on-the-slippery-slope
concerns about a root zone with a modified NS rrset, if I were going to use
it myself, it would *only* be because I was deploying a local root instance
on my own network or on the local host.  If I weren't going to deploy it
myself, then I'd stick to the traditional roots.  I may not be typical
in that respect, but if I am, then there's no need for unowned anycast
anyway.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 14 Nov 2014 10:49:48 -0800

> Friday, November 14, 2014 10:33 AM
>
> ...
>

because the global routing table is fundamentally insecure, such that
more or less anybody can announce more or less anything, where the
announcements may not be long lived nor widely propagated, i think
you're already facing and living in the dangerous situation that you're
saying scalingroot-00 presents.

the merits of this proposal should be judged on engineering economics
and risk management: what's the average and worst case and best case if
we adopt, vs. what's the average and worst case and best case if we
don't? i estimate that more traffic goes awry or undeliverable in
today's 13-server internet than will be so under this million-server
proposal, and that the delta will trend upward with topological density
and complexity.
> in that respect, but if I am, then there's no need for unowned anycast

those words are very insightful. because either the vixie/lee -or- the
kumari/hoffman proposal requires changes to each participating RDNS to
"opt-in" to the proposed method, the difference is in the scope of those
changes (add forwarding logic, add a loopback stealth root server; or,
change your root hints), i believe that the scalingroot-XX (-01 should
come out before december 8's hong kong workshop) should advise
participating RDNS operators to gauge the reliability and attack
resilience of their coreward Internet routing path, and consider
operating their own "unowned anycast" instances locally if they lack
full trust or accountability with their upstreams.

vixie

-- 
Paul Vixie

---

From: David Conrad <[email-masked]>
Date: Fri, 14 Nov 2014 11:10:31 -1000

Hi,

On Nov 14, 2014, at 8:33 AM, Evan Hunt <[email-masked]> wrote:
> AS112 absolutely proves that unowned anycast can work at scale;

I think AS112 is a red herring: it doesn't prove anything that wasn't already known ages ago (i.e., BGP works). 

I believe a better (still not perfect) analogy would be 6to4 and I'd refer to the discussion around https://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-08.  

However, I'm a bit confused: AFAIK, we're talking about a draft that has been revised and that revision has not been submitted to DNSOP for consideration (yet).  Perhaps it would make sense to defer discussion until the revised draft is more generally available?

Regards,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Sat, 15 Nov 2014 08:19:57 +1100

In message <[email-masked]>, David Conrad writes:
> I think AS112 is a red herring: it doesn't prove anything that wasn't
> already known ages ago (i.e., BGP works).
>
> I believe a better (still not perfect) analogy would be 6to4 and I'd
> refer to the discussion around
> https://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-08.
>
> However, I'm a bit confused: AFAIK, we're talking about a draft that has
> been revised and that revision has not been submitted to DNSOP for
> consideration (yet).  Perhaps it would make sense to defer discussion
> until the revised draft is more generally available?
>
> Regards,
> -drc

6to4 has asymetric routing 99.99999% of the time, encapsulating
IPv4 address mismatch, etc. which are 6to4 specific issues.

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

---

From: "Wolfgang Nagele (AusRegistry)" <[email-masked]>
Date: Fri, 14 Nov 2014 21:48:31 +0000

Hi,

One of my biggest concerns about the current proposal is that it seems to suggest that AS112 works.

I would like to find some definition of “works” and how we come to that conclusion. In my experience there are AS112 nodes out there that are misconfigured in many ways (RIPE Atlas be your friend). Returning SERVFAILs, wrong data, etc. While wrong data is safeguarded by using DNSSEC in this proposal, malfunction is likely to occur still and can be just as bad. In the current system this issue is lessened due to the many different operators.
Within a given enterprise or ISP that would have limited impact and one could just point the finger at them and not care (although I don’t agree with that either). However route leaks are going to occur as they have in the past (no-export stripping happens by accident) and will start to have impact on users outside of that admin/routing domain. Assuming that local routes are always the routes that are chosen first is a flawed assumption. Routing is integral to this proposal and cannot be disregarded if you wanna find a workable solution.

From a TLD operator perspective I think it’s a huge step backwards that we will loose our update propagation assurance. Will I have to rely on the RRSIG expiry as my worst case scenario for a zone update to be fully propagated? With the sort of requirements that are put on TLD operators and DNS operators these days that sounds completely unacceptable path to me. It’s very different from AS112 where there is are simple zones that are configured as master and then remain that way.

I support the expansion of root server deployments. In my opinion this can be fully achieved in the given framework and ICANN as the operator of L-root has shown what can be done in a very short period of time. The discussion should be about the standards of operation that each root server operator is held to these days. There should be no question that some of the current root server operators muscle a way more substantial deployment than others. If it’s politically too sensitive/hard to establish any level of quality with the given root server operators, the addition of other root server operators within the current protocol limitations could be used to hold them to a certain standard. For the overall system to function well this would suffice. This is very similar what was done as part of the new gTLD program from ICANN where a whole set of requirements was added that didn’t exist before (IPv6, DNSSEC, etc.).

In closing, this draft proposes a solution to a problem that hasn’t been quantified and has no measure of success. Personally I think that’s bad practice.

Regards,
Wolfgang

---

From: Paul Vixie <[email-masked]>
Date: Fri, 14 Nov 2014 13:53:39 -0800

> David Conrad <mailto:[email-masked]>
> Friday, November 14, 2014 1:10 PM
> Hi,
>

my reason for mentioning AS112 is that its target protocol is UDP
request-response (that is, DNS itself, same as for scalingroot-00), and
is in my opinion more relevant to this discussion than the 6to4
experience, where multi-roundtrip protocols such as TCP/80 were meant to
be carried.

nevertheless:
>
> However, I'm a bit confused: AFAIK, we're talking about a draft that
> has been revised and that revision has not been submitted to DNSOP for

strong +1 here. i've issued and then discussed my apologia for the poor
readability and high controversy of scalingroot-00, and i'd be grateful
if we could postpone any more scalingroot-XX discussion until after
scalingroot-00 is published.

-- 
Paul Vixie

---

From: David Conrad <[email-masked]>
Date: Fri, 14 Nov 2014 11:59:35 -1000

Mark,

On Nov 14, 2014, at 11:19 AM, Mark Andrews <[email-masked]> wrote:
>> I believe a better (still not perfect) analogy would be 6to4
> 
> 6to4 has asymetric routing 99.99999% of the time,

99.9% of all statistics are made up.

> encapsulating IPv4 address mismatch, etc. which are 6to4 specific issues.

You apparently missed the "(still not perfect) analogy" bit.

The point was that operationally, anycast can be a PITA to debug and unowned anycast increases the magnitude of the PITA.

I'll not comment on the split root zone aspects until I see the revised draft.

Regards,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Fri, 14 Nov 2014 14:17:11 -0800

i think we're about to enter a non-discuss period for scalingroot-XX,
yet this message touches other topics.

> Wolfgang Nagele (AusRegistry) <mailto:[email-masked]>
> Friday, November 14, 2014 1:48 PM
> Hi,
>
actually, the proposal doesn't mention AS112, but my discussion of the
proposal here has mentioned AS112.
>
> I would like to find some definition of “works” and how we come to
> that conclusion. In my experience there are AS112 nodes out there that
> are misconfigured in many ways (RIPE Atlas be your friend). Returning
> SERVFAILs, wrong data, etc. While wrong data is safeguarded by using
> DNSSEC in this proposal, malfunction is likely to occur still and can
> be just as bad.
because AS112 only serves in-addr for non-routable address space (as
described in RFC 1918), its failures are mostly benign -- it's rare to
find someone who cares that the PTR for 10.0.0.73 has some particular
value. in that way AS112 is a terrible canary for the scalingroot-XX
coal mine, because data failures in the root zone are extremely
noticeable and important. in other words the only reason we run AS112 at
all is to keep the queries out of more important servers (like the root
servers or the in-addr.arpa servers), whereas we have a broader and more
powerful motive to run root servers.

for that same reason, i'm not very worried. failures in AS112 servers go
mostly unnoticed and as a result they might not be fixed quickly or
ever. failures in root name service are extremely visible and will be
noticed and fixed pretty quickly. so, in a way, AS112's weakness is
scalingroot-00's strength.

> In the current system this issue is lessened due to the many different
> operators.
i think you mean that the issue is lessened due to the small number of
well known highly visible operators, since in scalingroot-XX, there
would be millions of operators rather than a dozen or so operators.

> Within a given enterprise or ISP that would have limited impact and
> one could just point the finger at them and not care (although I don’t
> agree with that either). However route leaks are going to occur as
> they have in the past (no-export stripping happens by accident) and
> will start to have impact on users outside of that admin/routing domain.
route leaks also occur for the existing root name server anycast nodes.
we're not inventing new trouble here.

> Assuming that local routes are always the routes that are chosen first
> is a flawed assumption. Routing is integral to this proposal and
> cannot be disregarded if you wanna find a workable solution.
as i tried to explain in the circleid post last week...

...the routing issues are integral to the proposal (as you say) and are
in no way disregarded (as you ask).
>
> From a TLD operator perspective I think it’s a huge step backwards
> that we will loose our update propagation assurance. Will I have to
> rely on the RRSIG expiry as my worst case scenario for a zone update
> to be fully propagated? With the sort of requirements that are put on
> TLD operators and DNS operators these days that sounds completely
> unacceptable path to me. It’s very different from AS112 where there is
> are simple zones that are configured as master and then remain that way.
my primary reason for answering this message on-list rather than
privately is to ask you whether your stated concern also applies to
draft-wkumari-dnsop-root-loopback? (it would seem so, in which case,
that part of this thread should continue here, even while the parts
related narrowly to scalingroot-XX should be paused for now.)
>
> ...
>
> In closing, this draft proposes a solution to a problem that hasn’t
> been quantified and has no measure of success. Personally I think
> that’s bad practice.
i hope you'll make time to come to hong kong on december 8-9 to inform
the discussion with your perspective.

mine is: several of us have, and many of us could, construct a simple,
cheap, effective method to ddos all 300+ root name servers, untraceably
and unstoppably. please do the thought experiment. we can repeat it as a
group "bar bof" thought experiment in hong kong if you wish. but in any
case i'm going to make that harder; while no service can ever be
"ddos-impossible" we can and should work toward "ddos-difficult". i
pushed f-root into global anycast on the strength of m-root's pioneering
early success with it. i applaud l-root's efforts. but i'm not satisfied
that any number of hundreds of servers, or any number of dozens of
operators, can serve the internet as it has become and as it will be.

-- 
Paul Vixie

---

From: "Wolfgang Nagele (AusRegistry)" <[email-masked]>
Date: Fri, 14 Nov 2014 22:28:09 +0000

One of my biggest concerns about the current proposal is that it seems to suggest that AS112 works.
actually, the proposal doesn't mention AS112, but my discussion of the proposal here has mentioned AS112.
Correct.

I would like to find some definition of “works” and how we come to that conclusion. In my experience there are AS112 nodes out there that are misconfigured in many ways (RIPE Atlas be your friend). Returning SERVFAILs, wrong data, etc. While wrong data is safeguarded by using DNSSEC in this proposal, malfunction is likely to occur still and can be just as bad.
because AS112 only serves in-addr for non-routable address space (as described in RFC 1918), its failures are mostly benign -- it's rare to find someone who cares that the PTR for 10.0.0.73 has some particular value. in that way AS112 is a terrible canary for the scalingroot-XX coal mine, because data failures in the root zone are extremely noticeable and important. in other words the only reason we run AS112 at all is to keep the queries out of more important servers (like the root servers or the in-addr.arpa servers), whereas we have a broader and more powerful motive to run root servers.

for that same reason, i'm not very worried. failures in AS112 servers go mostly unnoticed and as a result they might not be fixed quickly or ever. failures in root name service are extremely visible and will be noticed and fixed pretty quickly. so, in a way, AS112's weakness is scalingroot-00's strength.
Agree on the technical nature of AS112 and that it goes largely unnoticed. That’s why I don’t like the notion of drawing conclusions that scalingroot-XX might work based on AS112 experience. It’s flawed.

In the current system this issue is lessened due to the many different operators.
i think you mean that the issue is lessened due to the small number of well known highly visible operators, since in scalingroot-XX, there would be millions of operators rather than a dozen or so operators.
No, in case that K-root (sorry guys ;)) has a failure it is less likely that L-root has one as well. In the case of scalingroot-XX propagated failures due to a single operator are higher.

Within a given enterprise or ISP that would have limited impact and one could just point the finger at them and not care (although I don’t agree with that either). However route leaks are going to occur as they have in the past (no-export stripping happens by accident) and will start to have impact on users outside of that admin/routing domain.
route leaks also occur for the existing root name server anycast nodes. we're not inventing new trouble here.
Now at least I know who to contact. See the issues with the root instances in Beijing and how quickly the could be resolved once noticed.

Assuming that local routes are always the routes that are chosen first is a flawed assumption. Routing is integral to this proposal and cannot be disregarded if you wanna find a workable solution.
as i tried to explain in the circleid post last week...

...the routing issues are integral to the proposal (as you say) and are in no way disregarded (as you ask).
Good. Thanks.

From a TLD operator perspective I think it’s a huge step backwards that we will loose our update propagation assurance. Will I have to rely on the RRSIG expiry as my worst case scenario for a zone update to be fully propagated? With the sort of requirements that are put on TLD operators and DNS operators these days that sounds completely unacceptable path to me. It’s very different from AS112 where there is are simple zones that are configured as master and then remain that way.
my primary reason for answering this message on-list rather than privately is to ask you whether your stated concern also applies to draft-wkumari-dnsop-root-loopback? (it would seem so, in which case, that part of this thread should continue here, even while the parts related narrowly to scalingroot-XX should be paused for now.)
Yes it applies the same way to Warren’s draft.

In closing, this draft proposes a solution to a problem that hasn’t been quantified and has no measure of success. Personally I think that’s bad practice.
i hope you'll make time to come to hong kong on december 8-9 to inform the discussion with your perspective.
I would be happy to help with work to quantify the problem. As said, I think there are more ways to go about this and it seems that the “I want my own root server” is taking centre stage without there necessarily being a need for that.

mine is: several of us have, and many of us could, construct a simple, cheap, effective method to ddos all 300+ root name servers, untraceably and unstoppably. please do the thought experiment. we can repeat it as a group "bar bof" thought experiment in hong kong if you wish. but in any case i'm going to make that harder; while no service can ever be "ddos-impossible" we can and should work toward "ddos-difficult". i pushed f-root into global anycast on the strength of m-root's pioneering early success with it. i applaud l-root's efforts. but i'm not satisfied that any number of hundreds of servers, or any number of dozens of operators, can serve the internet as it has become and as it will be.
Many tales to tell ...

---

From: Mark Andrews <[email-masked]>
Date: Sat, 15 Nov 2014 10:14:08 +1100

In message <[email-masked]>, David Conrad writes:
> The point was that operationally, anycast can be a PITA to debug and
> unowned anycast increases the magnitude of the PITA.
>

6to4 has the listed issues independent of whether you use the anycast
to get to the decapsulation router or not.  Using 6to4 as a reason
for not doing anycast is like comparing apples to cars.  They have
nothing to so with each other.

Mark

---

From: Warren Kumari <[email-masked]>
Date: Sun, 16 Nov 2014 06:11:01 -1000

> to suggest that AS112 works.

Actually, AS112 works just fine....
.
.
.
... except when it doesn't.

It is very hard to discover who is answering AS112 queries and go poke them
when things go awry - luckily, the primary effect of a "bad" AS112 node is
often (usually?) just a reduction in the AS112 benefit - it doesn't
actually break you, it just means you don't get the win.

The very fact that anycast works so well means that finding all the AS112
nodes and contacting them, to either delegate new space to them, or remove
existing delegations lead to the omniscient-as112 draft, and
then draft-ietf-dnsop-as112-dname ("AS112 Redirection using DNAME"), which,
IIRC finished IETF LC is waiting for us to incorporate a comment or two.

>  I would like to find some definition of “works” and how we come to that
> conclusion. In my experience there are AS112 nodes out there that are
> misconfigured in many ways (RIPE Atlas be your friend). Returning
> SERVFAILs, wrong data, etc. While wrong data is safeguarded by using DNSSEC
> in this proposal, malfunction is likely to occur still and can be just as
> bad.
>

Well, luckily DNSSEC is ubiquitous at this point...

> Within a given enterprise or ISP that would have limited impact and one
> could just point the finger at them and not care (although I don’t agree
> with that either). However route leaks are going to occur as they have in
> the past (no-export stripping happens by accident) and will start to have
> impact on users outside of that admin/routing domain. Assuming that local
> routes are always the routes that are chosen first is a flawed assumption.
> Routing is integral to this proposal and cannot be disregarded if you wanna
> find a workable solution.
>
>  From a TLD operator perspective I think it’s a huge step backwards that
> we will loose our update propagation assurance. Will I have to rely on the
> RRSIG expiry as my worst case scenario for a zone update to be fully
> propagated? With the sort of requirements that are put on TLD operators and
> DNS operators these days that sounds completely unacceptable path to me.
> It’s very different from AS112 where there is are simple zones that are
> configured as master and then remain that way.
>
>  I support the expansion of root server deployments. In my opinion this
> can be fully achieved in the given framework and ICANN as the operator of
> L-root has shown what can be done in a very short period of time. The
> discussion should be about the standards of operation that each root server
> operator is held to these days. There should be no question that some of
> the current root server operators muscle a way more substantial deployment
> than others. If it’s politically too sensitive/hard to establish any level
> of quality with the given root server operators, the addition of other root
> server operators within the current protocol limitations could be used to
> hold them to a certain standard. For the overall system to function well
> this would suffice. This is very similar what was done as part of the new
> gTLD program from ICANN where a whole set of requirements was added that
> didn’t exist before (IPv6, DNSSEC, etc.).
>
>  In closing, this draft proposes a solution to a problem that hasn’t been
> quantified and has no measure of success. Personally I think that’s bad
> practice.
>
>  Regards,
> Wolfgang
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf