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

Ralph Droms <> Mon, 06 February 2017 21:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4001C1295A6 for <>; Mon, 6 Feb 2017 13:46:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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] 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 yPViEP3AFKaC for <>; Mon, 6 Feb 2017 13:46:56 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 835F1129581 for <>; Mon, 6 Feb 2017 13:46:56 -0800 (PST)
Received: by with SMTP id u25so10500914qki.2 for <>; Mon, 06 Feb 2017 13:46:56 -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=SHLhiEweJR9xTVWOd7/sccJAdQDQoiVXOz3Fwp1KV5o=; b=eDE0zkZS1n/bgo+gKgM+4n4iKFJEiVWqxdB8geB3GQYvGxG6+122Nc2mdIZ7itYdfR yF//H/Zz23tH3aktPTbr0sP5JWl0040oJ2p80QrZkWhua32KTwX83rH+ibMH3X5/8dvP an3oAO5YAXHm44+Rfh1jNgH4rJXAt41ZDuGDX8DhG+G0zjgkUnHAQXsom+yxU2fXSjaL iAnl6iVNMxWxFrjUIBUIHjoYHSNyDDVbmC7WozO6D4PdRFqcLYLR4Cmhsg8PA1LfAstP FYmBYvW8P4/EpxLnzWWvQxsbh2bEFoNZZMY8mNlidqeuQAge3tsKGWOavB+nXmT0Tnhu qebw==
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=SHLhiEweJR9xTVWOd7/sccJAdQDQoiVXOz3Fwp1KV5o=; b=RPedgN0M4nsf/TQNi2WUmtU0d5/C8ID7W4qMu2OfexySvTKdcUlwW4vkkkLyTlYjSK GXIeB/7klmRpZvNYJWC8/0PHyISBsC6Fs+EzqCKQBXfxvhZHv88LTU0MxPdju+GBtTcQ E85+iEVhY5IMtsWBj6qm2n2PZwk1WObWzm3eOx1MbA0lGKBtVKCDjfuGLBk+spLWG30D LDP05a/viAn3DXARDvYt52m4+xlipEZ+CjroNQLdi7zBO9etNjHkXJKs2ur9GNeKjvhZ ZtXuKiLsRlWvFWBRlq6vXfLjilQkGGpQQJqMUzBOlwTtxB/wI7rpf8sQHO89qK7soBkO pGQA==
X-Gm-Message-State: AMke39krM5MPmgD04DjZpGiYlFy5ymgXqwWsQ9vSM+uXlu1CQaxp14sMaCkqtg6te4p+hw==
X-Received: by with SMTP id q128mr11052326qkf.220.1486417615688; Mon, 06 Feb 2017 13:46:55 -0800 (PST)
Received: from ?IPv6:2601:18f:801:600:7074:fbd6:4df:cdf7? ([2601:18f:801:600:7074:fbd6:4df:cdf7]) by with ESMTPSA id s20sm1572076qtc.39.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Feb 2017 13:46:55 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Ralph Droms <>
In-Reply-To: <>
Date: Mon, 06 Feb 2017 16:46:53 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Andrew Sullivan <>
X-Mailer: Apple Mail (2.3259)
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: Mon, 06 Feb 2017 21:46:58 -0000

> On Feb 3, 2017, at 9:10 PM, Andrew Sullivan <> wrote:
> On Fri, Feb 03, 2017 at 07:59:24PM -0500, Ted Lemon wrote:
>> Mark, I don't think you've actually given an answer to my question.
>> I understood that .ALT was for alternative naming systems, not for
>> DNS locally-served zones.   We simply need to decide whether or not
>> that's true.   I think either answer is fine; we just need to pick
>> one.
> I agree with this.  I will say that, when I first started working on
> this with Warren, it was really for the use-case where people would
> tread on the namespace as a protocol switch -- we wanted a sandbox in
> which things like onion could live.  My memory is that only after that
> did we start thinking of a sort of 1918-style part of the DNS as
> well.  That may have been a mistake, since as this discussion is
> showing the properties of an in-protocol, in-DNS namespace without
> delegations are somewhat different to alternative-protocol uses that
> do not rely on the DNS at all.

Andrew - I have come around to agree that the properties and requirements of non-DNS resolution mechanisms are different from those of DNS resolution that does not use the root zone as a resolution context.  I believe that these properties and requirements cannot be served by the single .alt delegation, so, in my opinion, draft-ietf-dnsop-alt-tld should specify .alt for use of non-DNS resolution mechanisms.

How to proceed with DNS resolution that does not use the root zone as a resolution context is open for discussion.

- Ralph

> Best regards,
> A
> -- 
> Andrew Sullivan
> _______________________________________________
> DNSOP mailing list