Re: [DNSOP] Search lists revisited (Was: WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

Ted Lemon <> Mon, 12 February 2018 17:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B97412D86F for <>; Mon, 12 Feb 2018 09:58:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-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 zzuikpdrOXUD for <>; Mon, 12 Feb 2018 09:58:36 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AD304126E3A for <>; Mon, 12 Feb 2018 09:58:36 -0800 (PST)
Received: by with SMTP id j21so6986055ita.1 for <>; Mon, 12 Feb 2018 09:58: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; bh=Yz3KhsyR/XkzXwc97iJuL09tkU/DEYkCkca/+S8mDY4=; b=huwmgq4orQaNbM/tk1W4xGu/LQ1OkoQ5HUcKYxDaF28JePMmOnSwMSBTm54YBOvEtP cEURf74t0zrdafH9EunVCpFKHwrw4/2llZcGYmMcvCyTyMhlbNSzSIkDjN5dpHky9MkZ O+a2FQ0h968akhC2tquZYiamLCZutyNPvR6w1zsBhYABhQj0bPuTyMADVNjJeK4f3N1Y IFxYEvpyukQuzd7Cp548VClNER1taxbWmJ/SWC67NmlyW7AsuSzLVx9h4UBUbns+Ger6 vWRqmQsoG5At8HY2nD7Q28CKGC1zAgIx37ReHfil9UyEaHwcnqfnF24Bl6tc9Hn6QLAd i79g==
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; bh=Yz3KhsyR/XkzXwc97iJuL09tkU/DEYkCkca/+S8mDY4=; b=bFN8qzhYLHje4ac7gP6gFnH92oVTP/IniTTTveQZ/GADA8rSeecSrMNc3e7S+UU/i4 DNhY9n3L4Bzh2/UU84cpaT3mrYGF3fxFptKQN8aLPnX0G4EuB2WFSz7jRufr1QJsLcFc NrCZJR9ZzsTMex5WuvpXSgRJpoxn90ll5DfNU8ui2fq7BRipTJd5Wa8wgc3CBhHhj3Y5 YakdzVqxouTEOOHQ0dePJVvIhm+K7sQLpdIV7VLyyHplCgdSk7NI314A71TjJ8IWhi/S /PhZ/x76eNf9otyupKpb++TUs6iyymf00Gcez2FU69Dlm+eHw42F1qEJmacRtfzwaG9V 4qWg==
X-Gm-Message-State: APf1xPCq3qcXvQZEX1ApZ1FoQf4y9+kfAyjTlK7qkp4hcR+00bbvlnVm bQBacFgaPOma016s00h8CDinrRsA0W9KxkvbEiDFtw==
X-Google-Smtp-Source: AH8x225u+TtMWJbHl3vrYCkXiGACHPSplFy/Q4M0FpMC6ZNNzHCcux9V7+XJnR8GYd0Hi8pp+ImP4lmTNrUO9jCTLt8=
X-Received: by with SMTP id s141mr6927150itb.13.1518458316003; Mon, 12 Feb 2018 09:58:36 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 12 Feb 2018 09:57:55 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: Ted Lemon <>
Date: Mon, 12 Feb 2018 12:57:55 -0500
Message-ID: <>
To: Paul Vixie <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="001a113f78c08831bd056507a08f"
Archived-At: <>
Subject: Re: [DNSOP] Search lists revisited (Was: 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: Mon, 12 Feb 2018 17:58:39 -0000

Of course you realize that there's a fairly obvious implication to what you
just said: "we need to write another document!!11!"


On Mon, Feb 12, 2018 at 12:51 PM, Paul Vixie <> wrote:

> Stephane Bortzmeyer wrote:
>> that might be a useful thing to do -- documenting the issues caused
>>> by search lists [...] and that IETF technologies shouldn't rely on
>>> them
>> That's certainly a better proposal than the initial one (banning
>> search lists).
> there's a huge unspecified middle and edge of dns, which is the
> presentation layer. even with RFC 1535 for "ndots", there's nothing that
> tells an endpoint how to interpret unqualified or partially qualified names
> -- or how to display them. IDN made this lack of specification even more
> obvious by not outlawing the other glyphs that look like . or /. BIND was
> certainly wrong to use RFC 952 to determine what a "hostname" was and to
> apply that restriction to A/AAAA owners and MX/SRV/NS targets, but there
> was no better specification available.
> However, I wonder if it is really IETF business? It is a local
>> decision, after all.
> RFC's 1535 and 2292 show that endpoint behaviour, not just signaling, are
> in-scope. the IETF needs more work of this kind, since the norms everybody
> is violating (mostly without realizing it) turn out to be important to
> interoperability. that is, partially qualified names and unqualified names
> are a layering violation, not unlike putting an RFC 1918 address into the
> FTP "PORT" verb.
> paul mockapetris sometimes tells the story of how auto-completion was the
> motive for writing names with most-local on the left and most-distant on
> the right. my counter-observation is that when the DNS consisted of a dozen
> large sites each full of similarly named "hosts" that must have made more
> sense. now that most of the names most of us look up are not local and not
> of "hosts", the situation has reversed: auto-completion of .org.redbarn.www
> would be far easier to implement than of
> ted's arguments about the insecurity of "localhost" lookups are one tiny
> corner of this land-mass sized lack of presentation-layer specification. it
> turns out you should never put an unqualified name on the wire since the
> days when your RDNS did search list processing for you are long gone, and
> it turns out that "localhost" should never have search-list processing
> applied to it. those two "turns out that"'s add up to a hard requirement to
> implement localhost-to-address and address-to-localhost lookups in the
> presentation-layer side of the stub resolver, except, we don't define a
> presentation layer, so we can't.
> --
> P Vixie
> _______________________________________________
> DNSOP mailing list