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

Andrew Sullivan <> Fri, 10 February 2017 17:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 64AE6129A64 for <>; Fri, 10 Feb 2017 09:31:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=XVgT5sDF; dkim=pass (1024-bit key) header.b=HVQjynzx
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mXhp5vJkcjPI for <>; Fri, 10 Feb 2017 09:31:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2F972129A5B for <>; Fri, 10 Feb 2017 09:31:28 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 80472BD554 for <>; Fri, 10 Feb 2017 17:31:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1486747887; bh=8LNT99nLpPTub95unaQb4yqCWPgcI5X+3X4yJUsCXYI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=XVgT5sDFbJRgYWTc7HlHE2SBOowheKZZr3UzBEKn6UrnGdvZ1tpViYvFkP5RQeRQT YRW9uaqN4UjM3htOqafELEafwHdF9ozQUyUkxhk7aCrxkeIvrHhCmV30iTrRvAFiUv ChhewKDoxBW5j9oW5OvqWD3LbgE/jTF3MuuMwmaY=
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hdc0zMfMwKZ9 for <>; Fri, 10 Feb 2017 17:31:26 +0000 (UTC)
Date: Fri, 10 Feb 2017 12:31:24 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1486747886; bh=8LNT99nLpPTub95unaQb4yqCWPgcI5X+3X4yJUsCXYI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=HVQjynzxx1ZP6bsk+5C2h3xqSt/Rw2dL2fvAne7ebUOMOEf1+cdV7OJmcKVPcr35a L9vNL+NWybVztoja0KhZbm7n57PTmVBqBAcR7V7HXkfPnzF93Dic/Len72t9f5stFm q0z5Vn2gt1htKFzl+W0F0CLroIJZZSM5ZGFfRCKQ=
From: Andrew Sullivan <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
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: Fri, 10 Feb 2017 17:31:29 -0000

On Tue, Feb 07, 2017 at 10:01:23AM -0500, Bob Harold wrote:
> What I envision for the future is an insecure delegation of .alt, and an
> option in future cable modems to enable a local "homenet.alt" domain, which
> would just work, even if some stub resolvers in the house are validating.
> The cable modem is already a recursive resolver or forwarder, and dhcp
> server, so it seems a logical place for the local domain.

No, it won't just work if a stub is validating, because the validating
stub will want to validate the delegation from the parent, and that
will be a proof of non-existence.  Provable non-existence prevents you
from being poisoned through typosquatting, but it means you can't
inject things in the tree without co-operation from the parent.

This is part of why I don't want to extend alt this way, and the more
I think about it the less desirable it seems to me.  We have a
particular problem: non-DNS-protocol switching for applications that
want to use a DNS-compatible domain name slot (see RFC 5890).  This is
problems like onion, local, and so on.  We propose a solution in which
we steal four of the available 255 octets to create a "safe" space
from DNS delegation.  Now anyone can use that space for their non-DNS
protocol, and every resolver library in the world knows that if it
runs into a name in the alt tree it shouldn't need to look it up in
DNS.  If the query leaks to the root and gets a proof of
non-existence, it doesn't matter because it was supposed to be a
different protocol.  Non-existence in the DNS is analytically true.
If a validating resolver gets an answer back from another resolver
that provides NXDOMAIN without the proof of non-existence and treats
the result as bogus instead, who cares?  It was never supposed to
resolve in the DNS anyway.

The homenet case is different, because it _is_ supposed to work with
DNS.  In that case, the missing proofs are a problem for validating
end points.

Best regards,


Andrew Sullivan