[DNSOP] comments on draft-muks-dnsop-dns-opportunistic-refresh-00

神明達哉 <jinmei@wide.ad.jp> Fri, 14 July 2017 17:43 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 7C0A413144F for <dnsop@ietfa.amsl.com>; Fri, 14 Jul 2017 10:43:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Status: No, score=-2.4 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] 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id cmH9aGjxuYeT for <dnsop@ietfa.amsl.com>; Fri, 14 Jul 2017 10:43:10 -0700 (PDT)
Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 5F7DB131455 for <dnsop@ietf.org>; Fri, 14 Jul 2017 10:43:10 -0700 (PDT)
Received: by mail-qk0-x235.google.com with SMTP id d78so81015500qkb.1 for <dnsop@ietf.org>; Fri, 14 Jul 2017 10:43:10 -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; bh=pmSmIRn0qvNY72a8Q8WI+HGcb/iuhudjZsL0fDK9E1g=; b=Io2QpDRN5VGP4d9KGHmV6KInn5e5I4YTRf/KreGPOueW0Sqjl5vVwlkkDI1H+LXr0M JiHlH+Bdx4B6k5nkGjJA74zpThnWjOo05xXXMI27eLXg9HQHKYeYNxY0n+1owo80w80o A6uHLoCo4lZAguxO9nV0V0INs/JoVrMT39U1SUfWP5Jzm+bt8tDMhpbK7+1opegE3g8e jAJ3mWVGi9/d7FbixchyDR7RnAf01ki2gwDwxbzBwD1ehPNDrKGVx2OCjX4eorTCMjk5 AslOMSHiBJOT4jh81koySUylDuayzYfM08s0JTJ0sHXBLy7qTcBR5tptANyG3bodLCTt BAOQ==
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; bh=pmSmIRn0qvNY72a8Q8WI+HGcb/iuhudjZsL0fDK9E1g=; b=NpP/HMW6mUZXPyRmWZevD2pq2QgE2IPaa0iBvLXSJWViey+UQjwmKxau0W+iRmoKV9 XcFByEn0DpmY1HSjMJ02lovvlWT29jTWBuRivTm56qao2Su5DMbm9rseLzBEFfhYxdZk vUiusyE/Aag9VtY+7jv4U4vL8DYg1FNRMsoYFG2lwaecZSXbtBPu+xC6lctS6pCKOFVf wqetfajsnImAH6PTYDO8UQAFSiNsUZLqvufUASFeSuDIsjt5jbDvOgnvJerkBLYRDsuI fhhR1crmfgFH7ubnUmap0ffXsofl2ToTWLZpqk9TSFFR8dmSNj6tUlHPtOup3Nn/GreP 8D0w==
X-Gm-Message-State: AIVw110M7eSk2ygIrXld5JTqqfL+Fy/xlcGcxCetV/bfKR4fOA+azBnS 3u+G8i8/C7ZYijh4tP15xI9YKBA5TyCC6U4=
X-Received: by with SMTP id j6mr12195125qkf.14.1500054189183; Fri, 14 Jul 2017 10:43:09 -0700 (PDT)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by with HTTP; Fri, 14 Jul 2017 10:43:08 -0700 (PDT)
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Date: Fri, 14 Jul 2017 10:43:08 -0700
X-Google-Sender-Auth: PvSgcxmQ5bnCWYfu28muLlBMVGY
Message-ID: <CAJE_bqcqcSERAvp5MCMWq_RYZVHEi4XAuf3soZd6xdTPgNkC_A@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/J900_S6fKNLkbpQ84XywFQXyXK0>
Subject: [DNSOP] comments on draft-muks-dnsop-dns-opportunistic-refresh-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: Fri, 14 Jul 2017 17:43:13 -0000

I've read draft-muks-dnsop-dns-opportunistic-refresh-00.  In short my
current impression is: "interesting but not yet very convincing idea".

High-level comments:

It's an interesting idea.  However, depending on its main motivation
I'm not sure how effective it is.  As it's listed in the dnsop agenda
https://datatracker.ietf.org/meeting/99/agenda/dnsop/ with
draft-tale-dnsop-serve-stale, it may mainly intend to be a mitigation
in case the authoritative server of a popular name becomes
unreachable.  But, for this proposal to be effective in that case, the
resolver would have to query other names in the same zone
periodically.  I'm not sure if we can generally assume that in cases
where it matters (for example, for the "twitter.com" zone the resolver
may only query for "twitter.com").

Also, the target zone needs to be generally stable, so for example
it's not very effective if the zone is quite frequently updated.  I
can imagine some popular zones are frequently updated, e.g., for load
balancing purposes.  For example, in my quick experiments the SOA
serial of the facebook.com zone changes quite rapidly.

On the other hand I wonder some other popular zones may not rely on
SOA serials to keep its authoritative servers up to date (i.e., they
may not use the standard zone transfer mechanism to distribute the
latest version of zones to secondaries).

I can also think of a corner case where this approach doesn't work
well: assume a zone that changes very frequently and its serial can
wrap quite quickly.  unlike secondary authoritative servers that are
supposed to be notified reasonably timely via NOTIFY, a resolver may
not be able to notice intermediate changes quickly enough and
incorrectly assumes the zone hasn't changed when the serial has
actually wrapped around.  It's easy to dismiss such a case as
unrealistic, but as a formal protocol I don't think we should ignore
these cases too casually.

Given these observations, I'd first like to understand specifically
for what purpose under which assumptions this proposal is deemed to be
useful.  At this moment it's not very convincing to me.

Some specific comments on the draft text follow:

- Section 4.3

   Upon receiving a positive response containing an SOA RR and a valid
   ZONESERIAL EDNS0 option, the resolver SHOULD associate the zone's
   serial number with the RRs in the answer.

  I believe the resolver should also associate the zone name.  Perhaps
  that's the intent, but it's not very clear from this description.
  So it would be better to say so more explicitly.

- Section 4.3: what if the response contains a ZONESERIAL option but
  there's no SOA in the additional (or authority) section?

- Section 4.5

   o  An authoritative server receiving a misconfigured ZONESERIAL
      option in a query SHOULD return a FORMERR response.

   o  A resolver receiving a misconfigured ZONESERIAL option in a
      response MUST NOT interpret the serial number in any SOA RR in
      that response as an indication of zone freshness.

  It's not clear what "misconfigured" means.  It would help if this
  could be more specific.

- Section 5

  I'd suggest revising the format diagram as follows:

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     !         OPTION-CODE           !         OPTION-LENGTH         !
     |   Reserved  |R|

  with the following description:

      Reserved       A 7-bit unused field.  It MUST be initialized to
                     zero by the sender and MUST be ignored by the

      R              1-bit request/acknowledge flag.  This bit MUST be
                     clear in requests [...same as the original text]

  The main motivation for this suggestion is that "Bit 7 of this
  field" in the original text might sound a bit ambiguous.  Even if
  it can be considered reasonably clear per common sense, I think it'd
  still be helpful if we specify the position in the diagram.  Also,
  in the suggested text the reserved area is just called "reserved"
  instead of calling the entire 8 bits "flags".  Not a strong opinion,
  but I think it's better as we might want to use some of the reserved
  area for non-flag type of data.

JINMEI, Tatuya