Re: [DNSOP] ALT-TLD and (insecure) delgations.

Brian Dickson <> Tue, 07 February 2017 07:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC9EF129A9A for <>; Mon, 6 Feb 2017 23:08:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, 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 aJcX4TdlUVY0 for <>; Mon, 6 Feb 2017 23:08:23 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5A2FF12009C for <>; Mon, 6 Feb 2017 23:08:23 -0800 (PST)
Received: by with SMTP id v184so36167319pgv.3 for <>; Mon, 06 Feb 2017 23:08:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FwP9pv9PZbmBUGvXgCCsAzbT4PtGnozBtnm2ljZSq0s=; b=jgs3I4TrKh7yFBG+v3VaoqA6LxIoQkJ6CM/aVXyyKA1MA1KAcwKoGhGLvy9Z5EknPp dK22u2tzlAAU2u4/F8cSTd6w30fiXTiNOrB6gDihiXlJghP7mtYEzG2LLjY6Q+Ajg1rj F6u6DMUN/SuR17YFTTReGZz2ibLzartw8hyuQP+uC7WxTx5M//q4C6bjd9ng+Eq21Bjs iO/9HjJgQr7HoWf7TYAMD7OFipKzbECFGXDK8LNgd47SPYNjmtGlpzuxQfcYxqxSX+n9 KcxSvWyvFmb9iQXshEucej52S+Z0QIc5GkOjHcesnIjum2JMbuZmfIhVZCyq7/d9kvNo eJFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FwP9pv9PZbmBUGvXgCCsAzbT4PtGnozBtnm2ljZSq0s=; b=U0jA921D+LU/dVLbj8uenzw26wg5XCDyuVvl4ES7lqdYxlThGvAukmveEgQkwKsVnW /qDFN1AC9qHgIBPYwPX7lGg/dC0dn1xDhxAzNdLH7oA99Qo6w8LYo3vdIB7ENI/MU24V Wbca37iEa3BjNkVUQi0dnQcWSbR9IBBW/nq/7nAb+6szHup7HOdYwXKE3PFC5KMGhT67 fVogKTyjXrovImFAZhzlGUpTR1af2qIwwFXn+8fT+wlOeRm76BxL+dQ0b461RONHmD3Y Pjcv/u6cXxDkVy3yGeLct16m6oED5r2UrrKrvdwGippc/XWxzGGf+1rr8t/WfPdnUDx2 Lpvg==
X-Gm-Message-State: AIkVDXIH1rnJP2dlwNsDpbn7zNXvD10iXScjUMU7uleJFaBv5HCmvr2Hnc8l+iAZe286kA==
X-Received: by with SMTP id y7mr23336871plb.60.1486451302850; Mon, 06 Feb 2017 23:08:22 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id g64sm7902493pfc.57.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Feb 2017 23:08:21 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Brian Dickson <>
X-Mailer: iPhone Mail (14D27)
In-Reply-To: <>
Date: Mon, 06 Feb 2017 23:08:21 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Mark Andrews <>
Archived-At: <>
Cc: " WG" <>
Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations.
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Feb 2017 07:08:25 -0000

The suggestion of DNAME to involves some subtle details, which IMHO may in combination be the right mix here.

The DNAME target is an insecure empty zone.

This avoids the validation issue, and facilitates use of local "alt" namespaces.

The default response to queries under alt would be unsigned NXDOMAINs.

I am not seeing a problem with this.

Am I missing anything?


Sent from my iPhone

> On Feb 6, 2017, at 10:31 PM, Mark Andrews <> wrote:
> In message <>, Brian Dickson writes:
>> Mark,
>> I don't think the use cases for most of the sandbox involving alt, and/or
>> the homenet use case, requires support for validating stubs. If stubs
>> aren't already validating, the incremental addition of a local alt, only
>> requires distribution of the trust anchor to the resolvers. That is a
>> solvable problem for most values of "local".
> It's not just stubs.
>> If use cases for non-local or validating stubs exits, IMHO that rises to
>> the level of requiring something real, not an alt name.
>> If you think that is something that there is a demand for, I don't know
>> if it might belong in a separate domain.
>> An insecure delegation from the root may be seen as an invitation for
>> exploitation by squatters.
> And if they could find a way to squat here (which requires intercepting
> queries) what would be the problem?  We are expecting the namespace
> to be squatted.  Thats the whole point of the namespace.  In fact
> we are going to tell nameserver vendors to squat on .alt by default*
> to generate the NXDOMAIN responses.
> There is absolutely no need for a secure NXDOMAIN here.  Just as
> there is zero need for secure NXDOMAINs in COM, ORG, NET or any
> other gTLD.  The gTLDs prevent secure delegations being spoofed
> away.  The don't prevent names being spoofed into existence between
> the secure delegations.
> There is absolutely no need for a secure delegation here.
> I have not seen anyone demonstrate a technical need for a secure
> delegation for alt.  There are no formal delegation in alt so there
> can be no secure delegations from alt.
> Mark
>> Sent from my iPhone
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: