IETF Logo Mail Archive

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

Jared Mauch <jared@puck.nether.net> Fri, 01 December 2017 16:44 UTC

Return-Path: <jared@puck.nether.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 D211D127286 for <dnsop@ietfa.amsl.com>; Fri, 1 Dec 2017 08:44:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 yQ5mVIUuVfa0 for <dnsop@ietfa.amsl.com>; Fri, 1 Dec 2017 08:44:00 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 84BB7126E7A for <DNSOP@ietf.org>; Fri, 1 Dec 2017 08:44:00 -0800 (PST)
Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 1F3F55407E8; Fri, 1 Dec 2017 11:43:57 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <CAN6NTqytiDj-FfixD6aKD4AKa5oik7SEtP=82JhP4GR=SyWjYw@mail.gmail.com>
Date: Fri, 01 Dec 2017 11:43:50 -0500
Cc: "Giovane C. M. Moura" <giovane.moura@sidn.nl>, dnsop <DNSOP@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0D230F29-6F59-4953-BA98-7DB83880F0EF@puck.nether.net>
References: <aec2510c-e543-6c4a-873d-5c2db7df5a78@sidn.nl> <CAN6NTqytiDj-FfixD6aKD4AKa5oik7SEtP=82JhP4GR=SyWjYw@mail.gmail.com>
To: Ólafur Guðmundsson <olafur@cloudflare.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/HZ_caBVn6-HiCkeWzAZ3DHZVUEU>
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: Fri, 01 Dec 2017 16:44:02 -0000


> On Dec 1, 2017, at 11:38 AM, Ólafur Guðmundsson <olafur@cloudflare.com> wrote:
> 
> 
> I strongly disagree with your "terminology", TTL is a hint about maximum caching period, not a demand or a contract. 
> A resolver can at any time for any reason discard cached entries. 

Agreed.

> Many Authoritative operators have "unreasonable" TTL's like less than 10 seconds or multiple days and I see no reason why resolvers do not 
> apply minimal and/or max caching rules that are reasonable. 


Yes, I remember a load balancer from the last century that had serious issues with DNS requests with low TTLs.  We ended up replacing it.

TTL is certainly a MAX, but no reason you can’t return a shorter value.  My stub resolver may see a lower number if an item is about to be evicted from cache, should we not see that?  Clamping the max seems helpful and causes the least enduser harm, so is quite wise.  

The same would be true hitting a large anycast dns server like 75.75.75.75 or 8.8.8.8, 4.2.2.1, you may hit a different backend for whatever reason so see varying TTLs for the same query within a 10 second interval based on that.  That’s not bad, it’s working as designed.

I think measurements are interesting though, so identifying TTL clamping in the wild would be an interesting study.

- jared

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