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

Andrew Sullivan <ajs@anvilwalrusden.com> Tue, 05 December 2017 21:07 UTC

Return-Path: <ajs@anvilwalrusden.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 6B7101286CA for <dnsop@ietfa.amsl.com>; Tue, 5 Dec 2017 13:07:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=JR4SeU0m; dkim=pass (1024-bit key) header.d=yitter.info header.b=TbNoMouQ
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 V6yssB3uv0vk for <dnsop@ietfa.amsl.com>; Tue, 5 Dec 2017 13:07:49 -0800 (PST)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCAF012711A for <dnsop@ietf.org>; Tue, 5 Dec 2017 13:07:49 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 346A0BD33A for <dnsop@ietf.org>; Tue, 5 Dec 2017 21:07:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1512508039; bh=hjb8FVlEujnUuGDsVwAjeSWqH3yaEb4dOR+Ldzh9gYI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=JR4SeU0mlnr/yHOluzl6+WIZlpVMslwV6pvRc+yt0JirdyQpOd1fc4lon/QBcOGU5 FtzSxF+v31mLDohDs+QG3WbpWOuzlSEwrO+hlpDEukheTuXJwYBrN+blNeuUa3c/e0 dYUk1D0zQ4G3TPWCCzIcOxpSMq5EoEI5dJQ5SRHQ=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFh8OS69pYKx for <dnsop@ietf.org>; Tue, 5 Dec 2017 21:07:17 +0000 (UTC)
Date: Tue, 05 Dec 2017 16:07:16 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1512508037; bh=hjb8FVlEujnUuGDsVwAjeSWqH3yaEb4dOR+Ldzh9gYI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=TbNoMouQz+UFNI36Q12nbK5EhTc3mjN+u+XUI//sfdtGO68IrEatFZ6drXPLBxGdB I+Ymy0upOBuwtIHEA+dV2Nq92UJ2B2EjzfvVQ6Kx/U/msNHxJ3eLt9RoNp5huI1bRU DraaYXW6G/jRTIsw5h/8BacoY7K6W7CzYK7O+Mj0=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsop@ietf.org
Message-ID: <20171205210716.d6dfvwlwdo44uslp@mx4.yitter.info>
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> <20171202143925.GA20446@jurassic.lan.banu.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20171202143925.GA20446@jurassic.lan.banu.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/uTylJnR_xGeDcNU9Zqk7VF-MrVU>
Subject: Re: [DNSOP] Measuring DNS TTL Violations 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 21:07:52 -0000

On Sat, Dec 02, 2017 at 08:09:25PM +0530, Mukund Sivaraman wrote:
> I don't agree a downstream cache has authoritiative say about extending
> TTLs (except exceptional circumstances where the authority is
> unreachable ~serve-stale).

I will note that this WG spent a fair amount of effort on RFC 7583.
That text is actually bad advice if you are supposed to expect
resolvers to extend the TTL on RRsets, because the Ready state depends
on caches expiring.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com