Skip to Content.
Sympa Menu

netsec-sig - Re: [Security-WG] Re: [NTAC] DNS Serving Stale to the rescue?

Subject: Internet2 Network Security SIG

List archive

Re: [Security-WG] Re: [NTAC] DNS Serving Stale to the rescue?


Chronological Thread 
  • From: David Farmer <>
  • To: Paul Howell <>
  • Cc: "" <>, Akbar Kara <>, Bill Owens <>, NTAC <>, Kim Milford <>, "" <>
  • Subject: Re: [Security-WG] Re: [NTAC] DNS Serving Stale to the rescue?
  • Date: Mon, 6 Nov 2017 10:19:40 -0600
  • Ironport-phdr: 9a23:mcIFmhJIAoQKSUorgdmcpTZWNBhigK39O0sv0rFitYgeL/7xwZ3uMQTl6Ol3ixeRBMOAuqIC07KempujcFRI2YyGvnEGfc4EfD4+ouJSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47xaFLIv3K98yMZFAnhOgppPOT1HZPZg9iq2+yo9ZDeZwZFiCChbb9uMR67sRjfus4KjIV4N60/0AHJonxGe+RXwWNnO1eelAvi68mz4ZBu7T1et+ou+MBcX6r6eb84TaFDAzQ9L281/szrugLdQgaJ+3ART38ZkhtMAwjC8RH6QpL8uTb0u+ZhxCWXO9D9QKsqUjq+8ahkVB7oiD8GNzEn9mHXltdwh79frB64uhBz35LYbISTOfFjfK3SYMkaSHJDUcZfVyJPDICyYZYRAeUdJutXtZXxqkEUoBeiGQWhBuXiwSJIiH/s2q061vwsHw/c0ww+HtIBrWnfotXvO6cIVOC60rPIxijEYvNYwzj98o3IfQ47ofyXQLJwdMzRxVMxGAzYk1WdsIroNC6b2OQKtmiU9etgVeS3hm4gsQFxoz+vxsE2honOgIIZ0EzL+j9hzIYyI920UlR3bsK+H5dIqy6bN5B5Td04Q25yoio11qcJtYa6fCcU1JQnyQTTa/udc4iH5B/oSeWfIS9giX54dr+yiAy+/Euvx+HmS8W51FdHojBbntXQtX0BzwLf5tSDR/dn/Uqs2SyD2x7O5uxEO0w5lK7WJpg8ybAqjJUTq17MHirulUX2kqCWckIk9/Ct6+T7eLrqv4ecOoxuhgH5M6QuhtazAfk9MggIRWSU5/mz1KD78U34RrVFkOE2n7HEvJ3UKskXvK20DgBP3oo+7xuyDi2q3MoEkXQENF5FfQiIj4ntO1HAOvD4CvK/jkyikDhx3fDGO6PuAo/WI3jelbfhe6xx5FBBxwou1dxf/Y5bCqkdIPLvXU/8rMfYAQElPAyp2ebnCcl914MHVWOBDa+UK6fSsV6T5uIzOOmAepUZuDf7K/g5+fHul3k5lkEBfaW3x5cYdm23Huk1a3meNELln9NJMWAVsw46BLjyiFqdXDpXT3e0Q68m4DwnUsSrAZqVFa63h7nU8C6lH5EeSGlcD12WWSPmfp+BVu0kdSeUZMJtj2pXBvCaV4Y92ET250fBwL19I7+Ro3VAuA==

Yes we need to work on resiliency, and I think DNS infrastructure is a good place to start. One shared priority for our community I think should be to get EDU TLD instances directly within the R&E network ecosystem. Then DNS root and other TLDs within the R&E network ecosystem follow that as a priority.

After that I'd like to see something like CIRA's D-Zone, a secondary DNS hosting service with a global footprint, DDOS protected, etc...

Some of the Canadian Regional networks are working closely with CIRA;

  
Maybe Internet2 could work with CIRA to provide this to the US R&E community.  Maybe Internet2 could host several D-Zone servers within the US, just a thought.

Thanks.

On Fri, Nov 3, 2017 at 10:32 AM, Paul Howell <> wrote:

I think this is a timely topic.  Resiliency in the  face of sever disruptions that essentially segment major networks is something we've been discussing inside of Internet2 and began promoting externally as well, doing a presentation at the DHS cyber security table recently on this topic.  As a follow up to the presentation, I'm writing an article for our newsletter that will come out later this month.  I am always interested in working together on this topic, perhaps we could have a security-wg call to discuss further.  Thoughts on that?

 

Regards,

Paul

 

 

From: <> on behalf of Steven Wallace <>
Reply-To: <>
Date: Friday, November 3, 2017 at 10:54 AM
To: Akbar Kara <>
Cc: Bill Owens <>, "" <>, NTAC <>, Kim Milford <>, "" <>
Subject: [Security-WG] Re: [NTAC] DNS Serving Stale to the rescue?

 

My scenario is loss of Internet connectivity. That would include loss of TR-CPS.

 

I think we need to be careful WRT to routes to roots. Roots are anycast, and since most of us local-pref TR-CPS/I2, this could lead to suboptimal DNS requests, both in terms of path used, and concentrating queries to fewer serves. This may already be happening. It would be good for someone to check the I2/CPS routing tables for the root anycast prefixes.

 

steve



On Nov 3, 2017, at 10:48 AM, Akbar Kara <> wrote:

 

Steve,

 

Could we not ask TRCPS to carry routes to root server infrastructure? Or is the assumption that campus has lost TRCPS too!

 

Alternatively, it would be interesting to run quagga on AWS vm (that has a path to commodity) and have quagga vm NAT packets originating from your campus DNS that are destined to external DNS.  Maybe something will break... One could do this test for the cost of a latte 😀

/ak

 

 +1 214-392-2717LEARN NOC: +1 866-647-8728  |  

 


On Nov 3, 2017, at 8:56 AM, Steven Wallace <> wrote:

In some of my uses cases, it ensure the resolver continues to have access to the authoritative name server.

 

For example, caching the TLD entry that points to canvas’s name server (which happens to be hosted in AWS), ensures my resolver is able to refresh its cache for canvas’s domain.

 

steve

 



On Nov 2, 2017, at 9:44 PM, Bill Owens <> wrote:

 

It sounds as though this would solve many problems in your isolated campus scenario, but I wonder about the side effects on providers who load balance by returning different DNS results. It’s not uncommon to see 60-second TTLs in records from cloud providers, sometimes even shorter. I think it is unlikely that the server behind whatever A record BIND decided to stick with would simply go away, but it is possible that server would be overwhelmed by the continuous load from your campus. It might be worth a discussion with your critical cloud providers, if they’re willing to discuss that ‘secret sauce’.

 

Bill.


On Nov 2, 2017, at 11:00 AM, Steven Wallace <> wrote:

It’s going to get better. BIND 9.12 (currently in beta, GA due out end of year?) supports “serve stale” (see: https://tools.ietf.org/html/draft-tale-dnsop-serve-stale-02). Serving Stale Data to Improve DNS Resiliency - does what you’d expect. If the resolver can’t update a cached entry, it responsed with the its current cached entry. BTW, this would have mitigated the October Dyn outage, which left many in the community without access to Box, PayPal, etc., despite the fact that we had working network paths to these service providers.

 

 




--
===============================================
David Farmer              
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota  
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================



Archive powered by MHonArc 2.6.19.

Top of Page