Re: [DNSOP] .arpa

Ralph Droms <rdroms.ietf@gmail.com> Thu, 23 March 2017 18:11 UTC

Return-Path: <rdroms.ietf@gmail.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 5935D12965D for <dnsop@ietfa.amsl.com>; Thu, 23 Mar 2017 11:11:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 BRTfdPW0kLUJ for <dnsop@ietfa.amsl.com>; Thu, 23 Mar 2017 11:11:22 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 283DD129B15 for <dnsop@ietf.org>; Thu, 23 Mar 2017 11:11:21 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id p64so187532231qke.1 for <dnsop@ietf.org>; Thu, 23 Mar 2017 11:11:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PH++b1YOY3Ga7dyGJk7V2bhDDFthzzlZ3u6gMcw2JS4=; b=cU8Nr5P3D7zYnlnZ3OoIo/fhnwWQCu7a29Sit7bGoXg3EQpmNHoF8wHGSmzQ+NPJOF 4NjwAHDutjvPP/Ep5U4yI6Xdn6Xq8Q3OFw2nPWci8Di7n7+JhwjZe3Uanywl1wYIN0UM 1BGkXyHyJiVI6PEgyom09+/anVILRUbi/EizLrLIJa/CdxT5mmlRPJ+1mC/mjLpt/4mJ lkTz+JUSqQgjzOhsNUIvTleXoOI7NEn6QINcV6Vxv3ed17Dx1tKC3erHDlqRvQH085Z9 9WORZX60SjwEoVkUkU/SbfslCxSK/ZB6lMk8QxbWClrFLIidf72206gu5rL9tDqYjEic Co4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PH++b1YOY3Ga7dyGJk7V2bhDDFthzzlZ3u6gMcw2JS4=; b=pMdz3V4TiTQe6QjK4nMA3N+ed4e24OyLqW52r5w9aH1r9vdBNTrMmi1rxQiRJaYDGa 9WuKQz3pBRkpKHa2lMxBpwqvF5jxD3EetqkaCOZJ6JvNS3tP139lAeEDb7S7BRqfkzLk nmwZec11vxnfXfq5TYJ+zxFhbdcrnPTxejE6warAZrQYFlJXM1Uo4K6G+yKYZ+rra2Vf xodBAtScuzVHK+pn9VJObBKU7RfYfPwx09LphDFbUDHC+Z7xueKq+0Ce6v3lwiQVp7+K WcYMNS0/7JiNqfn0aj/pHNX/F+KBxI9LZx8HlNczyBO3n0f9Iq9wnDMJAETFR//EGYkf FdLg==
X-Gm-Message-State: AFeK/H27LqgJvo6ygCf0YY/W9JBsHYFejgY1XNojrLHZ5JVNqjgW15uHySI98Js0b7WGNg==
X-Received: by 10.55.54.76 with SMTP id d73mr3437581qka.307.1490292680125; Thu, 23 Mar 2017 11:11:20 -0700 (PDT)
Received: from ?IPv6:2601:18f:801:600:65d4:518c:a8e7:5d72? ([2601:18f:801:600:65d4:518c:a8e7:5d72]) by smtp.gmail.com with ESMTPSA id y52sm3725307qty.60.2017.03.23.11.11.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Mar 2017 11:11:19 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Ralph Droms <rdroms.ietf@gmail.com>
In-Reply-To: <47548136-78d7-8c53-462e-62439d6194ac@bellis.me.uk>
Date: Thu, 23 Mar 2017 14:11:17 -0400
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <360B2807-049F-4707-95FE-AA279C583884@gmail.com>
References: <20170323042741.79108.qmail@ary.lan> <2C6B4EB6-D0F0-44A8-95E4-68DF32244639@fugue.com> <20170323163205.GD19105@mx4.yitter.info> <500af1ed-5425-4452-ad8e-c2d511ee738d@bellis.me.uk> <850A8729-8762-4375-90EF-50CDF4AC232E@gmail.com> <47548136-78d7-8c53-462e-62439d6194ac@bellis.me.uk>
To: Ray Bellis <ray@bellis.me.uk>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/68eJUeuM5KQfO4j8MwO4Mp6Atdk>
Subject: Re: [DNSOP] .arpa
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: Thu, 23 Mar 2017 18:11:24 -0000

> On Mar 23, 2017, at 1:50 PM, Ray Bellis <ray@bellis.me.uk> wrote:
> 
> 
> 
> On 23/03/2017 10:34, Suzanne Woolf wrote:
> 
>> I’m trying to make sure I understand what the special use reservation
>> accomplishes in the absence of the insecure delegation.
>> 
>> If I read your comment correctly, I can infer two things about the
>> protocol, whether the insecure delegation is delayed or refused, at
>> least in the short term:
>> 
>> 1. The protocol is sufficiently functional for deployment without
>> working capability for DNSSEC validation.
> 
> Correct, in so much as "the protocol" is actually "DNS".

No snark intended, but if "the protocol" were really just DNS, we wouldn't be having this discussion.  Rather, it is the DNS wire protocol using a local resolution context rather than the root zone.  In any event, yes, the locally server homenet zone can function with DNSSEC.

As I see the situation, a problem arises if there is a requirement for DNSSEC at some point in the future, and ".homenet" is found to be unusable as the special-use domain name.  It would be unfortunate to deploy devices with ".homenet" now and find that needs to be changed in the future.

> 
> The HNCP protocol is only used to configure the domain name used for
> local resolution, but Homenet's zeroconf nature requires that there be a
> default value, and as such Homenet / HNCP is not fully deployable
> without an agreed default.
> 
> The presence of ".home" as that default in RFC 7788 was a mistake, and
> the current pair of drafts is our attempt to rectify that.
> 
> Hence w.r.t Matt Pounsett's argument that the -redact document go first
> and then the assignment of ".homenet" be done later, the Homenet WG has
> argued *very* strongly that this is not acceptable because it leaves
> HNCP in an indeterminate state.

On the other hand, not publishing -redact now leaves ".home" in an indeterminate state in an Internet Standard, for example relative to the TLD assignment process in ICANN.

> 
>> 2. Having a single-label name is more important for the functioning
>> of the protocol than having DNSSEC validation work.
>> 
>> Is this a fair assessment of the WG’s view?
> 
> Not quite - DNSSEC should work correctly on any Homenet resolver which
> has the appropriate trust anchor configured.
> 
> The insecure delegation is required to allow validating stub resolvers
> in hosts to access .homenet names without the signed proof of
> non-existence that's currently in the root from getting in the way.
> 
> Since those validating stubs are currently exceedingly rare, we can live
> without that insecure delegation _for now_.

Again, I'll argue that "for now" is a potentially problematic way of looking at the issue, considering there may be several years of deployment between the selection of .homenet as an SUDN and determination of whether or not the necessary entry in the root zone can be added.

- Ralph

> 
> Ray
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop