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

Ted Lemon <mellon@fugue.com> Sat, 10 February 2018 00:21 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 927F3120454 for <dnsop@ietfa.amsl.com>; Fri, 9 Feb 2018 16:21:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 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] 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 iOqHWnwlHpgZ for <dnsop@ietfa.amsl.com>; Fri, 9 Feb 2018 16:21:10 -0800 (PST)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 A20ED120227 for <dnsop@ietf.org>; Fri, 9 Feb 2018 16:21:10 -0800 (PST)
Received: by mail-qt0-x232.google.com with SMTP id d14so12729506qtg.1 for <dnsop@ietf.org>; Fri, 09 Feb 2018 16:21:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/k2B5tS6YnazSmJluYCuTGUNSGfdksWkkKmt9rLso9A=; b=oewEbTqqLFYLF3eC10nMJnXpZtRRv0i02jKeWM2vdmcjHaVDBKRTm5AkOnGPZ/OYjY Ka2IB/g4qzUGeymvScpjVGGcQZUwh5fD3V7W1nfbfgFq0plCVDzM5FTp93JaSrF5SaJ+ yqu1mnikzn2i9B4rMW8ye0/ZKSvr9kbBjcTQQm0HPjbapdn9ZIaiRgFDN8IDGE+SvMAY QGtoU3YeXBOOtoX/61pdRAJqcRK6A5LGXUh/CAsIIb41sPFFU/SXZ78lcCheLaICsbf3 1HBb7uu6FxJAiS0Exz9vlTEMxkcsIp6iKS+I/bHhPZJRmxp2Aap7/bQ5RnZhAMGv48sS n4rQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=/k2B5tS6YnazSmJluYCuTGUNSGfdksWkkKmt9rLso9A=; b=NyptEEgJP0CcKOS89qZlCJIjeHfihs9QN+OXkQHyuXCpdCxmrL09SQcpmdbsAPVWj/ khUc0Uz4iLIaaQWFfXkLmFgJS292uceORJVuM7MNdCyEzsPFPSPYg42AC6PVSiBRGNhp zy/UADz0RHN3XG1v7QNE7f23ikxLGU7HpGTuJYEp0YH9oAUrAFqcEBGkcEYum46FZmUY 9GODdqJyprsobnreWmR8ij6501wHZaZJTOhvyxwOTRQ4y/eYo96JGe1j4lI4efXbAlii Y0tQkdpq4+DBwJT2v8oEHhWiYnZgjJanMme6hvyXt9Zv8aK65fLIawa5jrMifjSWOy1M QY6Q==
X-Gm-Message-State: APf1xPDp0Lbm0DbNwdhu4hSTdYHrTYZ1SHNLhhbCVjE92WjKoUNcIBKn pPufvGYwMBBOccFg8WP4gjLcxA==
X-Google-Smtp-Source: AH8x226BDqDMsUpQ8FqW8/eSj06hyi4SLjApKkYAaQ7RKZivijvjRh8LgIg4YVzGzqXIhXBMxVHFlg==
X-Received: by 10.200.23.21 with SMTP id w21mr4968591qtj.131.1518222069525; Fri, 09 Feb 2018 16:21:09 -0800 (PST)
Received: from [10.0.30.153] (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id x29sm2909957qtc.0.2018.02.09.16.21.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Feb 2018 16:21:08 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <CBC8CD1F-F6CC-4C2B-962B-121888F108A6@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_29F9E315-90F5-4743-8813-D9E19DDD280F"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Fri, 9 Feb 2018 19:21:05 -0500
In-Reply-To: <20180209225508.GC974@mx4.yitter.info>
Cc: dnsop@ietf.org
To: Andrew Sullivan <ajs@anvilwalrusden.com>
References: <2B1DC084-C6EA-41DA-9029-5E230874FCBE@isc.org> <29F25C57-31D1-4A07-875D-16E7612DB993@fugue.com> <E4C5AA7E-E9C1-4E53-ABE0-676A9B7B3269@isc.org> <618D31E1-8EC7-4F75-BD97-31D42CB1E681@fugue.com> <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>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Bim5gUq_flprkB9pjbCCSWxBrIU>
Subject: Re: [DNSOP] 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: Sat, 10 Feb 2018 00:21:13 -0000

On Feb 9, 2018, at 5:55 PM, Andrew Sullivan <ajs@anvilwalrusden.com> 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.

This is really fascinating.   To me what this code requires it something like the following, in any affected stub resolver:

resolve(name):
  if (name == 'localhost'):
    return [IPv4Addr('127.0.0.1'), IPv6Addr('::1')]
  if labelcount(name) == 1:
    for domain in searchlist:
     result = resolve_dns(labelconcat(name, domain))
       if len(result) != 0:
         return result
  return resolve_dns(name)

What is needed without this restriction, is either the same code, because it's what is obvious to any thinking person (kidding!) or:

resolve(name):
  if labelcount(name) == 1:
    for domain in searchlist:
     result = resolve_dns(labelconcat(name, domain))
       if len(result) != 0:
         return result
  if (name == 'localhost'):
    return [IPv4Addr('127.0.0.1'), IPv6Addr('::1')]
  return resolve_dns(name)

So to me there is no obvious architectural superiority to what you think is correct.   It's just a question of whether to test for localhost before or after the domain search list loop.   The standard you refer to currently says:

Relative names are either taken relative to a well known origin, or to a list of domains used as a search list.  Relative names appear mostly at the user interface, where their interpretation varies from implementation to implementation, and in master files, where they are relative to a single origin domain name.  The most common interpretation uses the root "." as either the single origin or as one of the members of the search list, so a multi-label relative name is often one where the trailing dot has been omitted to save typing.

So in fact what we are saying is completely consistent with STD13, in the sense that STD13 does not require some other behavior than what we are specifying.   It's true that behaviors that are allowed by STD13 are forbidden by this document.   That's the point.  What this admonition does is to remove an ambiguity in the specification, and for good reason.

Yet to you it appears to be self-evident that the second code sample is correct, and the first is "having your cake and eating it too."   Obviously you are seeing something here that I am not.   Can you point it out?

> 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).

Yes, applications may anticipate broken APIs and do the right thing prophylactically.   But APIs should do the right thing anyway.   Is that what you mean with the cake bit?

>  there's
> no reason to suppose that this alternative approach is going to make
> things any better.

Essentially what you are saying is that because existing name servers do not take advantage of this attack surface, there is no reason to remove it.   :)