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

Hector Santos <hsantos@isdg.net> Wed, 07 March 2012 23:26 UTC

Return-Path: <hsantos@isdg.net>
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 971D111E808A for <dnsop@ietfa.amsl.com>; Wed, 7 Mar 2012 15:26:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.152
X-Spam-Level:
X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599]
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 GhNIrpHdZYv8 for <dnsop@ietfa.amsl.com>; Wed, 7 Mar 2012 15:26:01 -0800 (PST)
Received: from dkim.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3780811E8072 for <dnsop@ietf.org>; Wed, 7 Mar 2012 15:26:01 -0800 (PST)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4218; t=1331162750; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Pab/M+ye1AV9lT82F+Cqrc914jc=; b=Iotoj7Cw/S/uz8qrvFpk L64VPoQ64rH2brrE3SriN6+YJfOr+BHiUfIn5hJDOKDSI3jBOGE/BfZZ2W5jbhTT S2FXVlyGefcQwbKjXtC4MOPoKmsDGeLLjfixEdcT5uguoaw0Ha0HMrHfdZyHBc1M qLuBO6+rV0USyRlQvsGsC9g=
Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for dnsop@ietf.org; Wed, 07 Mar 2012 18:25:50 -0500
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com;
Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 69613298.12682.4760; Wed, 07 Mar 2012 18:25:49 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4218; t=1331162485; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=6Ftjuye kFF0FKZvV7QqPhFIF8KoSzSc22d6IKiPlOLI=; b=gHCce3c46xBlptVCpKPq6qU paecjDdCSupX8vEqschglSVaUycB8Usm+Se7+x/BDKoRp8xjm77TnZgbpPtnKQ1f JhBoqlgPlWfPXOi6N0sGTa9E35RE6HxbrXlbURKoWEHX6P0w17zG1Ck2ZXbfNs5c x2Wu0ylGcyG18MURFTFA=
Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for dnsop@ietf.org; Wed, 07 Mar 2012 18:21:25 -0500
Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 668541002.25136.2652; Wed, 07 Mar 2012 18:21:24 -0500
Message-ID: <4F57EEC1.5010208@isdg.net>
Date: Wed, 07 Mar 2012 18:26:57 -0500
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Eric Osterweil <eosterweil@verisign.com>
References: <20120223155730.20754.45643.idtracker@ietfa.amsl.com> <ED92824E-550C-4E76-B7B7-F010613326A2@verisign.com> <F089E289-F10D-4CCA-BF64-2D77E96DD880@verisign.com>
In-Reply-To: <F089E289-F10D-4CCA-BF64-2D77E96DD880@verisign.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Wed, 07 Mar 2012 23:26:02 -0000

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

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
> 
>