F.ROOT-SERVERS.NET moved to Beijing?

Mon Oct 3 15:20:01 UTC 2011

In a message written on Mon, Oct 03, 2011 at 09:27:46AM -0400, Danny McPherson wrote:
> User Exercise:  What happens when you enable integrity checking in an 
> application (e.g., 'dnssec-validation auto') and datapath manipulation 
> persists?  Bonus points for analysis of implementation and deployment 
> behaviors and resulting systemic effects.

I think this is a (to some on the list) cryptic way of asking "If
all your routes to the server go to someone masquerading, what
happens when you try to validate that data?"  The question being
if you configure your nameserver to validate the root, but don't
get signed answers back will your nameserver refuse to serve up any
data, effectively taking you and your users offline?

The answer should be no.  This is part of why there are 13 root
servers.  If a nameserver is told the root is signed and it gets
unsigned answers from one of the 13, it should ignore them and move
on.  I do not off the top of my head know all the timeouts and
implementation dependant behaviors, but also remember that a up
caching resolver will make approximately 1 query to the root per
day for _valid_ names, but many queries per day for invalid names.
Thus the impact to valid names should be minimal, even in the face
of longer timeouts.

Is there enough operational experience with DNSSEC?  No.  Can we
fix that by saying it's not good enough yet?  No.  Run it.  The
people who write nameserver software are comitted to fixing any
issues as quickly as possible, because it is our best way to secure
DNS.

> Network layer integrity techniques and secure routing infrastructure are 
> all that's going to fix this.  In the interim, the ability to detect such 
> incidents at some rate faster than the speed of mailing lists would be
> ideal.

Network layer integrity and secure routing don't help the majority of
end users.  At my house I can choose Comcast or AT&T service.  They will
not run BGP with me, I could not apply RPKI, secure BGP, or any other
method to the connections.  They may well do NXDOMAIN remapping on their
resolvers, or even try and transparently rewrite DNS answers.  Indeed
some ISP's have even experimented with injecting data into port 80
traffic transparently!

Secure networks only help if the users have a choice, and choose to not
use "bad" networks.  If you want to be able to connect at Starbucks, or
the airport, or even the conference room Wifi on a clients site you need
to assume it's a rogue network in the middle.

The only way for a user to know what they are getting is end to end
crypto.  Period.

As for the speed of detection, its either instantenous (DNSSEC
validation fails), or it doesn't matter how long it is (minutes,
hours, days).  The real problem is the time to resolve.  It doesn't
matter if we can detect in seconds or minutes when it may take hours
to get the right people on the phone and resolve it.  Consider this
weekend's activity; it happened on a weekend for both an operator
based in the US and a provider based in China, so you're dealing
with weekend staff and a 12 hour time difference.

If you want to insure accuracy of data, you need DNSSEC, period.
If you want to insure low latency access to the root, you need
multiple Anycasted instances because at any one point in time a
particular one may be "bad" (node near you down for maintenance,
routing issue, who knows) which is part of why there are 13 root
servers.  Those two things together can make for resilliance,
security and high performance.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111003/fb7fad0f/attachment.sig>