[DNSOP] comments on draft-tale-dnsop-serve-stale-00

神明達哉 <jinmei@wide.ad.jp> Wed, 24 May 2017 17:58 UTC

Return-Path: <jinmei.tatuya@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 2BA3E12940D; Wed, 24 May 2017 10:58:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1
X-Spam-Level: *
X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 gXsczgT1tGFG; Wed, 24 May 2017 10:57:59 -0700 (PDT)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 9DD411200E5; Wed, 24 May 2017 10:57:56 -0700 (PDT)
Received: by mail-qt0-x233.google.com with SMTP id f55so161942564qta.3; Wed, 24 May 2017 10:57:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=oZAuGQzl3CryrA33vnXRHO8C9mkw2GJkOiFm7pKddb8=; b=oGbfK5NASpn5LO+Z7Nn8BvRhQJPz4ErH+1drlziy6mIT2LMqJTAS0jdzof6+QzySkk S2A+iUuL9IiENhSBisnOzusQkrbi9kitakXs3dbyB/cvb0A3b2p+m4HwWhEy6NSh+Buc Boq5rFuy0IjL6Ufc+5KTbcTlxHkYfbsV4wuzbEbrpFlo5qRxti7f6Rxjzy8vdBzrh1gm EmTGmBfICh4/rrfpQ65lHKYiThvhinb90Q2SD+/omvwLGb2UmrpyXAmfHcsUZYxrTwFw bzWVU4AuNhuGq5tKqg9IcRY65shGeH4zisVQLWa/J3yQgphnQ4o9xTIqCB4SS+E1kYRs Rx4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=oZAuGQzl3CryrA33vnXRHO8C9mkw2GJkOiFm7pKddb8=; b=fQeQYrTUruR1VjfM6gdtv+midAEb4tq8d8A+bJ0FJpgYyxfmnHho6uzPLm2y4u03kD fSiqBTkNWhtTJ73Im/gIBmAf6EIpx4UVOIvQzBJbNistyPman8Z5jsl3PHH4HhdwvH0B li0ZIoNkgLBzWt4YZ2wgEJkE7WNDkOgq6RY1VHIzqd4UnHOlsM7z3/FuR6KsbbYRAFQR dSs8LSgzSy7JlrUuUFnoZOrYoNpGYUJNgNNNLgjAmqz8qOCGu1r9VUb4OqemhT8t6Rze iG98CwgBU4rkPGLX7eF5DPwSV2qvHJU+dmvqtwvGcZ16osOoN4WWaE5JvvCTmhalfMpf kRdQ==
X-Gm-Message-State: AODbwcDGBSPzB690wRCeezLxHUsezDu0wwejH8CurpvibWRbQX37Dne/ 9v+g0Du5/rGom5faUYWv3Mwx0WcKN4gydBE=
X-Received: by 10.237.37.21 with SMTP id v21mr36675498qtc.97.1495648675413; Wed, 24 May 2017 10:57:55 -0700 (PDT)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.200.48.141 with HTTP; Wed, 24 May 2017 10:57:55 -0700 (PDT)
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Date: Wed, 24 May 2017 10:57:55 -0700
X-Google-Sender-Auth: ef5IKhqWJnfigIVp2B7lOIRbk50
Message-ID: <CAJE_bqebjKFEvWEQbHM49sr_BgFEf8PtrnFWWPphSttFU+aQ8A@mail.gmail.com>
To: draft-tale-dnsop-serve-stale@ietf.org
Cc: dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jlWplNP-ZOtfcOLwq5z4AdUyCcA>
Subject: [DNSOP] comments on draft-tale-dnsop-serve-stale-00
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, 24 May 2017 17:58:01 -0000

I've read draft-tale-dnsop-serve-stale-00.  Overall I think we need
something like this in practice.  Even if, technically, it violates
the current protocol standards, the background motivation is a real
operational issue and I believe we should provide some
standard-compliant mitigation.  Of course, the end result may be very
different from what's currently described in this draft, but I think
this is a good start for the goal.

I have a few minor comments on the current version:

- I suspect it should include 'Updates: 1035 (if approved)' in the top
  boilerplate.

- Section 3

   If the answer has not been completely determined by the time the
   client response timer has elapsed, the resolver SHOULD then check its
   cache to see whether there is expired data that would satisfy the
   request.  If so, it adds that data to the response message and SHOULD
   set the TTL of each expired record in the message to 1 second.

  The recommended value of the client response timer is 1.8 seconds,
  so end clients will see this amount of delay for queries for which
  this technique is needed (most notably while the corresponding
  authoritative servers are under a DoS attack and unreachable).  I
  wonder whether this is really acceptable in terms of user
  experience.  According to the draft this implementation has been
  actually used in the field (correct?).  If so, were the end users
  okay with the delay?

  Also, it's not clear to me why the TTL is set to 1 second.  Since
  it's actually expired, a zero TTL seems to be a more sensible choice
  here (a similar feature of unbound uses a zero TTL).  If there's a
  specific reason to avoid 0, it would be better to explain it
  explicitly.

- Section 4

   Canonical Name (CNAME) records mingled in the expired cache with
   other records at the same owner name can cause surprising results.
   This was observed with an initial implementation in BIND, where a
   hostname changed from having a CNAME record to an IPv4 Address (A)
   record.  BIND does not evict CNAMEs in the cache when other types are
   received, which in normal operations is not an issue.  However, after
   both records expired and the authorities became unavailable, the
   fallback to stale answers returned the older CNAME instead of the
   newer A.

  I suspect this is quite specific to internal implementation details
  of BIND, specifically that RRsets of a name is maintained in a
  single-linked list, newer RRsets are prepended to the list, and on
  lookup the last found one is used if the list contains both CNAME
  and the exact type (A in this example).  Is my guess correct?  If
  so, while this is really an interesting topic and probably worth
  sharing, it's probably better to clarify it's specific to a
  particular implementation architecture.

--
JINMEI, Tatuya