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

Warren Kumari <> Sat, 10 February 2018 21:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6259612DA68 for <>; Sat, 10 Feb 2018 13:39:39 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Aaxq1-mQKvTL for <>; Sat, 10 Feb 2018 13:39:37 -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 E23BD1270AE for <>; Sat, 10 Feb 2018 13:39:36 -0800 (PST)
Received: by with SMTP id o76so8457068wrb.7 for <>; Sat, 10 Feb 2018 13:39:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5S91cuahyR49lp7zxZ/VCW3QVWjp/OTaxeEegQz3Tnc=; b=YnJBLhxxcbcHQmcj/HiosTwIVzBdcjbop0mvt/PrxZIntabhfwvt7Yb1NkNiOi6yOf Ol4zX+mLjIa/UGwhr3AUKMdvsGq6XkdrI+uvojXcCplUx+xfIFLOfCdBdr0go1XVnSqU 8rFN9DATrT9UgINhK2a3HYqzp4lAVZqmsEpIJa4F6E92zOalfiqziZ/UkPo2n1AjhOSl xapwvHFE4wkbd/jkpk3rJN6t1HZJuKtonwrtFGu6JbQqMwwGRMQwboYFUaV9Rk4YJDPc oLWqOf6gt78rXe+pb1+MKSho9rgb8/j4Irp4z6n5JjRxMlpAN1E2sDCk4PwBiLefMXXd Aq1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5S91cuahyR49lp7zxZ/VCW3QVWjp/OTaxeEegQz3Tnc=; b=MFkUcs/wRUVDHgM3GcHwWoJ8vHDJABn0JTXSIs89XuG6Bf7CMx0/wxBl+wxx1olo0n V+p7RdWRRm7z/c+KV7eZoKxW2NIJx0VwjEELFaGf465hzx4ke8Yl3Zwg+Q7lBM3gAcge eOmVtfuFRLUdEoj4rIz6EXBP+Wat33wm0kLHCDnXpx0+Q5J05qC5KPwJMEQhvxeUzIms bEaLfhDEmBCUOGwKowSW+jih0S/RVs8IUzfMel3qY7wPCq4NBwmVWAhf1a3nbhnaypDh vDarqAtErIM9TyXBFHpij3JMP31E1NdkSp5ktSKo8VL8Y1BQEvKt3m9b22teZu5Dpy1G e2PA==
X-Gm-Message-State: APf1xPAgM2FtZcpcAFM9c0N+ag0XKDFIPREmikN6ZGn7AVhAfi+gIBnm PAEmSmKQfl9MEPH/H+DrZ381qa/dluvFFtf+jUtn0A==
X-Google-Smtp-Source: AH8x227ZWAVvUKbwDjGjgV27447PWIvJ3EQehSwhApi5K9t7jU+oae7MJAjkTnOHaoLwzrBtjHzla9MGQ+eccVg/cLU=
X-Received: by with SMTP id 42mr6372393wry.283.1518298774973; Sat, 10 Feb 2018 13:39:34 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sat, 10 Feb 2018 13:38:54 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Warren Kumari <>
Date: Sat, 10 Feb 2018 21:38:54 +0000
Message-ID: <>
To: Joe Abley <>
Cc: Andrew Sullivan <>, 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: Sat, 10 Feb 2018 21:39:39 -0000

On Sat, Feb 10, 2018 at 9:21 PM, Joe Abley <> wrote:
> Hi Warren,
<obviously no hats>

> I think the advice is good, but I wonder what the practical effect of writing it down would be. I doubt it would change any of the entrenched habits in enterprise systems and networking in our remaining lifetimes, for example, but perhaps I'm just being overly grumpy and am ignorant of some important dynamic that would change for the better.

Yup - hence my recollection that the document mentioned tilting at windmills.

> On the other hand if the goal is simply to try and ensure that future work product of the IETF doesn't depend on search list processing, perhaps that's worth writing down? If we are the intended audience and the document's purpose is to document a consensus decision, perhaps that's a reason to work on it.

Ok, that might be a useful thing to do -- documenting the issues
caused by search lists, possibly recommending against using them
(look, a windmill!), and that IETF technologies shouldn't rely on them
would be a good start. I'll try to find the original document - it's
possible that we never actually hit the submit button, Steve would
know. I don't think I have the time/ energy/desire to work on it, but
if others want to take up the pen...



> Joe
>> On Feb 10, 2018, at 15:21, Warren Kumari <> wrote:
>>> On Fri, Feb 9, 2018 at 10:55 PM, Andrew Sullivan <> wrote:
>>> Hi,
>>>> On Tue, Feb 06, 2018 at 12:50:18AM -0500, Ted Lemon wrote:
>>>> That's pretty clear.   This document is not forbidding the appearance of such names in the DNS, nor the resolution of such names.
>>> Instead, it is wanting to have its cake and eat it too.  Because…
>>>>   Note, however, that the admonition against searchlist usage could
>>>>   affect their resolution in practice, as discussed in Section 3
>>> …of the "admonition" (or whatever you want to call it).  In effect,
>>> the document requires special-casing of "localhost" as a label in
>>> every searchlist context.
>>> If the goal is to say, "The search list is evil, and should not be
>>> used," then say that.
>> <with no hats at all>
>> Interestingly enough, Steve Sheng and I wrote just such a document a
>> number of years ago (around the time of the initial name-collisions
>> drama). Even though I'm 95% sure it included the phrase "tilting at
>> windmills" my search foo fails me at the moment... but it basically
>> deprecated search list processing in the DNS.
>> There are many things which would be safer, less complex, and safer if
>> search lists didn't exist -- would people be interested in discussing
>> the idea, or is it just too out there?
>> </hats>
>>> Otherwise, what this document is _really_ doing
>>> is altering STD13's search list processing, to include special-casing
>>> of down-tree names.
>>> I think that is the case despite this bit:
>>>>       Application software MUST NOT use a searchlist to resolve a
>>>>       localhost name.  That is, even if DHCP's domain search option
>>>>       [RFC3397 <>] is used to
>>>>       specify a searchlist of "" for a given network,
>>>>       the name "localhost" will not be resolved as
>>>>       "" but as "localhost.", and
>>>>       "subdomain.localhost" will not be resolved as
>>>>       "" but as
>>>>       "subdomain.localhost.".
>>> The reason I think that is because of the earlier part:
>>>   2.  Application software MAY recognize localhost names as special, or
>>>       MAY pass them to name resolution APIs as they would for other
>>>       domain names.
>>> If you can just pass this to a resolution API, then it's actually the
>>> resolution API that needs to know to handle the search list rules
>>> according to this new specification (this part of the specification
>>> does not say that you can only use the API if you can tell the API not
>>> to use search lists, &c).
>>> I really do sympathise with the goal of the document, but I think it
>>> is making a bigger change than it seems to understand.  And anyway, I
>>> don't understand how the original 6761 text is the wrong approach:
>>> given that it isn't even being followed on the Internet today, there's
>>> no reason to suppose that this alternative approach is going to make
>>> things any better.
>>> Best regards,
>>> A
>>> --
>>> Andrew Sullivan
>>> _______________________________________________
>>> DNSOP mailing list
>> --
>> I don't think the execution is relevant when it was obviously a bad
>> idea in the first place.
>> This is like putting rabid weasels in your pants, and later expressing
>> regret at having chosen those particular rabid weasels and that pair
>> of pants.
>>   ---maf
>> _______________________________________________
>> DNSOP mailing list

I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.