Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale

tjw ietf <tjw.ietf@gmail.com> Wed, 18 October 2017 11:51 UTC

Return-Path: <tjw.ietf@gmail.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 5D51C13305E for <dnsop@ietfa.amsl.com>; Wed, 18 Oct 2017 04:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 b92ttwH6_WS1 for <dnsop@ietfa.amsl.com>; Wed, 18 Oct 2017 04:51:23 -0700 (PDT)
Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752411342D1 for <dnsop@ietf.org>; Wed, 18 Oct 2017 04:51:22 -0700 (PDT)
Received: by mail-wr0-x233.google.com with SMTP id z99so2252796wrc.12 for <dnsop@ietf.org>; Wed, 18 Oct 2017 04:51:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GH3B8BcnmoS1fQTCDx+5XCwroyK/b1u2FVTHzorYfV0=; b=k/PTVKWReiqj6RiOd+rYJ/Nb+0YKb228QvefJwdlG5IjzOoc82OtaF6y4j/zu7WNH8 Uogm/9ZHRU8Kjk3/7Aie199v1fHel1zmtFjHbWi+wYEQlJVkNn0UO8MQ5uxRj08VdG8+ hsc8IvxVGPv2k5nm39ohqr8Qcc1X0u3nQ5OdR4vh/N6FxdIX0xezOnT2udgZgb+noExI njL0eKGNog/fkd26r14CJRbl3GswdactaY76ZhLUL3FTXF6z3SCF/dE6+WvhygF/w6Qc DBWsfRU7idUUbCIgl+X7DriVtXLMIhJD70oKFuUNQmG6X4Dw4hVjKpHoUOk6BUQf2xGP 4mWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GH3B8BcnmoS1fQTCDx+5XCwroyK/b1u2FVTHzorYfV0=; b=YdTt48giEYp1hkTVVsIxTV6aozkuGs3ZsFgwMxoprOBqfAdz+/rtRQUEC/DzQVbsQN 0JPxC1lqq8VGA7rYW0lt9qQUsMej+Bc8gKiseY2iY3tiJG2snneQk4E/eimCZiAazJoz QTsvtawSy2OgtJtOnUwASSDRTaFt75GL5sSSnXSMuxFc/1pGjLGQIT5kUVlUZE+n/srf djDwSB6DRUQUFzT2vJNXaU5Ru/OGJ0DJ/PtY+TebFSFxKTMWkEKWRSz7u9ss48l9bxVC viUR1WbTvuSiHVMjJTKqCfCR8ZoLdl4QJbeypWW+ZXdKGpMcfAXLa7OOBoFuWXXj5uQU hSow==
X-Gm-Message-State: AMCzsaWNmbhzT2YhnbJ1HLogYU8HzsVBoBJjMLVgjCoAZdYNro4W3pBZ Y2AbpUhdrk3cyygSUgKkvCMTth0aG/9SlT8JopA=
X-Google-Smtp-Source: ABhQp+R47h8ZPkoA8X2g95SGgoamOrIoTqQ1Mu7imeeEQQSH/kr1Rk+s2RpGehDDB/xFDn3ZI4FWsJ57dvxH9gn5MnM=
X-Received: by 10.223.133.99 with SMTP id 90mr6545838wrh.101.1508327481016; Wed, 18 Oct 2017 04:51:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.184.60 with HTTP; Wed, 18 Oct 2017 04:51:20 -0700 (PDT)
In-Reply-To: <CAC=TB12Y8nAPZAFy3WiXskuAzb+3cwR-Kqp_WoG8VPu+6AfuBg@mail.gmail.com>
References: <CADyWQ+FHDHcmq-mr0BCHS5A8yvaOQmhTjve1_DmZN6vAc=BKyA@mail.gmail.com> <20170907154234.3z2zbju2sciiy7wr@nic.fr> <ybltw0emmvh.fsf@wu.hardakers.net> <8295055.TIQDDEhZcU@localhost.localdomain> <20170907221241.GA1031@puck.nether.net> <20170908020710.0170284A3195@rock.dv.isc.org> <CA+nkc8CaJ+4_SCwm5Nbvd8r5SaKcTFhRq4jNV8RHp91Mrt5BhA@mail.gmail.com> <CAC=TB12Y8nAPZAFy3WiXskuAzb+3cwR-Kqp_WoG8VPu+6AfuBg@mail.gmail.com>
From: tjw ietf <tjw.ietf@gmail.com>
Date: Wed, 18 Oct 2017 07:51:20 -0400
Message-ID: <CADyWQ+GPEopoXvnxN4Jsi_=yGKCmitL+L-Ptpx_iPqBbZWBL6Q@mail.gmail.com>
To: =?UTF-8?Q?Marek_Vavru=C5=A1a?= <mvavrusa@cloudflare.com>
Cc: Bob Harold <rharolde@umich.edu>, IETF DNSOP WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0d293eb60532055bd0db2a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/BOqpJhfHGyYg4wvFOBdHbMCa4a0>
Subject: Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale
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: Wed, 18 Oct 2017 11:51:25 -0000

The adoption period finished sone time ago with strong consensus to adopt.
  Authors will want to upload their latest version.

tim


On Mon, Sep 11, 2017 at 2:52 PM, Marek Vavruša <mvavrusa@cloudflare.com>
wrote:

> I support the adoption of this document. Was there a discussion of any
> actual downsides besides "I'd like to know if it's stale" and
> monitoring?
>
> On Mon, Sep 11, 2017 at 11:11 AM, Bob Harold <rharolde@umich.edu> wrote:
> >
> > On Thu, Sep 7, 2017 at 10:07 PM, Mark Andrews <marka@isc.org> wrote:
> >>
> >>
> >> Part of the problem is that we have one TTL value for both freshness
> >> and don't use beyond.
> >>
> >> This is fixable.  It is possible to specify two timer values.  It
> >> does require adding signaling between recursive servers and
> >> authoritative servers, on zone transfers and update requests.
> >>
> >> You basically add a additional timer field to every record immediately
> >> after the TTL field.  This is only returned if the client has
> >> signalled support for the extended field, I suggest using the last
> >> DNS header bit for this as you can determine how you will parse the
> >> response base on whether the bit is set in the response or not.
> >> This field is used to expire records from the cache and its value
> >> is set to the TTL field if the server has learnt the record from
> >> server that doesn't support the extension.
> >>
> >> The existing TTL field is used for freshness checking.  When a query
> >> comes in after that value has expired a freshness check is performed
> >> similar to the existing prefetches that happen today.  A TTL of 1
> >> is returned unless the original TTL was 0 in which case 0 is returned.
> >>
> >> New client - new recursive server - new authservers
> >>
> >>         example.com. 300 86400 IN A 1.2.3.4
> >>
> >>                 +300 seconds
> >>
> >>         example.com. 1 86100 IN A 1.2.3.4
> >>          (background query is in process)
> >>
> >> Old client - new recursive server - new authservers
> >>
> >>         example.com. 300 IN A 1.2.3.4
> >>
> >>                 +300 seconds
> >>
> >>         example.com. 1 IN A 1.2.3.4
> >>          (background query is in process)
> >>
> >> New client - new recusive server - old auth servers
> >>
> >>         example.com. 300 300 IN A 1.2.3.4
> >>
> >>                 +300 seconds
> >>          (record has expired from cache,
> >>           new query is performed)
> >>
> >>         example.com. 300 300 IN A 1.2.3.4
> >>
> >> For UPDATE a replacement opcode would be cleanest way to signal the
> >> new format is being used.  NOTIMP should be returned by servers
> >> that don't support the new opcode.
> >>
> >> There will be a few broken servers that just echo back the new
> >> header bit.
> >>
> >> This way the authoritative servers still control how long records
> >> are stored for.  Dead servers will get a little bit of traffic until
> >> the the refresh completes.  If the authorative servers are under
> >> attack the clients still see a answer.
> >>
> >> The alternative is to perform the refresh query and if it fails to
> >> complete within X milliseconds return the cached data rather than
> >> returning the cached data and doing the refresh in the background.
> >>
> >> Mark
> >>
> >> --
> >> Mark Andrews, ISC
> >> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> >> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
> >
> >
> > While I like the idea of a  "don't use beyond" timer, I think it will be
> a
> > very long time before it is widely deployed (and actually configured by
> zone
> > owners), and therefore won't solve our immediate need.  It would be
> great if
> > clients could opt-in, but again I don't see that happening anytime
> soon.  So
> > I would start with resolver-operators deciding what seems best for their
> > clients (which is hat is happening whether we like it or not).  Adding
> > client opt-out/opt-in would be good.   Signalling to say that a response
> is
> > stale would be good.  Adding the second timer (both per-RR and as a zone
> > default value, like TTL is handled) would be good.
> >
> > On a related note - the SOA "expire" timer tells a slave how long to keep
> > serving "stale" zone data when the master cannot be reached.  Would that
> be
> > a reasonable default value for how long a resolver should serve "stale"
> data
> > when the authoritative servers cannot be reached?   (Currently I think
> most
> > people set a very high value compared to the TTL.)
> >
> > --
> > Bob Harold
> >
> >
> >
> > _______________________________________________
> > 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
>