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

Ted Lemon <mellon@fugue.com> Mon, 12 February 2018 17:58 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B97412D86F for <dnsop@ietfa.amsl.com>; Mon, 12 Feb 2018 09:58:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzuikpdrOXUD for <dnsop@ietfa.amsl.com>; Mon, 12 Feb 2018 09:58:36 -0800 (PST)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD304126E3A for <dnsop@ietf.org>; Mon, 12 Feb 2018 09:58:36 -0800 (PST)
Received: by mail-it0-x233.google.com with SMTP id j21so6986055ita.1 for <dnsop@ietf.org>; Mon, 12 Feb 2018 09:58:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; 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; d=1e100.net; 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 10.36.67.147 with SMTP id s141mr6927150itb.13.1518458316003; Mon, 12 Feb 2018 09:58:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.79.241.202 with HTTP; Mon, 12 Feb 2018 09:57:55 -0800 (PST)
In-Reply-To: <5A81D404.6010304@redbarn.org>
References: <40992CF7-5740-43ED-8B78-8D8A9B50A15C@isc.org> <F28D0F1D-416E-4016-8A5A-95173FFFAA4E@fugue.com> <CANLjSvVd+vj8M+vBOokfpOL1fmq2iU9JAhSCd6eY_aoE1p5SMQ@mail.gmail.com> <97783B49-11C9-47F1-8F73-3D909C9B4DC4@fugue.com> <CANLjSvUV1RPR8nhLXCEL0WT9=2Lqb+4STh+7gSRPvv_Mmf-NTA@mail.gmail.com> <698033B2-09A6-4E66-82AD-04906D4DEA1B@fugue.com> <20180209225508.GC974@mx4.yitter.info> <CAHw9_i+OhMckTx5rniXTJJHXZXHtHt8wYO2XU9_kCmdW+nswfg@mail.gmail.com> <78DB0408-9870-4855-936A-3C4774B2CDE7@hopcount.ca> <CAHw9_i+6BPECPByUDzMx07tX4zMSK5RZ5+HPiS67_vOVjjnzMQ@mail.gmail.com> <20180212111201.iogcwngobam44joh@nic.fr> <5A81D404.6010304@redbarn.org>
From: Ted Lemon <mellon@fugue.com>
Date: Mon, 12 Feb 2018 12:57:55 -0500
Message-ID: <CAPt1N1=wrtuBY6hz_ruKLydK9Sf2FHnNAt1aBq9e0mt=0X4swA@mail.gmail.com>
To: Paul Vixie <paul@redbarn.org>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="001a113f78c08831bd056507a08f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qUMV_wtNNSVlcR3CDaIRht1Q8Rc>
Subject: Re: [DNSOP] Search lists revisited (Was: WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=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 <paul@redbarn.org> 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 www.redbarn.org.
>
> 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
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>