Internet2 Network Security SIG

[Karl Reuss <>]

Access to the DNS root shouldn't be a problem these days.  Root servers use 
anycast from over 1000 locations and
most ISPs have good peering them.  Through our partnership with PCH.net, UMD 
has d.root-servers.net in 153 locations.  Using latency to evaluate access to 
DNS servers is more important than physical location, AS path or router hops. 
 If you are really concerned about the root there is RFC7706 (Decreasing 
Access Time to Root Servers by Running One on Loopback), see 
https://localroot.isi.edu/ for an implementation. 

Just as important as access to the root is access to servers for the TLDs you 
care about, e.g. Verisign for .edu.  I believe [a-m].edu-servers.net also use 
anycast globally and have great connectivity. 

-Karl



On 12/5/19 3:25 PM, Andrew Gallo wrote:
> I'll share a recent effort I completed mapping out how we get to the root 
> name servers.  I only focused on the roots; I realize that in order to 
> resolve a name, you have to traverse more servers, but just as a first look 
> at how we're connected to critical infrastructure, I found this informative.
>
> I mapped out our paths to each of the roots (see two attached graphviz 
> graphs) and also counted the number of 'exit' points (number of physical 
> exit points, and number of 1st hop ASNs- we have a lot of bi-lateral peers 
> reachable via a peering switch).
>
> I'd say, we're pretty well positioned for access to the roots.
>
> I'd be happy to discuss my methodology, and how others might use the script 
> I wrote.
>
> Thanks.
>
>
> On 12/5/2019 11:12 AM, Steve Wallace wrote:
>> Greetings NTAC & Security-WG,
>>
>> We’ve heard from a number of community members the desire to leverage the 
>> Internet2 infrastructure to improve the robustness of DNS. I’d like to 
>> suggest that the NTAC and/or Security-WG consider convening motivated 
>> stakeholders to advance this idea. As a placeholder, I’ve created a 
>> high-level description. The google docs link will allow anyone with the 
>> link to comment. I’m happy to carry water, to help organize, coordinate, 
>> etc.
>>
>> Grateful for responses to the following:
>>
>> Is this on-target? If not, how should it be changed?
>> How can I2 staff best move this forward?
>>
>> Thanks,
>>
>> Steve
>>
>>
>> https://docs.google.com/document/d/1sV1JVDwRilAfmizq-wi52JsoMLX-vyw2mFA5GF4aoIE/edit?usp=sharing
>>
>> DNS Resilience Initiative
>>
>> Purpose
>> This initiative's goal is to improve the Internet2' community's DNS 
>> resiliency.
>>
>> Background
>> DNS is a crucial component of basic Internet connectivity. Due to its 
>> distributed nature, when the Internet is fully functioning, DNS service is 
>> typically rugged and resilient. However, during a partial Internet 
>> failure, DNS may fail in unexpected ways. Frequently the connectivity 
>> requirements of DNS differ from those of an application or service.
>>
>> For example, a campus's ability to use Canvas (a popular learning 
>> management system hosted in the AWS cloud), requires network connectivity 
>> to AWS *and*  the DNS servers for root, dot.com, and instructure.com.
>>
>> Approach
>> DNS resiliency depends-on campus deployment practices and connectivity to 
>> the hierarchy of external DNS servers. Through this initiative, we'll 
>> collect and share campus deployment practices, as well as identify 
>> opportunities to improve the connectivity to the DNS hierarchy made 
>> possible by leveraging the Internet2, regional, and campus networks.
>>
>>