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

Paul Vixie <> Mon, 12 February 2018 17:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE673126E3A for <>; Mon, 12 Feb 2018 09:51:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PYG017miIkR5 for <>; Mon, 12 Feb 2018 09:51:05 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4D7D81201F2 for <>; Mon, 12 Feb 2018 09:51:05 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 54D3E7594C for <>; Mon, 12 Feb 2018 17:51:03 +0000 (UTC)
Message-ID: <>
Date: Mon, 12 Feb 2018 09:51:00 -0800
From: Paul Vixie <>
User-Agent: Postbox 5.0.22 (Windows/20171208)
MIME-Version: 1.0
To: dnsop <>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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:51:07 -0000

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