Re: [DNSOP] Please review and provide feedback -- draft-stw-6761ext

Warren Kumari <> Fri, 23 August 2019 21:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1966612011E for <>; Fri, 23 Aug 2019 14:18:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 2KTnnfsDjFQz for <>; Fri, 23 Aug 2019 14:18:54 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D24DA12009C for <>; Fri, 23 Aug 2019 14:18:53 -0700 (PDT)
Received: by with SMTP id v38so12622305qtb.0 for <>; Fri, 23 Aug 2019 14:18:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tpAut3bWwa2ygM8qViEfOHV6ec3vyu3GhZ1wZjOLp2I=; b=TF2Ag6cryXnBPTtgZ1OPeAV7WscM5X2MF/XVm+NTTp3QzdAWo9EDhb0AJoDWhozng0 bgVhGEuCQx2v+In8JG7B7V/yhMjLQNRONOgJBp4odpcRZH1yJ1DdjmBT6AdYoG/scPPr Z7IyoZW2bNcmlJUOe8NkCMbwNJg2C4u5GJMJXJyBQHk38CBAELZ6GdQc6KDYc7uBO9VH Dw/MGOxP9MW4r+D0/2eUBHeqrLBeiy6fGUB7ysNI9I6YzxhJxoTiRcDaP4jBnQMfxTTh crbqqJk6OY0GL6T4AfUv8vCDezRbws7ABFbk6KQWN6y3LhDveKrnWa+HiXnLFGcS3rw+ JhSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tpAut3bWwa2ygM8qViEfOHV6ec3vyu3GhZ1wZjOLp2I=; b=V1sdfwVLvzIaM5uff5zJIawuKnbp6taNlGor87I2k66iJsfZmHYL7zKMVk9OWGM3Vn eF6FvKULw3cGg2Yjvt9MMSgAs2R0AnaKiseWHKDNQpjaaYicJUWEHLC17l7bZuc85/eI 9+JRRwAQve0mV44X64UxfiEQn544ZmV+tqYYfdEfgAP94GV0ZYY/XCAW8jYg2FqKF9gG 9pVRbYBfueBcWtY4Jz39IXlPYGXm200GSQHq8EfFbB1GxqhBqQCQ6yWBTDkQ8FsPKu9q IofxzHzGSImimqloHAgNrr8/bij50JlX1nH+pFQjh4LJTYNA3RbWBNVGwiNMDdsSQypb /v7Q==
X-Gm-Message-State: APjAAAWgqgnEktpwL/vZlCmzWVSYcnKmBa7a4Szaf1e4WHsFS9sq5GWV 96UrdML3+2l+qipYf7Xw+eEpyFPqt8YDBYXHhs0fLA==
X-Google-Smtp-Source: APXvYqwA2p7InVbNYHq7w5t/Jp2RSrc+bFDSkXQ+WpgBeIt3taU65VKIbTaU0ddlJ9coxIAQoBrsrdKPqkqqKzdegtA=
X-Received: by 2002:ad4:424e:: with SMTP id l14mr5749494qvq.150.1566595132157; Fri, 23 Aug 2019 14:18:52 -0700 (PDT)
MIME-Version: 1.0
References: <> <20190818182935.F172A87452C@ary.qy>
In-Reply-To: <20190818182935.F172A87452C@ary.qy>
From: Warren Kumari <>
Date: Fri, 23 Aug 2019 17:18:16 -0400
Message-ID: <>
To: John Levine <>
Cc: dnsop <>, Suzanne Woolf <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [DNSOP] Please review and provide feedback -- draft-stw-6761ext
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Aug 2019 21:18:56 -0000

[ No hats!]

On Sun, Aug 18, 2019 at 2:29 PM John Levine <> wrote:
> >So it would be helpful to know if you think the recommendations are in fact reasonable.
> I think they're reasonable but I would more clearly distinguish cases
> by where the protocol switch is, where I think these are the
> interesting ones:
> 1. Names handled totally unlike the DNS with nothing like an IP address (.onion)
> 2. Names handled through mutant DNS which can returns IP addresses (.local, .localhost, .homenet/
> 3. Names that have other problems such as conflicting prior use (.test, .example, .invalid, also .home, .belkin)
> For 1, we can reserve if if there's a compelling argument and evidence
> of clear use.  This leads to a catch 22 where the only way to get the
> evidence is to squat on it, but I don't see any way around it.  I
> particularly do not want to reserve names just because someone claims
> to have a great plan.  I think this probably includes Warren's great
> plan for .alt.

... hey, that's my cue!

.alt was discussed at IETF 105, and it sounded to me like was good
support for progressing it / discussing it again.

A quick recap for those who've managed to swap out state on this...
"This document reserves a string (ALT) to be used as a TLD label in
non-DNS contexts.  It also provides advice and guidance to developers
developing alternative namespaces."

For all sorts of reasons (compatibility with existing apps being the
main one!) people building alternate naming systems (like .onion, the
GNUnet naming system, many of the blockchain-based / type systems)
want to use names which follow the DNS convention. This means that
they can and do leak into the DNS - for example, if I send you email
with a link to https://facebookcorewwwi.onion/ and you don't have a
TOR browser / shim you'll end up asking the DNS. This ruins much of
the privacy they should be providing (and also being annoying :-), and
also leads to the possibility of collisions.

As John says, there isn't much that people who want to do this
responsibly *can* do - there isn't a path for them.
Reserving .alt will give people designing and using systems like this
a responsible option -- they choose something under .alt (e.g:

Below is a FAQ to answer to some of the previously discussed questions.

1: Why not just suggest people choose something + <non-DNS-character>
(like ASCII 168)?
A: We need this to be usable with existing apps. e.g 'telnet<0xA8>' results sadness. It's also makes the solution
really user-unfriendly.

2: Does this also get added to the"Locally Served DNS Zones"  registry?
A: "Earlier versions of this document requested that .ALT be added to
the  "Locally Served Zones" registry, and that a DNSSEC insecure
delegation (a delegation with no DS record) be created at the root.
Significant discussion on the DNSOP list (and an interim meeting)
generated the consensus that these names are specifically not DNS
names, and that them leaking into the DNS is an error.  This means
that the current (non-delegated) response of NXDOMAIN is correct as
there is no DNS domain .alt, and so the document was updated to remove
these requests.

3: Will there be a registry under .alt.
A: Not one run by ICANN / the IETF, no. There is the expectation that
people using this space will self-organize. A number of people have
also offered to publish an informal list.

4: What is the current status / history?

There was a WGLC started 2017-03-16:

This was then extended 2017-04-07:

I believe that we've addressed all open comments from the WGLC.

It was marked as "Held by WG" (2018-07-17) while we dealt with the
Special-Use Domain Names Problem Statement (which became RFC8244)

It was discussed / presented at:
DNSOP Interim meeting on Special Use Names, RFC6761 (May 12, 2015) -

IETF92 -
IETF96 - (missing)

The Special Use Names interim:

It was also mentioned on the joint IETF DNSOP / ICANN interim to
discuss SUDN PS document, and ICANN was invited to participate in the

I've just posted a new version (bumped the version / date,
aggressive-nsec is now RFC8198, ) to revive it. I'd appreciate review
and comments; I personally believe that this document solves a real
issue, and I'd like to see it progress...


> For 2, we seem to agree that future reservations, if any, will go under .arpa.
> For 3, we already did .test, .invalid, and .example which seem to have
> solved that particular problem.  I think the question of what might be
> too cruddy to delegate is ICANN's problem.  As you know better than I
> do, ICANN has a big project to characterize "cruddy" and I don't see
> the IETF having anything to contribute there.
> R's,
> JOhn
> _______________________________________________
> DNSOP mailing list

I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.