|
||
|
||
The folks at Renesys pointed out earlier this week some interesting activity surrounding the L-root name server, highlighting some activity that should give us all yet another reason to be concerned about the security and integrity of the Internet DNS.
In short, L-root, operated by ICANN, was renumbered from 198.32.64.12 to 199.7.83.42. ICANN renumbered L-root into this 199.7.83.0/24 space after being allocated a “critical infrastructure” address block from ARIN, the old 198.32.64.0/24 block belongs to Bill Manning and ep.net. ICANN announced their intentions to renumber over six months ago, and stopped using the old address space for the authentic L-root on May 2.
Since ICANN (AS 20144) announced their intentions to stop using the old address space, three other networks (Community DNS, ep.net & Diyixian.com) have asserted reachability for that old address space. Normally, that wouldn’t be such a big deal, as name servers on the Internet that hadn’t yet picked up an updated root hints file would simply query the old IP, receive no response, and move on to another root. However, not only did these three networks assert reachability for the old address space, they were actually fielding DNS queries targeted to the root, and replied to the querier. All data presented to date seems to suggest that the responses they were providing were legitimate, but to me that’s all together a different issue.
However, considering that a great deal of malware today tends to corrupt the DNS resolution path [PDF] in order to further exploit compromised end-systems, and that corruption, or any other actual end-system compromise, might well be unnecessary if the root were compromised—well, think of the possibilities!
The root DNS infrastructure is extremely resilient and well distributed, in part because of anycast and local instances of various root servers, and this is a good thing, IMO. However, the fact that I might initiate a DNS query that would find its way up the DNS tree to the root, and AN L-root resolver responds, and that L-root might not be the legitimate L-root, well, that should give every user on the Internet great reason for alarm, certainly those that are security-minded.
I trust ICANN and RSSAC will put new safeguards in place to ensure that these activities are detected much more quickly in the future (for all roots), and that they will also work on plans that both help avoid renumbering of roots, and monitoring of existing and old root address spaces (for both DNS queries and distributed Internet routing system state) to detect these sorts of threats. ICANN should also consider a more far-reaching mechanism for notification of root IP address changes (I’m not sure a blog post alone is considered reasonable, although I’m not aware of other methods that may have been employed to make folks aware of this critical change). Folks that do flow-based or other network transaction monitoring should ensure that you don’t have DNS transactions targeting or sourced from old root address spaces. In addition, wrapping some contractual or legalese around these old address spaces to prohibit this type of activity (for whatever the incentive) would seem prudent.
Sponsored byRadix
Sponsored byDNIB.com
Sponsored byCSC
Sponsored byWhoisXML API
Sponsored byVerisign
Sponsored byIPv4.Global
Sponsored byVerisign
A World-Renowned Source for Internet Developments. Serving Since 2002.
Hi Danny,
Your post seems particularly defensive - based on the assumption of mal-intent. Root Server operators have (todate) operated based on the presumption that we all serve the same data. Some operators use contractors, some keep everything in-house. A hallmark of root service operations has been diversity. This is no different.
Taking the ICANN party line, that no renumbering in the future, turning some address spaces into very attractive targets for bad guys - seems hardly prudent or reasonable. Even the IAB has made public statements about the inadvisability of single points of failure.
And then you close with a plea to not take data to try and understand WHY these old addresses still get queries. No one knows why and yet you argue that we should be prevented from looking. Or am I reading your post incorrectly?
—bill
Bill, glad you commented here, let share some additional thoughts and I’d love to get any clarification you might provide on the questions below.
For starters, I’m a huge fan of diversity. I believe that the diversity of root operators is a huge positive. However, I personally believe there’s much room for improvement of transparency and accountability for root operators.
————
Some questions specifically related to this that only you can answer:
Why did ICANN renumber L root into their own address block, from a /24 that was part of a /16 “Exchange Point” address block that was initially allocated to you (by Jon Postel?) for sub-allocations to NAPs and other exchange points?
I noticed that 198.32.0.0/16 had the registration changed at some point from “Exchange Point Blocks” to “EP.NET LLC”, why was that? Is this block being used for EP.NET LLC commercial purposes or just sub-allocations of exchange point subnets and other related Internet experiments?
Did you enter into a contract with CommunityDNS to announce the space AND respond as a root server (AA bit et al)? Why?
What was in it for CommunityDNS, why would they want to do such a thing?
What was the timeframe between when ICANN announced the new address for L root with a six month transition plan and when CommnityDNS began announcing into BGP and responding authoritatively to root queries directed to the old address? Was it months, weeks, or days after the ICANN notice was published?
Why was ICANN seemingly surprised by this, is there no formal communications and policies for renumbering a root? It’ll be years before everyone has properly updated root hints files, surely, root operator transitions should be coordinated in some manner that’s open, documented, and best serves the Internet community.
It’s one thing to collect data for measurement, it’s an entirely different thing to respond authoritatively (to respond at all, for that matter) to queries - especially in a world where things like compromised DNS query resolution paths are a huge source for enabling nefarious actives on the Internet, as you’re well aware.
————
General questions that come to mind:
If root operators don’t meet service level agreements (is there such a thing?) who’s accountable? If they don’t invest enough in infrastructure, or bandwidth, or security, who’s accountable? If they don’t monitor the routing system to identify hijacked routes associated with the roots they operate (which can certainly be more localized with the advent of anycast), who’s accountable?
Do root operators do anything with data like NXDOMAIN queries? Do they sell it? What prevents this? Is there any auditing of data use, or network and security associated with operating roots? Are the results of those audits publicly available?
Should root operators be announcing /24s from dedicated critical infrastructure blocks, or allow the root servers to be numbered from an existing /16 (e.g., D root), or any address space that doesn’t allow the roots to be moved to a new operator without renumbering? It’d seem not having dedicated blocks for roots would “hold them hostage” to the root operators address blocks, no? What about anycast, are there any hard requirements for that or the associated number of instances, etc..
Some might argue that this “root operator franchise” isn’t in the best interest of the Internet community. From where I sit, this incident would only seem to amplify an already ugly situation with ICANN, Internet governance, et al, and rightly bring about concern from the Internet community, and in particular those watching from Iran, India, Russia, China, Saudi Arabia, etc… How do you respond to that?
-danny (speaking only for myself)
Bill Manning said:
Bill, glad you commented here, let share some additional thoughts and I’d love to get any clarification you might provide on the questions below. Apologies for the duplicate comment below, I wanted this tracked correctly so I added it here as well.
For starters, I’m a huge fan of diversity. I believe that the diversity of root operators is a huge positive. However, I personally believe there’s much room for improvement of transparency and accountability for root operators.
————
Some questions specifically related to this that only you can answer:
Why did ICANN renumber L root into their own address block, from a /24 that was part of a /16 “Exchange Point” address block that was initially allocated to you (by Jon Postel?) for sub-allocations to NAPs and other exchange points?
I noticed that 198.32.0.0/16 had the registration changed at some point from “Exchange Point Blocks” to “EP.NET LLC”, why was that? Is this block being used for EP.NET LLC commercial purposes or just sub-allocations of exchange point subnets and other related Internet experiments?
Did you enter into a contract with CommunityDNS to announce the space AND respond as a root server (AA bit et al)? Why?
What was in it for CommunityDNS, why would they want to do such a thing?
What was the timeframe between when ICANN announced the new address for L root with a six month transition plan and when CommnityDNS began announcing into BGP and responding authoritatively to root queries directed to the old address? Was it months, weeks, or days after the ICANN notice was published?
Why was ICANN seemingly surprised by this, is there no formal communications and policies for renumbering a root? It’ll be years before everyone has properly updated root hints files, surely, root operator transitions should be coordinated in some manner that’s open, documented, and best serves the Internet community.
It’s one thing to collect data for measurement, it’s an entirely different thing to respond authoritatively (to respond at all, for that matter) to queries - especially in a world where things like compromised DNS query resolution paths are a huge source for enabling nefarious actives on the Internet, as you’re well aware.
————
General questions that come to mind:
If root operators don’t meet service level agreements (is there such a thing?) who’s accountable? If they don’t invest enough in infrastructure, or bandwidth, or security, who’s accountable? If they don’t monitor the routing system to identify hijacked routes associated with the roots they operate (which can certainly be more localized with the advent of anycast), who’s accountable?
Do root operators do anything with data like NXDOMAIN queries? Do they sell it? What prevents this? Is there any auditing of data use, or network and security associated with operating roots? Are the results of those audits publicly available?
Should root operators be announcing /24s from dedicated critical infrastructure blocks, or allow the root servers to be numbered from an existing /16 (e.g., D root), or any address space that doesn’t allow the roots to be moved to a new operator without renumbering? It’d seem not having dedicated blocks for roots would “hold them hostage” to the root operators address blocks, no? What about anycast, are there any hard requirements for that or the associated number of instances, etc..
Some might argue that this “root operator franchise” isn’t in the best interest of the Internet community. From where I sit, this incident would only seem to amplify an already ugly situation with ICANN, Internet governance, et al, and rightly bring about concern from the Internet community, and in particular those watching from Iran, India, Russia, China, Saudi Arabia, etc… How do you respond to that?
-danny (speaking only for myself)