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

Ted Lemon <> Thu, 25 January 2018 20:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 702281277BB for <>; Thu, 25 Jan 2018 12:48:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lYvOTmP16R7C for <>; Thu, 25 Jan 2018 12:48:38 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C1C3127599 for <>; Thu, 25 Jan 2018 12:48:38 -0800 (PST)
Received: by with SMTP id a27so22714723qtd.1 for <>; Thu, 25 Jan 2018 12:48:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=6NntatidmKJhvPyVG85SZaSsivDQTxx+ICtz5CpuOgE=; b=UbpNhvlgU8VVt7ZOvLBJCeYBkssemskOLAhYixMShnqLAItCrjzlhIt7IxDE8KVyJV 4an64TnVbH5je/iBS4QubPX7lyDOpiZSBYvwLy+qmsOX5wYShBX5SYJOM28nhQHiCMEQ GRBsY2qhyr7hT2dtMigtYJS6/qetS2jMmv2+WC9D+PzDKGTUTqVEG0gcoTxgXX0rxzhO zSfzzM618VFnftN7gIXtMcKf5/2raESTCS5FJTuXtFDQ4aWT7tYJTv+h093N101odtCx uNtSZ9wN56b5jroth4wsV2R+zb4jAE8PRwwHYGD2Oad/vNJ6c8szHZ5wuDfi9mpx8zhN d74Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=6NntatidmKJhvPyVG85SZaSsivDQTxx+ICtz5CpuOgE=; b=X05CsyhL0JEdrPqyhSbJ5HQeu4MzNp6Oy4CQmz3ioAqlUMNRXYrcUPsI7h3dBNY9uR bCrK77/hoIsYn/Y20FrgoMs2KZcL33KnjxvN4nf4y89dsruQ5muI/sfmKOJMOtnJ4P8p mXKxY5j/Mfdt9UwJjojVjFbtrJGOdaMEglr0Bbld01B8U21Qd0KePdB0Z/7/AWNW1JJH MCDi4717aA3xDwmKtEWmbHAcTzI0m7Za8yAscgIgtHCOudJYLLh6o4o7qlLVzKmIVXa9 RRtDDKvs6BR3Sdd8Uvgz0x9ahztHXhLybt0bVYOR1atVqzAQoF+kn0YJOflpmTKZAd8n +Zsg==
X-Gm-Message-State: AKwxytdbhKhz9kedC6do33ibqIV0C11qECQR7gcIdnWPKktukzfP5EZ6 /KovC9BHYDz442/uX4f/iEjVFjrbXdo=
X-Google-Smtp-Source: AH8x224UuyaDpmRwVEfguKlz3ftXuY0YqJwdZ7qG9UIdrqHAXdFlj0XiCGUkBdbdR61UzeXKYHpniw==
X-Received: by with SMTP id n19mr7741311qkh.184.1516913317038; Thu, 25 Jan 2018 12:48:37 -0800 (PST)
Received: from cavall.lan ( []) by with ESMTPSA id k7sm2613596qkk.70.2018. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jan 2018 12:48:36 -0800 (PST)
From: Ted Lemon <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_90C801AC-D316-4868-9B20-DC209ECBACAF"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Thu, 25 Jan 2018 15:48:35 -0500
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3445.5.20)
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: Thu, 25 Jan 2018 20:48:40 -0000

On Jan 25, 2018, at 3:35 PM, Viktor Dukhovni <> wrote:
> In summary, existing "localhost" zones are fine and should not come
> into a violation of a new RFC.  Secondly, returning the expected
> address records at each opportunity to do so, without punting
> the problem downstream is the most sensible way to achieve the
> stated motivating goals.

With all due respect, that's your stated opinion.   I asked if you have some specific use case in mind where what the draft says will cause a problem.   It sounds like the answer is no, but if I'm mistaken I'd like to hear what's motivating this opinion.

>> Also, it's worth bearing in mind that regardless of what this
>> document says, you can always answer queries to 'localhost.'   Is
>> there a reason why that's not enough to satisfy your use case?
> If it is going to happen anyway, why forbid it?

I think the answer is that the less it happens the better, and forbidding it is going to make it happen less.   If it's just your personal preference not to do this, then the working group isn't saying you can't make an informed decision to go against what the spec says.   We're just saying that the correct behavior is to not answer queries on localhost.

If you decide not to follow the working group recommendation, that would be you deciding that you do not agree with the consensus on what the correct behavior is.   It's still important for the working group to say what the correct behavior is (IMHO).