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

[Edward Lewis]

At 14:25 +0100 5/22/08, Simon Waters wrote:

>Was "believed to be coherent". I'm sure it was, but no one can prove it since
>any rogue root operator could serve different data to different addresses.

Given the absence of any claim, proof, or indication of incoherent 
answers, I'd stick with "was coherent."  As you say later, clarity 
regarding the problem to be solved is important - so "expanding" the 
accusations to say only believed to be coherent is leading to less 
clarity.

Unless someone actually has factual knowledge that there were 
incoherent responses.  Anyone?

>But it depends whether you think the "incident" is people asking a server that
>they shouldn't because it is removed (due to poor maintenance of their root
>hints - I suspect I'm guilty here since my preferred OS release cycle is
>slower than the 6 month announcements - or broken DNS resolvers), or that
>they accepted and believed the answers they received uncritically.

The incident is that someone stood up a server and, without full 
agreements, answered as if the address had not been decommissioned. 
("Without full agreements" means that at least one part of the 
equation was unhappy about what happened.)  To me, what is bothersome 
is that although this incident is apparently regrettable there is no 
paper trail to allow for public review that there "was a problem 
here."  Without rules being recorded there is no way for peers to say 
"yes, the rules were broken."

That people still asked is not the incident, that happenstance is a given.

>I think folks need to be clear what problem they are trying to solve. I was
>trying to address the how we know answers purporting to be from root (or
>hints) servers aren't lying issue. Which is different from stopping things
>purporting to be root servers (or stopping things intercepting or forging
>traffic from root servers). I'd argue this is probably the most useful
>problem to solve, especially if it generalises to other zones.

Certainly end-to-end security is more encompassing than protecting 
the publication mechanism.  That is what DNSSEC set out to do.  (More 
encompassing might also mean higher cost, so it is not always better.)

>I said encryption not DNSSEC. I don't know enough about the details of DNSSEC
>to say if it would fix a case of a rogue server in a root hints, since I
>don't know how it establishes the trust of "." initially. I assume to do this
>securely there would need to be some sort of out of band verification of the
>key signing the root zone.

I'd like to see a DNS security mechanism based on the use of 
encryption that is an alternative to DNSSEC and is an improvement on 
DNSSEC.  Over the years, there have been other attempts to do this, 
each, of those I became aware, faded away into academic oblivion. 
This is why I equate "DNS with encryption" and DNSSEC.


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.