[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [209.85.221.47]) (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: 神明達哉 <jinmei@wide.ad.jp>
Date: Thu, 07 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 unexpired. 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 authority" - 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 enabled. -- JINMEI, Tatuya
- [DNSOP] comments on draft-ietf-dnsop-serve-stale-… 神明達哉
- Re: [DNSOP] comments on draft-ietf-dnsop-serve-st… Dave Lawrence
- Re: [DNSOP] comments on draft-ietf-dnsop-serve-st… Benno Overeinder
- Re: [DNSOP] comments on draft-ietf-dnsop-serve-st… Paul Vixie
- Re: [DNSOP] comments on draft-ietf-dnsop-serve-st… bert hubert
- Re: [DNSOP] comments on draft-ietf-dnsop-serve-st… Ray Bellis
- Re: [DNSOP] comments on draft-ietf-dnsop-serve-st… Puneet Sood
- Re: [DNSOP] comments on draft-ietf-dnsop-serve-st… Puneet Sood
- Re: [DNSOP] comments on draft-ietf-dnsop-serve-st… Ray Bellis
- Re: [DNSOP] comments on draft-ietf-dnsop-serve-st… Frederico A C Neves
- Re: [DNSOP] comments on draft-ietf-dnsop-serve-st… Dave Lawrence
- Re: [DNSOP] comments on draft-ietf-dnsop-serve-st… Dave Lawrence
- Re: [DNSOP] comments on draft-ietf-dnsop-serve-st… Dave Lawrence
- Re: [DNSOP] comments on draft-ietf-dnsop-serve-st… Paul Vixie
- Re: [DNSOP] comments on draft-ietf-dnsop-serve-st… Tony Finch
- Re: [DNSOP] comments on draft-ietf-dnsop-serve-st… Olli Vanhoja
- Re: [DNSOP] comments on draft-ietf-dnsop-serve-st… Dave Lawrence
- Re: [DNSOP] comments on draft-ietf-dnsop-serve-st… Olli Vanhoja