Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

神明達哉 <> Fri, 26 January 2018 16:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19D0312DA29 for <>; Fri, 26 Jan 2018 08:22:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Status: No, score=-1.7 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] 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 4nuNZpdNMeMR for <>; Fri, 26 Jan 2018 08:22:20 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8CF76124BFA for <>; Fri, 26 Jan 2018 08:22:20 -0800 (PST)
Received: by with SMTP id t16so984504wrc.10 for <>; Fri, 26 Jan 2018 08:22:20 -0800 (PST)
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:content-transfer-encoding; bh=FazytXYOnvDIeiQsH1xjaetqf1wBPDFHc3U1gwF8ObU=; b=XRkxIMqSC7AxoDiEzP3XjccwUHNuAhwBQWKbTyEGh0fMQbQZSGWWPhUv2b8WiHQhD+ WLzn6VcNWtLy2Hk3+n/skHBSBItYmr1nvIajUDy/EdDSLzEbCHrl9gtxXorEgTOSjl4n HPl0Fz70scGp7yoIjDihuojssoDMN4fKBVlLpp81Sy+RPla5GFw9hrZmpUTJamQnzZ7D b1/TBKM4WEPQHFBqzFGQJ/H1f0rmllhU/F3eEeG3204xxOINViUYVAxI2A4WsXASO1QA Q5Jb92zKw+DqTYX9ve+3SB1SdZm8hFXNF3CRqCMveNAVLoZvz9Z/9mqmXfF18KYuQFto etZw==
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:content-transfer-encoding; bh=FazytXYOnvDIeiQsH1xjaetqf1wBPDFHc3U1gwF8ObU=; b=EWQNYRiqlsO34POKqsEoYG69GyggNGIBI/aCeQntGD5NPyb0oZEhRjooBevVApV8XP EUgtLTYBuFor3UJNYy4Zls4LSrlDiwtQ5dDh5msfhMmfZZhJb0HVei9Af7VdvT/Q+SVj 7doi9olCSt5LsGWjZ0avb62Ayuh6fmQeaunlNixW7U096ZxSt50/SU+WvjLPZMSZJB28 dtnFpfrigHjkx7ROD2arkku2xlbNkMyn+YHDJUknrlt4FUHzuNUrcqSeyRKpgypGZFiy y4W5E7vwYCqom/OzsYvhT+6ASyeUDydznQxG1583EEDcVSWTNh0onm2dGtftcOUJ4sqg 0GhQ==
X-Gm-Message-State: AKwxyteZhDzKQ7ijBgYEkxD9en+PeB32FYrIB6JeDnS6F6lkyiZtCGY7 OsbJeikA4cjlUBPhJotaPfCBaQBi+SQ28YQ7WJeOUegM
X-Google-Smtp-Source: AH8x224QsaNUY5Pu1an6Qm4i6jaM+AF/bqOPdzL3dLxBv6k7QQvid9wgB3RQP3Xmb8Zq5sjrgsP1FDy/sRaiVS5YNbw=
X-Received: by with SMTP id t3mr11400647wrb.274.1516983738937; Fri, 26 Jan 2018 08:22:18 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 26 Jan 2018 08:22:18 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Fri, 26 Jan 2018 08:22:18 -0800
X-Google-Sender-Auth: pb8hM4lcOsJKDMlNvWiLlsDichI
Message-ID: <>
To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <>
Cc: dnsop <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02
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: Fri, 26 Jan 2018 16:22:22 -0000

At Fri, 26 Jan 2018 12:47:29 +0100,
Petr Špaček <> wrote:

> > I myself don't have a particular opinion on whether to send it to the
> > IESG, but I don't think it's ready for it based on my understanding of
> > the WG discussion so far.  In particular, I don't think I saw a wg
> > consensus about one major objection to the idea: "I'd like to keep my
> > right of configuring my DNS servers (authoritative or recursive) to
> > return whatever I want to 'localhost' queries".  Again, I personally
> > don't claim this right, but I see the concern.  If my observation is
> Software is still free to provide knobs to deviate its behavior from
> RFC, which is nothing unusual when it comes to DNS(SEC).
> Is there a real problem to solve? My understanding is that this document
> is stating what software should do by default.

Hmm, that's different from my interpretation of the draft.  According
to my usual interpretation of IETF docs, I would interpret these from
Section 3:

   3.  Name resolution APIs and libraries MUST recognize localhost names
       as special, and MUST always return an appropriate IP loopback
       address for IPv4 and IPv6 address queries and negative responses
       for all other query types.  Name resolution APIs MUST NOT send
       queries for localhost names to their configured recursive DNS

       As for application software, name resolution APIs and libraries
       MUST NOT use a searchlist to resolve a localhost name.

   4.  (Caching) recursive DNS servers MUST respond to queries for
       localhost names with NXDOMAIN.

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

as these are requirements without a user-configurable knob.  If the
actual intent was just to specify the default behavior with a
configurable knob, I'd expect SHOULD-variants are used in cases like

JINMEI, Tatuya