IETF Logo Mail Archive

Re: [DNSOP] Measuring DNS TTL clamping in the wild

Stephane Bortzmeyer <bortzmeyer@nic.fr> Tue, 05 December 2017 16:46 UTC

Return-Path: <bortzmeyer@nic.fr>
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 DAC2A127867 for <dnsop@ietfa.amsl.com>; Tue, 5 Dec 2017 08:46:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJ9i13aELD8w for <dnsop@ietfa.amsl.com>; Tue, 5 Dec 2017 08:46:51 -0800 (PST)
Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF00312704B for <DNSOP@ietf.org>; Tue, 5 Dec 2017 08:46:51 -0800 (PST)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id C4801281076; Tue, 5 Dec 2017 17:46:49 +0100 (CET)
Received: by mx4.nic.fr (Postfix, from userid 500) id BD60028107F; Tue, 5 Dec 2017 17:46:49 +0100 (CET)
Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id B64A4281076; Tue, 5 Dec 2017 17:46:49 +0100 (CET)
Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id B2A3367F2EC0; Tue, 5 Dec 2017 17:46:49 +0100 (CET)
Received: by b12.nic.fr (Postfix, from userid 1000) id AA3E4401C9; Tue, 5 Dec 2017 17:46:49 +0100 (CET)
Date: Tue, 05 Dec 2017 17:46:49 +0100
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Steve Crocker <steve@shinkuro.com>
Cc: Jared Mauch <jared@puck.nether.net>, Paul Hoffman <paul.hoffman@vpnc.org>, Ólafur Guðmundsson <olafur@cloudflare.com>, dnsop <DNSOP@ietf.org>
Message-ID: <20171205164649.2bl3rgagzt6iun2m@nic.fr>
References: <aec2510c-e543-6c4a-873d-5c2db7df5a78@sidn.nl> <CAN6NTqytiDj-FfixD6aKD4AKa5oik7SEtP=82JhP4GR=SyWjYw@mail.gmail.com> <9E8E7EAA-7D37-4841-9144-F49C216ABD7B@verisign.com> <CAN6NTqx2Gq5XK6VDz-dVSbL8k5Yg8G=xM12qdQJHsBP=fp6pCw@mail.gmail.com> <953C8354-3F9D-46A4-82AB-7ED3A9E17387@vpnc.org> <EA286206-0AD7-48C3-B5BE-C2BFA1C7FB73@puck.nether.net> <61DF0A99-0B74-40AB-815F-3DF78755EBE5@shinkuro.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <61DF0A99-0B74-40AB-815F-3DF78755EBE5@shinkuro.com>
X-Operating-System: Debian GNU/Linux 9.2
X-Kernel: Linux 4.9.0-3-amd64 x86_64
X-Charlie: Je suis Charlie
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: NeoMutt/20170113 (1.7.2)
X-Bogosity: No, tests=bogofilter, spamicity=0.000001, version=1.2.2
X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.12.5.163916
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Ybqm3Bx577BSwxt7lSWlqfwzejI>
Subject: Re: [DNSOP] Measuring DNS TTL clamping in the wild
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 05 Dec 2017 16:46:54 -0000

On Fri, Dec 01, 2017 at 01:12:34PM -0500,
 Steve Crocker <steve@shinkuro.com> wrote 
 a message of 41 lines which said:

> Shortening TTLs increases the amount of traffic between the recursive resolvers and authoritative resolvers and lengthens the response time for some queries.  However, I don’t think there is any service guarantee with respect to an individual query that is violated by shortening the TTL.
> 
> Lengthening a TTL, on the other hand, does change one of the service guarantees.  When there is a change in the entry in the authoritative server, what is the maximum time until that change is guaranteed to be propagated throughout the net?  This depends primarily on the TTL.  However, when the TTL is lengthened by the recursive resolvers, the upper bound for propagation of a change is similarly increased.

I fully agree about this very important difference (which is
completely missing in the RIPE Labs article). Lengthening the
TTL is a protocol violation (otherwise, we wouldn't discuss about
draft-ietf-dnsop-serve-stale). Shortening it systematically is bad
manners, and is selfish but is not a protocol violation.

We should not discuss the two in the same thread: they are very
different practices.

v2.37.1 | Report a Bug | By Email | System Status