Re: [DNSOP] Last Call: <draft-ietf-dnsop-serve-stale-07.txt> (Serving Stale Data to Improve DNS Resiliency) to Proposed Standard

Puneet Sood <puneets@google.com> Wed, 18 September 2019 16:07 UTC

Return-Path: <puneets@google.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 7DE99120A1B for <dnsop@ietfa.amsl.com>; Wed, 18 Sep 2019 09:07:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Mv-stAhGqy6d for <dnsop@ietfa.amsl.com>; Wed, 18 Sep 2019 09:06:59 -0700 (PDT)
Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 076F7120881 for <dnsop@ietf.org>; Wed, 18 Sep 2019 09:06:58 -0700 (PDT)
Received: by mail-vs1-xe35.google.com with SMTP id v10so173292vsc.7 for <dnsop@ietf.org>; Wed, 18 Sep 2019 09:06:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wixKdzSiCBXw2m1TyS4XZ4oMMQ6C7ow0ONxcuD9a5Kw=; b=KOU2WWx/jqJukzW3zaRuBtRhZ5E4OsWCjJ4cfdUwt4uaOiAta6juwxOTjY4uuLGopM WlF/N4nKsiazPv6uHm3p1s/zKnpbqv5rrTWHNQV/fNt71/p0A6NCszWl/6iu0EK0zTzZ Vlvyp00jfsnvRkeVwgc8UlQj+VkeZdGIZshLAddTSk5LZlv7SGZku72uMbIjavJtNMxI E/FxUbrTA2pIUTJd/PPCttcQc+Mwnt6xMLPkZWhtowAsAymFe/+YGwnrEe42wAapdf0a hYZtKRPDcfUYlNr+m092SW2v80EBYuaTleSt7z0/Pr5C08bh6/m4FKEroteSEosAGAEP KqoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wixKdzSiCBXw2m1TyS4XZ4oMMQ6C7ow0ONxcuD9a5Kw=; b=ZpeoG6ApCPi2gLLzZtvF2SGeG0Q9ML4OwmfcPp6pQOJuLbEVw1L86KzQhDrlqFaBkv NyYGDzQX9Z0MDlFfUwhQLB58w6RYnARv2NMRr1ZGhAfXN4JBFFATy6s5y1di0qiKyo2t oojxOX07U+7OZ+K5ehPy57FGjyYUoyDa3EFDP5iJyCm8/2+dNg0+lNuCiByf004tx6zi CKyunR6Dl5FAdAhPV+W9I+v4ED5kq2Y/EG15XdG7Myv0It3ec1x1r+b6HgGm2xoBvtAr MGt2Y3q0Y3fkSSa9ysEmv8ZRD/bITgTXrSE4QVgooSBybiiUNmb/EGr2+cvYNn7VybSD Y76g==
X-Gm-Message-State: APjAAAVgQGP6dO4QvlijdisFE3SMMWQ5258S8C5RIMpsnaVUpiXzo/b/ fuq/Oq52zR7WWDhprvlDdsLyCbEDDM1RC5jNmbuI9g==
X-Google-Smtp-Source: APXvYqwC0HC/7OUxNMOi/pCHB/ndDFcmEv3j+w+ty3GyN2IGI5EuqsKXeegOD0MNwAgbBDRKOAueuVC2UPAZGci25og=
X-Received: by 2002:a67:1a41:: with SMTP id a62mr2809684vsa.54.1568822817408; Wed, 18 Sep 2019 09:06:57 -0700 (PDT)
MIME-Version: 1.0
References: <156821841762.13409.15153693738152466982.idtracker@ietfa.amsl.com> <91411A04-4DD6-47D6-A4CC-AD8747B21361@dukhovni.org>
In-Reply-To: <91411A04-4DD6-47D6-A4CC-AD8747B21361@dukhovni.org>
From: Puneet Sood <puneets@google.com>
Date: Wed, 18 Sep 2019 12:06:45 -0400
Message-ID: <CA+9_gVsiegDYNaxgipqqfACd394=C7Tf6htj8FfNbzAtw411LA@mail.gmail.com>
To: Viktor Dukhovni <ietf-dane@dukhovni.org>
Cc: ietf@ietf.org, draft-ietf-dnsop-serve-stale@ietf.org, IETF DNSOP WG <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/yZl0dZ1oJk6ztRcDUslqNKehAmY>
Subject: Re: [DNSOP] Last Call: <draft-ietf-dnsop-serve-stale-07.txt> (Serving Stale Data to Improve DNS Resiliency) to Proposed Standard
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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 Sep 2019 16:07:01 -0000

On Wed, Sep 11, 2019 at 2:32 PM Viktor Dukhovni <ietf-dane@dukhovni.org>; wrote:
>
> > On Sep 11, 2019, at 12:13 PM, The IESG <iesg-secretary@ietf.org>; wrote:
> >
> > 'Serving Stale Data to Improve DNS Resiliency' <draft-ietf-dnsop-serve-stale-07.txt>
>
> It looks to me like the list of resolvers that implement "Serve Stale"
> in Section 3 contains a typo.  Should "Know" be "Knot"?
Done

>
>                                                 A number of recursive
>    resolver packages (including BIND, Know, OpenDNS, Unbound) provide
>    options to use stale data.
>
> I am a bit puzzled by the lack of text that motivates treating TTLs
> with the high bit set as positive?  Why is this desirable, and why
> in this draft?  What is the connection between TTLs with the high
> bit set and Serve Stale?  If some resolver inadvertently returns
> stale data whose TTL has expired, it might return a negative TTL,
> and treating that as "0" seems safer than as 137 years (likely
> then capped to 7 days).

Discussed separately.

>
> Finally, in security considerations, there's no mention of
> the potential security impact of stale negative responses.
> Specifically, stale denial of existence of newly published
> TLSA records can delay their visibility to clients, and
> degrade transport security until the fresh records are
> finally available.  With RFC7672 MTA-to-MTA SMTP, a ServFail
> answer would avoid the downgrade and either use a different
> MX host or defer the delivery until such time as fresh records
> become available.  That said, this exposure exists only in a
> limited time window when TLSA records are initially published.

Added wording for negative caching to the first paragraph of "Security
Considerations".

-Puneet

>
> --
>         Viktor.
>