[dns-operations] renesys blog: Identity Theft Hits the Root Name Servers
paul at vix.com
Tue May 20 18:18:08 UTC 2008
> Or, you permanently lock down a set of provider independent DNS root service
> /32s and /128s (reducing the risk of prefix hijack by someone announcing a
> more specific) in a DNSOP BCP, allowing folks to configure filters to ensure
> announcements for those /32s are blocked and are coming from the "correct"
> ASes. Figuring out how to (securely) change everyone's caching server
> configuration remotely would no longer be an issue.
i guess this would make earthlink's life easier. right now if they intercept
traffic to f-root by injecting a more-specific /32 and /128 into their IGP, we
could go after them for fraud. if there were a well known, un-owned anycast
address for f-root, then they could just shovel their DNS traffic to paxfire
without having to set up a modified name server. and what's more, they'd get
more eyeball hits, since customers could no longer run their own recursive name
servers to avoid the NXDOMAIN remapping.
> My personal view is that root service, which is _unique_ because of the
> bootstrap problem, should NOT be associated with particular organizations
> that provide that service, but rather the address at which root service can
> be found. Renumbering root servers is just too fraught with peril.
i have long fought against root name server renumbering. too many clients
never update their hints. the decision to let ep.net have some control over
the prefixes used by some of the five expansion servers when we went from 8 to
13 was a mistake, clear to me at the time, but other voices said we have to be
able to renumber these things, so let's start with some temporary addresses.
it gives me no pleasure to have been proved right on may 2 2008 that ep.net
should not have had control over these addresses and that we should stop doing
any kind of renumbering of root name servers.
More information about the dns-operations