Re: [DNSOP] opportunistic semi-authoritative caching (Re: DNSOP Call for Adoption - draft-tale-dnsop-serve-stale)

Brian Dickson <> Tue, 12 September 2017 00:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 62F1A133233 for <>; Mon, 11 Sep 2017 17:39:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 53Lg325WmGpn for <>; Mon, 11 Sep 2017 17:39:27 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6092013321F for <>; Mon, 11 Sep 2017 17:39:27 -0700 (PDT)
Received: by with SMTP id v19so19399723ite.0 for <>; Mon, 11 Sep 2017 17:39:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=sOn5Z6Q1vyCyqopDK20ywMf1HIKPGiSAZYqfBPlyk48=; b=FKz6CxlSNrDjQWDkHPubTu4q4kdarQVVElZlHRmWNGzBL3kSVwhe9pvS6gPblWsRg2 1E9Oa517L65kAwZZ/Sdq9hEh9Lfw4gGFwg32+jfWEAFowiewsEs1QPwSvF7M2fX+r8at TtkoztThFYF/mIk3GT34XCC0u8nTE+yAdEEr9Rz3QYOz/WUryuzmyiHW8fl8/S8Y1OQO d+HxuOmwBR8Dqwr6CaE8AsB/l1BaOYQldQEOp1xwYSNAHH1p12UlyUJP1UBjK5b0s1Ra RArjXCq0ervqHfy/OGto3BHjjBYPyYrXffXYffZjBS/jKlE4CLMUNUmvwboGPGtHEFhy kPWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=sOn5Z6Q1vyCyqopDK20ywMf1HIKPGiSAZYqfBPlyk48=; b=EBqESEuCHrPgEW2gdvtu2JXNYle7cZvulkwXj9QN+gu3JJDSOf0ANa0fQY/SDNfxTG 0TOcmWBbOJkeaqXiNm+I1NjrAy/i9pfEBwHq78E+mzNd8NXvFTwElT8sMMR3rqbu+dr0 xGwZxMbDs8fpODB0L48Qmu+cyOYZk0JQ2GER0IxA97pIC68oydUT3BfzgfZ2Tx1QRk4u CkLtTwHP+T9HKIOWEffpYUWMemmqM+5MhqegL2E67pR20dmhEsTloMS0xreCEDq71HzL XokjYbiENDBQLEQUIQttIGkf/X64a6k5B1SEoSmfWnDjC5JMOSNjmDWxNaeM6p/5NQoA hGDw==
X-Gm-Message-State: AHPjjUilGw6UCfjD3xiBi0IUPfHBUyxIgMXf2O5WsfHoY8J/dp+KM/cq eSRzqINFvG5Y+BG71+AXKa4zgqIP48Sg
X-Google-Smtp-Source: AOwi7QAgj61G1apLSIs32zNE7jlGS8Df+H5uX+NEminRdZGUOoeZrLrI093YKouwLMVZlVXBMGyYA6zQi+1PIJcdJDU=
X-Received: by with SMTP id o124mr17567856itg.51.1505176766408; Mon, 11 Sep 2017 17:39:26 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 11 Sep 2017 17:39:25 -0700 (PDT)
From: Brian Dickson <>
Date: Mon, 11 Sep 2017 17:39:25 -0700
Message-ID: <>
To: " WG" <>
Content-Type: multipart/alternative; boundary="001a114991967c71240558f346d7"
Archived-At: <>
Subject: Re: [DNSOP] opportunistic semi-authoritative caching (Re: DNSOP Call for Adoption - draft-tale-dnsop-serve-stale)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Sep 2017 00:39:38 -0000

> Paul wrote:

> Evan Hunt wrote:
> (I do like the idea of advertising a separate expiry value though.)
> i think if we're going to put something into the 20-year deployment funnel
> we should treat the fixed costs as high and demand more benefits. that's
> where the proposal up-thread came from.

The idea is interesting, definitely.

Here's something potentially useful, in terms of "more benefits":

As I understand it, there would be signaling on this via another EDNS bit.

This makes it effectively orthogonal to DNSSEC.

Which means, at least semantically, a response to a query could have
meanings for:

   - The bare RR type
   - The DNSSEC RR type(s) that go with the response to the bare RR query
   - The EXPIRY RR type associated with the base RR query
   - The combination(s) of DNSSEC+EXPIRY RR types

And given the DNSSEC RR types that might appear, the corresponding
DNSSEC+EXPIRY could allow a zone owner to signal a variety of intents.

(Assuming that DNSSEC+EXPIRY records are themselves signed...)
There is the potential for a zone owner to indicate whether an entire zone,
or perhaps some subset of records from the zone, should be treated as
"INSECURE" rather than "INVALID" iff the signature record(s) expire, but
where the DNSKEY used for signing is itself correct.

Or, alternatively, the zone owner could signal that the default behavior is
explicitly correct, i.e. that if for whatever reason, no unexpired
signatures can be obtained, that the result should be treated as

A zone's default EXPIRY could be attached to the SOA record, and the
NSEC/NSEC3 records would be able to securely assert the
existence/non-existence of an EXPIRY for anything in the zone.

Recursives could explicitly determine intent, and pass along the results
(proof) to clients. Clients would not need to guess why INVALID or REFUSED
happens, which would also benefit DNS operators investigating
DNSSEC-related issues.

It is work, but I think it adds a lot of value.