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

神明達哉 <jinmei@wide.ad.jp> Tue, 11 July 2017 18:01 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 C425B12778E for <dnsop@ietfa.amsl.com>; Tue, 11 Jul 2017 11:01:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, 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 jL1kK7Hw0W5E for <dnsop@ietfa.amsl.com>; Tue, 11 Jul 2017 11:01:20 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 8AB68131772 for <dnsop@ietf.org>; Tue, 11 Jul 2017 11:01:20 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id d78so11295463qkb.1 for <dnsop@ietf.org>; Tue, 11 Jul 2017 11:01:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yFoMAozpbLy1q3QsmD2sJg+7tiH5qpPvaJJ7PWAglRY=; b=RVJ7gI3pl+/T1ruK6h1ry8iD6hmxN7Dl75HuVzHw8PQ7cZf6s/fRpAIc5/cdlL3R86 tc7VKNbweKW/UjZ+5MdsW/7UohMVR6EDZuxcr9+fZyK8WzIwADKEAy+5VZs9fSs/VTqy ODm7vLKMs2c56GncY6cdeVbnf3GXHJ6q6hyFthivblxtwCK0zb6DpFSuIQlAZfc4Kujj x+aOguk5Hpd5T+XlYn3PB3EPTurALVzjnzozr5ZBobQHdfqy4CVpb1DLVH4IWVtscZ65 8+igvwgZzrkUqTXywyOycMwRSO3+wPL/uM5duFqcxAPcti97vzFDMt0NfJnUwIxx8dMA mL4g==
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:in-reply-to:references:from :date:message-id:subject:to:cc; bh=yFoMAozpbLy1q3QsmD2sJg+7tiH5qpPvaJJ7PWAglRY=; b=ghUp/LOcjW27pyf7pSmRJsRoUCBjp7CFTYggkHEbQtJh9l8qtxM2OJsMOXStsRGc+A nwCj3zFJ8KJQac9XeXBfWjHOY6FXJVrnK4dabPxP/z+O0u8kxX/86m9jrQ8fDj219ztY IuINA6fFmHJqmaPadv9aqXTWoTVMksvhTTruOPep8jVQIH2rDRbUp6msiOjtflDrlQ9g afkuSA5WgbB56U4UkUvIcKnmM8I5Ky/u3/3ushV5Y7VZzqb1he5rduti3FKXMsaqFLP/ J1Gqw2Ih2F2PimR/PwjTKp2l9U7HwO1K4+tnW07/uw/wYU63b0b5LtgtVIMwN3QRwppU +SBw==
X-Gm-Message-State: AIVw113L/4tCNFzcloEYaiSfBp3PsO8VoYwIM39UuTrL78lSEyWNAyz9 ZYtNspCm9YgQBq3iO2iAujXtZM9VePkMSLc=
X-Received: by 10.55.123.131 with SMTP id w125mr1440416qkc.177.1499796079515; Tue, 11 Jul 2017 11:01:19 -0700 (PDT)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.60.44 with HTTP; Tue, 11 Jul 2017 11:01:18 -0700 (PDT)
In-Reply-To: <22866.37576.448814.454933@gro.dd.org>
References: <CAJE_bqebjKFEvWEQbHM49sr_BgFEf8PtrnFWWPphSttFU+aQ8A@mail.gmail.com> <22866.37576.448814.454933@gro.dd.org>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Date: Tue, 11 Jul 2017 11:01:18 -0700
X-Google-Sender-Auth: 9N34prZP-YFn51qJpwPxDOHbjHw
Message-ID: <CAJE_bqeaYsoPD=-4o0tdkKnyPXAY5iVPpUxJLOX6njMwzivrjg@mail.gmail.com>
To: Dave Lawrence <tale@dd.org>
Cc: dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pBOBwITMA49aekSyD6whkFj18kA>
Subject: Re: [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: Tue, 11 Jul 2017 18:01:26 -0000

At Tue, 27 Jun 2017 13:15:52 -0400,
Dave Lawrence <tale@dd.org> wrote:

> >   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.
>
> Added to document:
>
> "1 second was chosen because historically 0 second TTLs have been
> problematic for some implementations.  It not only sidesteps those
> potential problems with no practical negative consequence, it would
> also rate limit further queries from any client that is honoring the
> TTL, such as a forwarding resolver."

Okay.

> > - Section 4
> >
> >> Canonical Name (CNAME) records mingled in the expired cache with
> >> other records at the same owner name can cause surprising results.
> [...]
> >   I suspect this is quite specific to internal implementation details
> >   of BIND, [...] it's probably better to clarify it's specific to a
> >   particular implementation architecture.
>
> I struggled with how to incorporate this feedback, because I felt like
> it was already pretty clear that I was discussing BIND specifically.
> In the end the only change I made specifically about this was to say
> "The version of BIND" instead of just "BIND", because I'm not even
> sure whether it would be an issue in the latest versions.  I also
> swapped the sequence of events around to match the real incident that
> happened (A was received first, then later CNAME, versus the original
> doc saying CNAME then A).

My memory on this topic is already quite vague, but I guess I had this
impression since this paragraph begins with a generic sentence without
mentioning a particular implementation.  I'm not necessarily opposed
to the current text, but if I were to suggest something, I might say:

   This was observed with an initial implementation in BIND when a
   hostname changed from having an IPv4 Address (A) record to a CNAME,
   and could happen for other implementations depending on how they
   manage cached data.

In this suggested text I've made two unrelated changes:

- s/, where a hostname changed/when a hostname changed/
  sine the original phrase was a bit confusing to me (it could read as
  if it talked about something about the BIND implementation, but it's
  actually talking about in which case the problem happens).
- fixing typo: s/record.to/record to/
  You'll at least need to fix this one even if the other part of the
  suggestion is rejected.

--
JINMEI, Tatuya