[145282] in North American Network Operators' Group
Re: F.ROOT-SERVERS.NET moved to Beijing?
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Mon Oct 3 11:21:24 2011
Date: Mon, 3 Oct 2011 08:20:01 -0700
From: Leo Bicknell <bicknell@ufp.org>
To: NANOG list <nanog@nanog.org>
Mail-Followup-To: NANOG list <nanog@nanog.org>
In-Reply-To: <90B0DD58-41CC-4113-BD9C-42CD02FAA771@tcb.net>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--PNTmBPCT7hxwcZjr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In a message written on Mon, Oct 03, 2011 at 09:27:46AM -0400, Danny McPher=
son wrote:
> User Exercise: What happens when you enable integrity checking in an=20
> application (e.g., 'dnssec-validation auto') and datapath manipulation=20
> persists? Bonus points for analysis of implementation and deployment=20
> 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=
=20
> all that's going to fix this. In the interim, the ability to detect such=
=20
> 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.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--PNTmBPCT7hxwcZjr
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iQIVAwUBTonSobN3O8aJIdTMAQL5gg/9EGZwrcNknrjJk2+RRJEVCM4P16mmvg3v
clYUmJ0i3vUmP+ETMLp8DjNwszjvIRXvS1tXzYSCjZwR7GQPVGTWFHAgKcrqNVms
3ZDOg8fsw2B6Mi+mKG3yP1edeT06xy13hGnPj66XgVzw3K1Q8DY2OxRJeuc2XrBZ
p7jM8CwcfW4G4chMIeo88zaaAol6IJ+U/QOL0J+5/3eQOcyUte03BbNe9yiPvDZz
mtlUEpCaIEr/Y998Zd9oIFn3eIhzMrb0mU2FEl4oMpGXlnRAGk8QFTjHFhd0snA6
oOuxeFOgyqsr1CIX9c+S5JvemOcdjouyqdRsz4ZGEXaG9UPwB9ciMYSXzVFHJ9Nn
NNULs/Wequb/DHquXgOcOaF46BdHi/5HanWhgvrQ8EAR6TPmfg/pxP0v7xX18Zwt
Kf2+qeZpUnMTMdrlzv8nhX1n5FcdQgxFoNdrUgmOI2bXKqv9qjqTcNvJ5zGry5zo
K5MQBxf8cMxr0Mgmu/OltRFQ8YDHYmXZw54bgFA7aQmG+g/B0W6asvL5cHVogGk4
188fKaERqWAKbEgws6RvIbZOw7KkyTMGXLTwVgL550vGx9U30g67Vn1Zsb/Nt0GD
t+Ma/Qg+gDBCwYDSY0w/t41dUkwAN/4HalfDaH4U5/LiELp2tuvDa7FO3OVWPV6n
yjYFVuUBv4Q=
=peaz
-----END PGP SIGNATURE-----
--PNTmBPCT7hxwcZjr--
