Subject: [DNSOP] Fwd: I-D Action: draft-pappas-dnsop-long-ttl-04.txt

From: Eric Osterweil <[email-masked]>
Date: Fri, 2 Mar 2012 09:56:40 -0800

Hey everyone,

We have resurrected our draft Improving DNS Service Availability by Using Long TTL Values, and added some new polish to it.  We've taken some feedback from various people and would love to hear any thoughts other people have.

Thanks!

Eric

Begin forwarded message:

> From: [email-masked]
> Date: February 23, 2012 7:57:30 AM PST
> To: [email-masked]
> Subject: I-D Action: draft-pappas-dnsop-long-ttl-04.txt
> Reply-To: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Improving DNS Service Availability by Using Long TTL Values
> 	Author(s)       : Vasileios Pappas
>                          Eric Osterweil
> 	Filename        : draft-pappas-dnsop-long-ttl-04.txt
> 	Pages           : 17
> 	Date            : 2012-02-23
> 
>   Due to the hierarchical tree structure of the Domain Name System
>   [RFC1034][RFC1035], losing all of the authoritative servers that
>   serve a zone can disrupt services to not only that zone but all of
>   its descendants.  This problem is particularly severe if all the
>   authoritative servers of the root zone, or of a top level domain's
>   zone, fail.  Although proper placement of secondary servers, as
>   discussed in [RFC2182], can be an effective means against isolated
>   failures, it is insufficient to protect the DNS service against a
>   Distributed Denial of Service (DDoS) attack.  This document proposes
>   to reduce the impact of DDoS attacks against top level DNS servers by
>   setting long TTL values for NS records and their associated A and
>   AAAA records.  Our proposed changes are purely operational and can be
>   deployed incrementally.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-pappas-dnsop-long-ttl-04.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-pappas-dnsop-long-ttl-04.txt
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 7 Mar 2012 18:06:30 -0500

Hey list,

So far, we have not gotten a huge amount of feedback on this draft (but thank you _very_much_ to those that have responded).  I think we were really hoping that people could take a look at the draft and comment before Paris.  It focuses on how resolvers that query large TLD registries can maintain connectivity during sustained outages at the root (such as from DDoS attacks). While it may seem topical to some, we were hoping that some of the distinctions and practices in this draft would be useful in general (such as the distinction of Infrastructure RR types).

We would all very much appreciate any feedback from the list, thanks!

Eric

On Mar 2, 2012, at 12:56 PM, Eric Osterweil wrote:

> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Hector Santos <[email-masked]>
Date: Wed, 07 Mar 2012 18:26:57 -0500

Hi Eric, the only thing that came to mind was that we already have 
recommended TTL values and yet, it is highly abused with short values. 
  I did not read the draft yet, but does it touch base with how to 
control it or enforce a longer TTL?

I say that based on a last year project to single source our DNS 
resolver for an integrated system that was beginning to expand using 
different DNS resolvers and APIs and there was a growth of query 
duplicity with different caching, including round robin or lack there 
of.

TTL/Caching was its anchor for reissuing queries to optimize it and 
one of the immediate highlight was the huge amount of low TTLs.  What 
does disseminate or discriminate these?

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 8 Mar 2012 10:24:58 -0500

Hey Hector,

Thanks for the comments, I've tried to address them inline:

On Mar 7, 2012, at 6:26 PM, Hector Santos wrote:

> Hi Eric, the only thing that came to mind was that we already have recommended TTL values and yet, it is highly abused with short values.  I did not read the draft yet, but does it touch base with how to control it or enforce a longer TTL?

Rather than place an enforcement tone on the problem, the analysis is based on observing the benefits that a zone (and its resolver clients) get from acting this way.  It doesn't propose that any zone must follow this behavior, but says that if large zones consider their Infrastructure RRs as different than the rest, and want to survive large/sustained DDoS attacks, this is a simple practice that can measurably help.  Moreover, since no new protocol behavior is even being attempted, it doesn't require anyone to follow this approach.  It simply evaluates the benefits for anyone who does it.

> 
> I say that based on a last year project to single source our DNS resolver for an integrated system that was beginning to expand using different DNS resolvers and APIs and there was a growth of query duplicity with different caching, including round robin or lack there of.
> 
> TTL/Caching was its anchor for reissuing queries to optimize it and one of the immediate highlight was the huge amount of low TTLs.  What does disseminate or discriminate these?
> 

My guess, though I could quite likely be wrong, is that tackling the idea of TTLs on non-Infrastructure RRs might cause various people to come up with different reasons to be contrary.  I admit that I could be off base, as I'm not familiar with this project you mentioned.

Does that make sense?

Eric

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 13 Mar 2012 16:21:21 +0100

On Fri, Mar 02, 2012 at 09:56:40AM -0800,
 Eric Osterweil <[email-masked]> wrote 
 a message of 61 lines which said:

> We have resurrected our draft Improving DNS Service Availability by
> Using Long TTL Values, 

> A.1.  Frequency of Infra-RR Changes

A very interesting survey. Thanks for the data. But it works only for
zones who plan their NS change in advance (like most TLDs). For Joe
Smith or Jane Jones, holders of example.com, it won't help because,
although the NS changes are infrequent, they are typically not planned
in advance and the user would like them to be fast. 

I suspect that, if ordinary user's domains in .com adopt the 7-days
TTL, many will be surprised the first time they attempt to change the
NS set.