IETF Logo Mail Archive

Re: [DNSOP] Status of "let localhost be localhost"?

Jacob Hoffman-Andrews <jsha@eff.org> Wed, 02 August 2017 17:24 UTC

Return-Path: <jsha@eff.org>
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 8AE31131FC0 for <dnsop@ietfa.amsl.com>; Wed, 2 Aug 2017 10:24:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.002
X-Spam-Level:
X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org
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 dCs0zbaxww7s for <dnsop@ietfa.amsl.com>; Wed, 2 Aug 2017 10:24:05 -0700 (PDT)
Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2724131E9F for <dnsop@ietf.org>; Wed, 2 Aug 2017 10:24:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=KlMoKDcll+xxxVPuZ4k9hoRTp4zC+wLscyFRz4yKSFA=; b=hvD9Uqs+i5/Q69nWWvzsSnjhcjMJ+GKYxQ2NYAPuVDdxQICbowHlj5KYM30gFqlMurXbu8CIdASt9rv1HkZSm5pYHDovLHwnyI4UszGOuIIRoLMH9hiSRGJSjQNlnT863v/VhN+WmjTTmYkmatO1J6L3i2f2t8lOf42l0umM9lE=;
Received: ; Wed, 02 Aug 2017 10:24:04 -0700
To: Mark Andrews <marka@isc.org>
Cc: dnsop@ietf.org
References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <CAKXHy=ctB=LZkX9j=8-Jy0NkTAs2tAesa4gmFhfp94O5=9U4TA@mail.gmail.com> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <20170802012345.2CE2680BCC5E@rock.dv.isc.org>
From: Jacob Hoffman-Andrews <jsha@eff.org>
Message-ID: <121adcc6-55c5-4f90-2797-999f3f1f1ef8@eff.org>
Date: Wed, 02 Aug 2017 10:24:05 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <20170802012345.2CE2680BCC5E@rock.dv.isc.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Received-SPF: skipped for local relay
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DDkM2WfLRkf3HD1HV0jSxztlwLw>
Subject: Re: [DNSOP] Status of "let localhost be localhost"?
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: Wed, 02 Aug 2017 17:24:08 -0000

On 08/01/2017 06:23 PM, Mark Andrews wrote:
> The query for foo.localhost doesn't need to hit-the-wire for this
> to be a issue.  Ask your self why RFC 6303, Security section has
> 
>    As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
>    namespaces, the zones listed above will need to be delegated as
>    insecure delegations, or be within insecure zones.  This will
>    allow DNSSEC validation to succeed for queries in these spaces
>    despite not being answered from the delegated servers.
> 
> or draft-ietf-homenet-dot-10 is doing the same thing for "home.arpa".

RFC 6303 says "as DNSSEC is deployed within...". There's no plan to
deploy DNSSEC within .localhost, because it doesn't make sense there;
all resolutions should be handled locally.

> We didn't add the requirement for insecure delegations for the fun
> of it.  We added it so that the tools that validate will not break
> when those names are being used.

Can you tell me more about what type of tools you're thinking of here?
Are those tools expected to handle "foo.localhost" domains? If so, what
do they currently do with such domains?

To put it another way: is your concern about new potential for breakage
under this draft, or are you saying that there is existing breakage that
we might as well fix as long as we are touching ".localhost"?

v2.23.0 | Report a Bug | By Email