Re: [DNSOP] DNSOP Call for Adoption - draft-west-let-localhost-be-localhost

神明達哉 <> Mon, 11 September 2017 18:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0DEAC132F29 for <>; Mon, 11 Sep 2017 11:37:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Status: No, score=-1.699 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9kWKRCFDPfBk for <>; Mon, 11 Sep 2017 11:37:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 73C58132ECF for <>; Mon, 11 Sep 2017 11:37:47 -0700 (PDT)
Received: by with SMTP id k2so20954892qte.2 for <>; Mon, 11 Sep 2017 11:37:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=cXiP2zSDNX2S16mzi0axjBih9tLMvYwck1zZAitUew8=; b=h6/H2b0OEBY5hz6s4ABncq/nr0jqwY9V2Hb72UPHkWJ1if47M8pliLBR6lV7kMFFvh ak0ZUdzB9ecADthLEA6N7hN6bjd3T8fXMuxD0/mVrzcfmzSObtSOn+cx1zqa6sohuVWA JveAIRF5EtitiiwJf38f/tORaJzQrp0O2fDNqLgw1m8AAxsrJ0Mo+hnVotp4b8sXiVqw 7ufyudkbN+YvriiRwMDURq0+9lZo5lUqJLu6ITIreEa7zQDy3kuI6D9FD6+4tSommiCI 1lUJN+s1CDYp6cSziIAayOj+ul1uctRXUHXSREPfGac8Yj7Upt5VUDPsZ0jxM21BqSAR 1DCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=cXiP2zSDNX2S16mzi0axjBih9tLMvYwck1zZAitUew8=; b=Jts3B3eMDvbmW7vVD/iZSwBOKIubIZNPbNyZuqDjNrqBi1H9irWCyl41yXGCBoObAM q0Xa55qkr54BWJng8wwfDbHRyWVO47kD5g4HmR2bCii5tiL1hQEGtQ5tz8m7gsiItGca KPgsNOKZFdCp6nmPInvQ1l+7iAahmDEuw8WLJJNHqGJVcDQTQwsrlspWTU76I4zT36Xt btst9aPUvaV84mYuBP6u7JKevI847WDLPx7p0TJBto34vteP9gcHjGa/6gI970uVaXuu rdFhSKaLLRdmJ/BUvdVFQJ0vxrKzVtVI9pRzbKjKUC/8nbD72XGXogepI+JjYthQQS91 d+5g==
X-Gm-Message-State: AHPjjUjgiUORmlqm7/i56fXsotFEIs2Kcr9y8l+OAKBGyN0SWBXCtkYD fWU/ATMcpe6SUaKFf+kEJcBWo7OuAg==
X-Google-Smtp-Source: AOwi7QDxcQ5b45xOwE0+NR067hpJq+MQabr2wl2Sr18TmOAx09dQuCKdQCq8zdmA645sikGP9vaA1FQAJR++nZPHfUA=
X-Received: by with SMTP id j29mr18846205qtf.282.1505155066426; Mon, 11 Sep 2017 11:37:46 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 11 Sep 2017 11:37:45 -0700 (PDT)
In-Reply-To: <>
References: <>
From: 神明達哉 <>
Date: Mon, 11 Sep 2017 11:37:45 -0700
X-Google-Sender-Auth: dqDy6LxUYiLE2fovJqAq_qAT5J8
Message-ID: <>
To: tjw ietf <>
Cc: dnsop <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [DNSOP] DNSOP Call for Adoption - draft-west-let-localhost-be-localhost
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Sep 2017 18:37:49 -0000

At Wed, 6 Sep 2017 10:00:01 -0400,
tjw ietf <> wrote:

> When the idea of having a Call for Adoption for this document came up, we
> thought long and hard about this one.  However, the comments from the
> working group focused this document to address the specific issue of the
> local hostname.
> This starts a formal Call for Adoption for
> draft-west-let-localhost-be-localhost
> The draft is available here:
> Please review this draft to see if you think it is suitable for adoption by
> DNSOP, and comments to the list, clearly stating your view.

I've read draft-west-let-localhost-be-localhost-06.txt.  I don't have
a strong opinion on whether to adopt it, but if it's adopted I'm
willing to review subsequent versions.

I have one high-level comment: I wonder whether the name can be
different from "localhost".  My impression on some of the controversy
on this proposal is related to compatibility with the existing
practice with this name (e.g., some people may want to have their
preferred AAAA or A RDATA at their own risk).  If it can be a
completely new TLD we at least don't have to worry about that type of
conflict.  Of course this will require more procedural overhead such
as new registration for the special-use registry and doesn't help
any existing practice that assumes 'localhost' always means a
loopback address.  But such a practice is not 100% safe today anyway
(and in my understanding that's why this draft was written) and even
if the proposed new semantics for 'localhost' is standardized its
deployment will take time (and I suspect non-compliant behavior will
stay quite long).  So it might be even safer to introduce a new name
and have applications that need this property gradually migrate to it.

It's just a thought, I'm not pushing the idea.  But in any case, it
may be worth explaining in the draft why the name must be 'localhost'.

I have a couple of other minor comments on the current version.  All
of them are somehow related to how authoritative servers are supposed
to behave in the context of this draft:

- Section 1

   In addition, recursive and authoritative DNS servers are required to
   return "NXDOMAIN" for such queries.  This increases the likelihood

  Should authoritative servers other than the root server really be
  required to return NXDOMAIN?  Except for the root server, if an
  authoritative server receives a query for a name that doesn't belong
  to any zone it serves, it's generally considered a (some sense of)
  bogus query, and my understanding of common response to this kind of
  query is either REFUSED or a referral to the closest ancestor zone
  known to the server.  I don't see a reason for changing the behavior
  of these servers specifically for 'localhost'.

- Section 3

   5.  Authoritative DNS servers MUST respond to queries for localhost
       names with NXDOMAIN.

  Same comment applies.

- Section 4.2.1

   This document requests that a DNSSEC insecure delegation (that is, a
   delegation with no DS records) be inserted into the root-zone,
   delegated to "blackhole-[12]".

  This would violate the above 'MUST'.  If we choose this option (and
  if we also generally keep this MUST) some more clarification (such
  as making an exception) will be needed.

JINMEI, Tatuya