[DNSOP] comments on draft-ietf-dnsop-serve-stale-03

神明達哉 <jinmei@wide.ad.jp> Thu, 07 March 2019 20:48 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B23DC12AF7F for <dnsop@ietfa.amsl.com>; Thu, 7 Mar 2019 12:48:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.128
X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MIME_BOUND_DIGITS_15=0.798, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id E_NJkHICqmTC for <dnsop@ietfa.amsl.com>; Thu, 7 Mar 2019 12:47:59 -0800 (PST)
Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com []) (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 B6A401277C9 for <dnsop@ietf.org>; Thu, 7 Mar 2019 12:47:58 -0800 (PST)
Received: by mail-wr1-f47.google.com with SMTP id d17so19037691wre.10 for <dnsop@ietf.org>; Thu, 07 Mar 2019 12:47:58 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xmidp9+SjJaeINvq8eKW3SGBZKA1lK5Zypcm8l/PPK4=; b=o4BxsdfU23P4g+MAs5jOq6HtI+4XY/M/3qCpRSoLjIldbU2pDtn/x6PPG5VMcSkKBp 5qHlWjq6Q1mCHPjrXVDlxqOkcHIyWWyhIv4+RXBJ46HtOBRpwZqdU2PuDfISTI6VfFxg vOZ/BTz8SAlePbAcsI6UIWXIURlcU3QwH46eVLCAt3pqtoLSkiBHA+8/odF/NGL5H+ZW gqlYgfO2XSHYtSvsGfxmBqup2sUz43Txs4un0EJWMMw59Sh3mCvMCb/hwvXvsX5ApuTs UdgXFBO3lzAugaEfbRa9JwyOfTzw7vdPZwRu9Hc8iAaMHIcbQAqF5YbXmrlLJFzJcGSD VIfA==
X-Gm-Message-State: APjAAAXfGe3xwHoIolSAWqSeIsdzOv0aiNReY6D68/PU++liUwP2gfrC T9bUTGhR0DQ3KPfee2IN1Gz4Xm1EB8tz6b+PrilkJV/J
X-Google-Smtp-Source: APXvYqxmTLz4Fra9oLqrRFM2T30Peq72Y4mFCvd6yITxGUuLAyplAVN6zvtNjdmSk0ZxAIJKeK2nSH3Y+B0SkIWZ+3M=
X-Received: by 2002:adf:f58b:: with SMTP id f11mr7692649wro.266.1551991676564; Thu, 07 Mar 2019 12:47:56 -0800 (PST)
MIME-Version: 1.0
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Date: Thu, 7 Mar 2019 12:47:45 -0800
Message-ID: <CAJE_bqdugE3oMqyHres4hwhs4-NpO8yW2FwGDrk2WDAtbweBiQ@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009377760583873855"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/LRsAg0VUSoDrskffouQi6W-FxQY>
Subject: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03
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: Thu, 07 Mar 2019 20:48:02 -0000

I've read draft-ietf-dnsop-serve-stale-03.  In addition to the
high-level draft organization matter I mentioned in another thread,
here are my other comments on this version:

- Section 4:

   The definition of TTL in [RFC1035] Sections 3.2.1 and 4.1.3 is
   amended to read:

   TTL  [...]  If the authority for the data is unavailable
      when attempting to refresh, the record MAY be used as though it is

  On understanding that this is the only real normative description,
  I'd suggest making some more points explicit to prevent abusing of
  this leniency:
  - explicitly say "all authoritative servers" instead of just "the
  - also explicitly note that this MUST NOT be allowed if at least one
    authoritative server is available
  - clarify whether this means a 0-TTL record can be cached and reused
    under this condition (I assume it must not, but it's not very clear
    to me)

- Section 5

   If it
   finds no relevant unexpired data and the Recursion Desired flag is
   not set in the request, it SHOULD immediately return the response
   without consulting the cache for expired records.

  It would be nice if it clarified *what* to return in this case (if
  it's intentionally left open, explicitly say so).

- Section 5

   Outside the period of the resolution recheck timer, the resolver
   SHOULD start the query resolution timer and begin the iterative
   resolution process.

  It's not clear to me how this timer is related to the 'server-stale'
  behavior; this draft doesn't explain what happens when this timer
  expires, for example.  Also, in my understanding unbound doesn't
  have this timer - it eventually gives up a resolution if all
  possible external query fails with a per-query timeout, but it
  doesn't cap the overall resolution time.  That may not matter much
  as this section doesn't seem to be normative and it's just an
  implementation detail of a particular implementation, but if the
  role of this timer doesn't matter either, we might rather simplify
  the text by just omitting it.

- Section 6

   Stale data is used only when refreshing has failed, in order to
   adhere to the original intent of the design of the DNS and the
   behaviour expected by operators.

  I agree on this statement, but I wonder how widely this behavior is
  actually implemented.  As noted in Section 7, unbound doesn't behave
  this way, and in my understanding it's intentional, mainly due to
  a concern about related IPR.  If that's more common for other open
  source implementors (BIND 9 seems to work as described here, but I
  don't know about others), the description won't match the actual
  implementation behavior very well in reality.  So I'm curious about
  implementation status about this point, and if many different
  implementations intentionally ignore this "caveat" for the same
  reason, I think we should adjust the text to match the reality.

- Section 7

   Unbound has a similar feature for serving stale answers, but will
   respond with stale data immediately if it has recently tried and
   failed to refresh the answer by pre-fetching.

  If I understand the implementation correctly, this is not 100%
  accurate: unbound always return the stale data if it's found in the
  cache as long as the "serve-expired" option is enabled.  So I
  suggest revising the text to:

   Unbound has a similar feature for serving stale answers, but will
   respond with stale data immediately whenever the feature is

JINMEI, Tatuya