[dns-operations] renesys blog: Identity Theft Hits the Root Name Servers

[Daniel Karrenberg]

On 23.05 10:06, David Conrad wrote:
> [I had promised myself and others I wouldn't post on this topic  
> further.  I am breaking that promise because I believe Daniel is  
> trying to obfuscate a sucking chest wound in the Internet architecture  
> with platitudes and handwaving.  I'm weary of it.  This will be my  
> last post as I will be filtering out this subject line in the future.]

[Oh nice. Asking for wanswers but saying "I will not read them" is just 
such a great motivation to answer.  I'll give the answers anyway.]

> On May 23, 2008, at 1:15 AM, Daniel Karrenberg wrote:
> >We have independent, clearly defined, open and transparent  
> >governance processes for this.
> 
> Can you provide me with the URL where these processes clearly defined?

Sure:  

RIPE NCC Articles of Association 
	http://www.ripe.net/ripe/docs/articles-association.html
RIPE (Open Forum)
	http://www.ripe.net/ripe/about.html
Relevant RIPE WG charters
	http://www.ripe.net/ripe/wg/ncc-services/index.html
	http://www.ripe.net/ripe/wg/dns/index.html


Additional information:

K Operations
	http://k.root-servers.org/
RIPE NCC Activity Plan 2008
	http://www.ripe.net/ripe/docs/ripe-426.html


> Could you point me to your published service level guarantees?  

The RIPE NCC has  said repeatedly and publicly that we will do what it takes 
and we will be responsive to our governance process *and* to the Internet 
community as a whole.

We have also committed to adhere to all relevant best practises
such as RFC2870/BCP40. In fact we have contributed to that work.

The RIPE NCC does not have service levels spacified in nmeasurable
terms.  Toouche there.  But it is not for lack of trying.  Defining hard
service levels is not as as straightforward as you imply.  So what would
be reasonable?  Please make suggestions taking into account
multicasting, deliberate attacks, ... .

Let me also point out that the RIPE NCC "invented" and deployed the first
comprehensive measurement of the quality of DNS root name servers:

http://dnsmon.ripe.net/

This data has always been publicly available to anyone. I am certainly biased
but I firmly believe that just collecting and publishing this data has done
at least as much for the service quality of DNS root name servers than 
any contractual arrangements or bi-lateral service guarantees could have done.

> How  
> about the mechanisms, including penalties, that would encourage you to  
> remedy the situation in the event that RIPE-NCC does not live up to  
> those service metrics?  

The RIPE NCC is goverened and guided by the RIPE community and its members. 
That works quite well in this regard. See the Articles and
refer to the history. 

> How about your policies or statements about  
> not modifying root zone data as it is presented to the root servers?   

Oh boy, we have said that so many times. Which particular version do you want?

I say it again here, publicly: We will take the data from the IANA and publish it
unmopdified. We fully share the views expressed by the Internet Architechture 
Board in RFC2826.

> A statement about non-discriminatory access (e.g., refusing to serve  
> requests from a particular community)?  

Oh boy, we have said that so many times. Which version do you want?
The latest L9 cleared instantiation goes like this:

"Through k.root-servers.net, the RIPE NCC
publishes the DNS root zone to Internet users in a non-discriminatory
fashion, following the relevant technical standards and best
practises, and in accordance with its governance processes."

> How would, say, a TLD operator  
> who had operational issues because a root server failed to update  
> their zone in a timely manner (which has occurred on several occasions  
> when I was at IANA) go about getting compensated for lost business or  
> costs?

See the articles of association and the company registration.
There are Dutch courts available with suitable escalation 
and due process. 

Side note: this is equivalent to the recourse the same TLD operator has
against delays caused by the IANA and the root zone editing
process which in my reality have been much more significant than
the delays that sometimes occur in the publication process. 

All proposed and executed agreements in this area that I have seen
were actuually designed to deflect such liabilities and the first
thing all lawyers add are mutual "hold harmless" clauses. So while
I am not a lawyer and I do not play one on TV, I consider this 
the biggest and reddest herring of them all.

> >my erception of your line of reasining is that centralised control by
> >ICANN may look more convenient to you and that you support the efforts
> >of ICANN to implement such control through contracts or through ICANN
> >having authority over the IP addresses of the root name servers.
> 
> I will point out again that no where have I stated that I believe  
> ICANN should have contracts or centralized control (in fact have  
> suggested the opposite).  This is a very tired old red herring.

It is not. My argument is not about ICANN in particular but about 
*any* central authority that holds too much power about the root.
ICANN currently is the one that has said publicly that it wants it
and a lot of people assume that ICANN should have it without much 
thought. So that is why it is a convenient example to make my points
and everyone can relate to it. My argument however is about division of 
responsibilities, accountability and "power".


> If you actually read what I wrote, I am arguing that the IP addresses  
> for the root servers be fixed by the IETF (not ICANN).  I specifically  
> did not raise the topic of how an organization would be disassociated  
> or (re-)associated with one of the IETF-defined "golden" root server  
> address as I pointed out that is a layer-9 issue.  I did not say that  
> ICANN would even have a role in that disassociation/(re-)association  
> process.
> 
> The reaction from individuals within the root server community to this  
> suggestion is treating it as a threat or to attack me personally as  
> being on a "warpath" or engaging in "dismissive derisive sarcasm".  As  
> I said, this is not unexpected -- historically, any attempt to change  
> the status quo in a monopolistic system results in remonstrations that  
> everything is working fine the way it is (despite evidence to the  
> contrary), complaints of ulterior motives, FUD-spreading, etc.  Seen  
> it in the telco world and other businesses, it isn't too surprising to  
> see it here.

See above. Please solve the problem of who is the registered user of
those golden addresses and who determines that fact. 

> "Past behavior does not guarantee future performance."

Right.  But centralisation of function guarantees problems with
performance and scaling.  That is is one of the lessons the Internet has
taught us. 

To explain: Where would we be with anycast deployment if there had been
a central point of authority and acountbility that had to make a
decision for the whole root name server system?  Hint: Look at what it
took to add some AAAA records to the root zone, a change much more
straightforward by orders of magnitude.  Anyone responsible for all the
eggs *has* to be more conservative and less flexible than a distributed
system. 

> I would agree that operation has evolved.  Heck, I remember when the  
> root servers weren't anycast (and your arguments that everything was  
> fine back then too).  

Excuse me.  The two concerns with anycast which I voiced were the added
cost and difficulty for an operator to guarantee quality and consistency
in a widely distributed configuration and *the increased difficulty to
get ISPs to effectively support preventing route hijacks*.  This second
issue is the very problem that is at the start of this thread.  This is
on record.  Also let me remind you that K was indeed one of the first
letters to deploy anycasting and we have done so in a careful and
professional way.  Not all letters are currently anycast, nor should all
of them be. 

> I would be very interested in seeing how you  
> might justify the statement that "governance has evolved  
> successfully."  You appear to be saying "the root server operators  
> work fine, except when they don't and everything is open, transparent  
> and accountable, except when it isn't.  So everything is good and  
> nothing needs to change."  I find this sad.

The governance witin RIPE and the governance and constitution of the
RIPE NCC have certainly evolved.  See the references above.  I cannot
speak for others but if you find anything wrong with K governance, let
us hear it. 

If you find anything wrong with any root server operator's operations
or governance tell them. I have very good experiences with influencing
things for the better by doing just that, privately.  I have considered 
going public or taking public action in a few instances but never had 
to so far.

> In any event, when I responded to this thread, I was under no illusion  
> that anything would actually change.  Even if the IETF were to come  
> out with a "golden" root server address RFC, I am certain you and  
> others would refuse to abide by it, coming up with some platitude- 
> filled rationalization.  And there is nothing short of US government  
> intervention that could actually be guaranteed to do anything about  
> that.

US government intervention would be destabilising to the extent of severly
hurting US interests. While there are notable exceptions, the US government 
is in general acting rationally. So I do not expect direct interventions 
here, definitely not based on what we have heared so far.

> Now that's irony.

Yes indeed, but I suspect a whole different kind to me.

We just disagree on the fundamental thing:

I firmly belive that DNS root name server operations need to remain
de-centralised at the governance level because adding more
centralisation will at best not improve service quality and at worst
severly degrade service quality and make the whole DNS susceptible to
failure or capture.  The deficienceies caused by this de-centralised
arrangements are a far lesser evil than the potential benefits of
centralised control.

If there improvements are needed with operations or governenance
of individual root name server operators, let us work for these
improvements. Bringing them all under a central authority will not
achieve that either.

David,

While we have this fierce and seemingly continuous argument I respect
you personally and your achivements very much.  So noone should take
this to be a personal thing in any way. 

Daniel