netsec-sig - Re: [Security-WG] Re: [NTAC] DNS Serving Stale to the rescue?
Subject: Internet2 Network Security SIG
List archive
- From: David Farmer <>
- To: Steven Wallace <>
- Cc: , Akbar Kara <>, Bill Owens <>, NTAC <>, Kim Milford <>, "" <>
- Subject: Re: [Security-WG] Re: [NTAC] DNS Serving Stale to the rescue?
- Date: Fri, 3 Nov 2017 14:49:52 -0500
- Ironport-phdr: 9a23:ZUEy1RQeqrx6dHfH9ztY/wopedpsv+yvbD5Q0YIujvd0So/mwa6zYxKN2/xhgRfzUJnB7Loc0qyN4vCmATRIyK3CmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TW94jEIBxrwKxd+KPjrFY7OlcS30P2594HObwlSijewZbB/IA+qoQnNq8IbnZZsJqEtxxXTv3BGYf5WxWRmJVKSmxbz+MK994N9/ipTpvws6ddOXb31cKokQ7NYCi8mM30u683wqRbDVwqP6WACXWgQjxFFHhLK7BD+Xpf2ryv6qu9w0zSUMMHqUbw5Xymp4rx1QxH0ligIKz858HnWisNuiqJbvAmhrAF7z4LNfY2ZKOZycqbbcNgHR2ROQ9xRWjRDDYOyb4UBAekPM/tGoYbhvFYBtweyCBO2Ce/z1jNFhHn71rA63eQ7FgHG2RQtEdwUv3TKrdX6KboZX+Cvw6nSyDXMcelW0ir65YjGaB8hu/SMUqxqccfK1EkvEgXFgk+OpoP4IjOYz+IAuHWV4epnUOKgkW8nqwdprzix2MgskIjJhpkUylDL8yV5wYA1KsGiREFnZt6kFYNcty6dN4txTcMiR39ntDwmxb0BvJ63ZCYKyJM9xxLFd/OHdI2I7gr5W+aXPDh0nnRld6yjhxqq8Eig0fHzWtOz0FZQoSpJisPMtncK1xzP88SHUeVy/l2/2TmRzQDT8ftIIUcularUM5Ihw6A/loYdsUjZGS/2gkr2gLeXdko44Oeo7eLnbq/hpp+GOI94khn+PbgumsClB+Q3LBQOU3CB+eS9zL3s41f1QLNUgf0qlKTSrZPUJdwDq6KkDQJY3Zwv5hWwAju8zdgVmXgKIEhbdB6bjIXlI0/CLOz8APulgFmhkC1ny+7bMrDhGJnALGXPnbH8drhn8UFc0hA8zdVH6pJUFL4BJPXzV1f0tNzEFBA1KhS0zuX9BNV614MeRXiDArKcMKPUq1OH+P8gI/SUaI8UvjbyNeQl6ubzgXI3llIRZ6qk0JQNZHylGvlrIl+VbWTwjtoCCWsKuxAxTO3uiF2MSz5TYHOyUroy5j4hEoKmCJnMRpq2jbyc2Se7GIdaaX5bBVCRCXvobZmLW+8QaCKOJc9siicEWqa9RI88zxGutRP6yrp+Iuva9S0Vrpbj1Nlu5+3PjhE+6yZ4D8Wb02GRUW50hGUISCEq3Kxhu0By1EqM0bUry8BfQOdP6u1EVE8FPJrYxud3Q4TpQR3pf8rPRVq7FIaIGzY0G/443d4CK2h0AdCvlFiX0SOwBrIPv6GOAto5/r+KjCu5HNp013uTjPpptFIhWMYacDT+3qM=
I don't disagree, but I was looking for low hanging TLD fruit so to speak. Which as I know of, is COM and Net with a J-root instance, the the CC TLDs hosted by PCH, everything else will be much more complicated, but I'm not implying they are not important.
I wonder if we could get Educause and Verisign to host EDU on some J-root instances within the R&E network.
--
Thanks
On Fri, Nov 3, 2017 at 11:45 AM, Steven Wallace <> wrote:
IMO, we’ll need .us (zoom), .edu, .org. net, .us, too.On Nov 3, 2017, at 12:34 PM, David Farmer <> wrote:On Fri, Nov 3, 2017 at 11:19 AM, Steven Wallace <> wrote:I second this. We’ve been approved to host a RIPE root. Very straightforward. Our cost, small server, space, power…they manage it.Should we host some of the TLDs too?Verisign's RIRS includes a local TLDs for .COM and .NETPacket Clearing House hosts several CC TLDs, see;They will provide nodes at Internet Exchanges, we are looking at one for MICE.For much of this it is probably best to talk to people at NANOG, and the Peering Personals.For example Verisign had a table at the last Peering Personals.On Nov 3, 2017, at 12:14 PM, David Farmer <> wrote:As for root issues; Getting a local anycast root provided by one of the root providers is not that hard and probably a service each of us can provide to our regional communities. Especially if you are local peering or have a local internet exchange in your region. I'm looking at hosting one or two, along with the F-root already hosted by Cloudflare in Minneapolis.For the map of root server see and their anycast nodes see;Ensuring there is at least 1 anycast node in your state or major metro area is probably a reasonable goal, and larger metro areas probably more that one,Also, since the root zone is now DNSSec signed you can download a signed copy of the root zone and set up your own private root server for internal use and know you have authoritative information.On Fri, Nov 3, 2017 at 9:54 AM, Steven Wallace <> wrote: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.steveOn 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 😀
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.steveOn 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
=============================================== --===============================================
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
===============================================
===============================================
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
===============================================
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
===============================================
- [Security-WG] Re: [NTAC] DNS Serving Stale to the rescue?, (continued)
- [Security-WG] Re: [NTAC] DNS Serving Stale to the rescue?, Steven Wallace, 11/03/2017
- Re: [Security-WG] Re: [NTAC] DNS Serving Stale to the rescue?, David Farmer, 11/03/2017
- Re: [Security-WG] Re: [NTAC] DNS Serving Stale to the rescue?, Steven Wallace, 11/03/2017
- Re: [Security-WG] Re: [NTAC] DNS Serving Stale to the rescue?, Paul Howell, 11/03/2017
- Re: [Security-WG] Re: [NTAC] DNS Serving Stale to the rescue?, David Farmer, 11/03/2017
- Re: [Security-WG] Re: [NTAC] DNS Serving Stale to the rescue?, David Farmer, 11/03/2017
- Re: [Security-WG] Re: [NTAC] DNS Serving Stale to the rescue?, Steven Wallace, 11/03/2017
- Re: [Security-WG] Re: [NTAC] DNS Serving Stale to the rescue?, David Farmer, 11/03/2017
- Re: [Security-WG] [NTAC] DNS Serving Stale to the rescue?, Steven Wallace, 11/03/2017
Archive powered by MHonArc 2.6.19.