Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

Brian Dickson <> Tue, 21 March 2017 01:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 507BE12943C for <>; Mon, 20 Mar 2017 18:50:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T_ySz1yOnWfH for <>; Mon, 20 Mar 2017 18:50:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3E968129439 for <>; Mon, 20 Mar 2017 18:50:23 -0700 (PDT)
Received: by with SMTP id v127so125087441qkb.2 for <>; Mon, 20 Mar 2017 18:50:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5zADRaR1oCF6EodQAeIIv67aAhj9F+/kJnwH3PD0U4U=; b=f1LZJKAkSnMvt9hZhqM+NfNLiD+vqv415S6UysS5YVQFaMSGa6KHF4huaUrBaU+im4 d74+ok7Ry4vPWPRTrW4tHZPOn+ldVkOOaU+aUQuHeW/rhnwWjPsvwaaEp3MLkirnbKW2 6F9Yj13r4Wi9vr5W+knovpISPOgQpwCX8tjm9mRiyDdfIQcwaamIdJsPawsPE81DROWy bkIQAwzmt4mZixYBMeOdSaqTei8wkRLIEm9RGqAZb7zY01qGgqci8YSVnx7/PeXIfo42 dBOeVArT3DAWKJTyiR5mEQINUXDgKNKfq2/2lKKsyiY2eiHjCaCeboAntYfYD5WuPhzB pOEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5zADRaR1oCF6EodQAeIIv67aAhj9F+/kJnwH3PD0U4U=; b=nW3FRsq3bqa3uuiZ3mr5atxrnFb6y2lbqzv0XMnTNb5sCj5yqL8z/6nUajXmCoZCeM XjiHmItoTGGrFR1tKzbNNJJq7eoSQdKrJclppW5S0tEm2dJ1ySLEqNldOjX57pArovPh pT4cxLpy2S/bbedaDiBO9+4a7GTajp/XnQWqbvz+9Dg4uVZ9e0vH5is4/SViohTcQ6Vo WoMcDoNfn63Si0Q3f8FDqWjYDIRik0QNQ15+uCovhn7LHroC6WlCHfW5FPefisi4mk1f vAwn+tW0xDzIf2ukvbEV4xTXCOjQQ4rlJrcvVxOKDbSq2nH92ukcjs/qO6Dd3nS/3kfR vLow==
X-Gm-Message-State: AFeK/H2jd/dF3bpdhz5gk3byjB4bZ0o1ch4VB+gFgDCsKpfMSy4glVL/vXe7UC2LEFJp6Z5GgHeBjZWcZorUCg==
X-Received: by with SMTP id o74mr29290950qkh.288.1490061022349; Mon, 20 Mar 2017 18:50:22 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 20 Mar 2017 18:50:21 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Brian Dickson <>
Date: Mon, 20 Mar 2017 18:50:21 -0700
Message-ID: <>
To: Ted Lemon <>
Cc: " WG" <>
Content-Type: multipart/alternative; boundary=001a114446e2ee5250054b33dd8d
Archived-At: <>
Subject: Re: [DNSOP] WG review of draft-ietf-homenet-dot-03
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: Tue, 21 Mar 2017 01:50:25 -0000

Just to follow through on my thought(s) on this... (thought in-line below).

On Mon, Mar 20, 2017 at 6:25 PM, Ted Lemon <> wrote:

> I'm curious what Russ and Steve think about this as an alternative.   It
> seems a bit byzantine to me, but I can't say that I object to it on
> principal.   It does create a lot of extra work for ICANN, though, and it
> would be a bit more brittle than just doing an unsigned delegation: we now
> have to have some way to get current versions of these signatures into the
> homenet resolver.

Given that hypothetically this would not be published in the root zone,
there are ways to make this less brittle or expensive.
(Apologies in advance to anyone who might sprain their eyebrows.)

Technically, it is possible use the KSK instead of the ZSK in generating an
This would alleviate the temporal nature of validation from ZSK-derived
RRSIGs. (Continue reading for why this matters.)

And also technically, an RRSIG can have a nearly-arbitrary validity period,
up to 68 years.

So, if ICANN were to agree to do so, they could provide a long-lived RRSIG
signed directly by the root trust anchor, aka the KSK of the root zone.
This would validate for however long the RRSIG's validity period is, or
until the KSK rolls.

This would require an update every time the KSK is rolled, or whenever the
RRSIG needs to be refreshed. 68 years is an inconvenient interval, so maybe
50 or 20 years? This is still a lot better than 1 week or 1 month.

The question of how to publish this is orthogonal; perhaps some existing or
new RRTYPE, at some well-known place in the DNS tree, maybe under ".arpa"
somewhere convenient? Ideally also DNSSEC-signed.

Just suggesting something that is technically feasible...


> Further comments inline.
> On Mar 20, 2017, at 6:08 PM, Brian Dickson <>
> wrote:
>    1. What is required for the above, is generation of DNSSEC records
>    including RRSIG(NS), NSEC, and RRSIG(NSEC), for "homenet" TLD.
> Yes.
> Since the queries are never meant to reach the root servers, the presence
> or absence of "homenet" in the root is mostly moot.
> Sure.
> The only technical requirement is that suitable DNSSEC records be
> generated, and that the special-purpose homenet DNS resolvers are able to
> have up-to-date copies of these DNSSEC records.
> Sure.
> As a technical matter, this does not require publishing these records in
> the root zone, although that would be one way of achieving the necessary
> requirement.
> True.
> Perhaps the homenet WG folks could talk to the ICANN folks about ways of
> accomplishing the above, without the need for publishing the unsigned
> delegation in the root zone?
> Strictly speaking I think this is something the IESG would have to do.  I
> don't object to this as a solution, but operationally I think it's a lot
> more work.   It may be that it's worth doing it, since it might be
> applicable to other special-use name allocations.
> The benefit of not publishing, is that any queries that do hit the root
> servers, would get a signed NXDOMAIN, which IMHO is a more correct response.
> Yes.   I'm not sure that's enough to justify the extra work.