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

Eric Osterweil <eosterweil@verisign.com> Thu, 08 March 2012 15:25 UTC

Return-Path: <eosterweil@verisign.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744D621F8584 for <dnsop@ietfa.amsl.com>; Thu, 8 Mar 2012 07:25:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.491
X-Spam-Level:
X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3-wiL-HM6+k for <dnsop@ietfa.amsl.com>; Thu, 8 Mar 2012 07:25:05 -0800 (PST)
Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id AB43D21F856F for <dnsop@ietf.org>; Thu, 8 Mar 2012 07:25:04 -0800 (PST)
Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKT1jPTrn0fjnN655b9taKblBjiEE5CpUc@postini.com; Thu, 08 Mar 2012 07:25:04 PST
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q28FOv2w021176; Thu, 8 Mar 2012 10:25:01 -0500
Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.30.33]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 10:24:57 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Eric Osterweil <eosterweil@verisign.com>
In-Reply-To: <4F57EEC1.5010208@isdg.net>
Date: Thu, 08 Mar 2012 10:24:58 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <BF3848E8-0571-4708-9AE1-D46065CA88F9@verisign.com>
References: <20120223155730.20754.45643.idtracker@ietfa.amsl.com> <ED92824E-550C-4E76-B7B7-F010613326A2@verisign.com> <F089E289-F10D-4CCA-BF64-2D77E96DD880@verisign.com> <4F57EEC1.5010208@isdg.net>
To: Hector Santos <hsantos@isdg.net>
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 08 Mar 2012 15:24:57.0092 (UTC) FILETIME=[9E80F440:01CCFD3F]
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] Fwd: I-D Action: draft-pappas-dnsop-long-ttl-04.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2012 15:25:07 -0000

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

> -- 
> Hector Santos, CTO
> http://www.santronics.com
> http://santronics.blogspot.com
> 
> Eric Osterweil wrote:
>> 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:
>>> 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: internet-drafts@ietf.org
>>>> Date: February 23, 2012 7:57:30 AM PST
>>>> To: i-d-announce@ietf.org
>>>> Subject: I-D Action: draft-pappas-dnsop-long-ttl-04.txt
>>>> Reply-To: internet-drafts@ietf.org
>>>> 
>>>> 
>>>> 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
>>>> I-D-Announce@ietf.org
>>>> 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
>>> _______________________________________________
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
>