Re: [DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-alt-tld-23: (with COMMENT)

Warren Kumari <> Wed, 26 April 2023 18:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D30C7C14F736 for <>; Wed, 26 Apr 2023 11:09:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UPA8SkUPTkOo for <>; Wed, 26 Apr 2023 11:09:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id D1B88C151524 for <>; Wed, 26 Apr 2023 11:09:15 -0700 (PDT)
Received: by with SMTP id d75a77b69052e-3eab1f2ba18so36888011cf.0 for <>; Wed, 26 Apr 2023 11:09:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1682532555; x=1685124555; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=5BH0EZMRvrqx7OEDUwHYAWkI8VKmTcK9BUO56bN6MHI=; b=aX21KJAvoHezhwwvtnBsa4Rw7XLgWfMii1fR+F8O/ExImNktzKBXbzmLbIrwNmHNEg QJKYqKgd18HfXC+IAF8g3Gog7Chm1cYBSOpOUx1Vc+/hJfW8CeK6kBuU+gFxPyGSOPYl QOibiweRtOKP7vRq6jfmhoSz6WCEvSSnZTRVphpPGRenBXgnF+chEp7rPLgh1NSqBVBd lCkMmJs5xUV6G8gwMhoHPL8gwbWZb4jwpEdfdSvK1aVldtC7ayn9iMf0DgUB3/TFtRGQ D7xFNaozpRv6H1G58I/sjIUpNqSQTrVvPIe+/F8Bvqy+2hL9JLo8eunJ4Nih57+LT9un D9Zg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1682532555; x=1685124555; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5BH0EZMRvrqx7OEDUwHYAWkI8VKmTcK9BUO56bN6MHI=; b=IeNIYGE4LopcEi+0O5+OC8zVaL0QKNwn0/PW+GK3SUbXHSY3X6s9ol7Q7pYNCZED+o O3nhSWWrgytTv9HPToo4HTUxoztnbEaeue6fKZNf/A0UYyoJLKIMauXjZ7NoeIsZVouT dBeEE81jBi4OTtnipfj3lORIzjy2NS135cCGY+pYmn2ebGFXvp+e7H0IQxxvfBEScNUe OIG9x8hBfbAScID5+kgUgBngH9XdRtNPg/kDJXMPB0Uir9CqUkubY+tMpfnPI6L8PJc5 yqHDevUPzHHOSL8htY6DAJFcKycR5hZRDh3Ny225/A1Kq1/Ciiv4f5RwXN2mBhNFpn/V PxTg==
X-Gm-Message-State: AAQBX9dzTSl3Bg3Ef3A52E7LXSCTrUfF5OSOiT0rb0c2+2j8zfzwWkN3 0MbjGe7Eb9QFsrREQc3KCdye7iQVFvmqmGbCGXBKBQ==
X-Google-Smtp-Source: AKy350aulFFn/RTJZbtp6kWGowSrQX9PSwMqHdP9PN854YG5VPZi6VxL9sn7/ldGatB3BARuAHtgQSBR+fyavvm7fsU=
X-Received: by 2002:a05:622a:143:b0:3ef:371a:c80f with SMTP id v3-20020a05622a014300b003ef371ac80fmr40669066qtw.41.1682532554539; Wed, 26 Apr 2023 11:09:14 -0700 (PDT)
Received: from 649336022844 named unknown by with HTTPREST; Wed, 26 Apr 2023 11:09:13 -0700
Mime-Version: 1.0
References: <>
X-Superhuman-Draft-ID: draft00ee2d71374e81c6
In-Reply-To: <>
From: Warren Kumari <>
X-Mailer: Superhuman Desktop (2023-04-25T22:06:04Z)
X-Superhuman-ID: lgy0ffei.59d9aac8-286a-4a60-b230-384fb6ae821d
Date: Wed, 26 Apr 2023 11:09:13 -0700
Message-ID: <>
To: Paul Wouters <>
Cc: The IESG <>,,,,
Content-Type: multipart/alternative; boundary="0000000000003c9b5705fa412319"
Archived-At: <>
Subject: Re: [DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-alt-tld-23: (with COMMENT)
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Apr 2023 18:09:19 -0000

On Sun, Apr 23, 2023 at 4:16 PM, Paul Wouters <> wrote:

> Paul Wouters has entered the following ballot position for
> draft-ietf-dnsop-alt-tld-23: Yes
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> handling-ballot-positions/ for more information about how to handle
> DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Some of my comments might be DISCUSS-worthy (my apologies), but I really
> don't want to block this document for any further time. But please do take
> my comments into considerations if you can do a quick ref update.
> The term pseudo-TLD as defined here is not how I've seen the term used. A
> pseudo TLD as I've seen it used is a TLD that's one step below a real TLD
> and runs as a general GTLD (open registration), eg "". I guess I
> would qualify the use in this document more as "fake TLD", but I can see
> how that might come over as even more perogative. So I am fine with the
> current definition and use case. Perhaps a "to be confused with" note could
> be added, but is not strictly required.

We've been using this terming this way since at least 2015, and so changing
it now would be very disruptive. Do you have proposed text to clarify that
it's not used to mean something like the public suffix list?

> 4. Caching DNS servers SHOULD NOT recognize names in the .alt pseudo-TLD
> as special and SHOULD NOT perform any special handling with them.
> There is value for a recursor to "pre-load" the proof of non-existence of
> ".alt" (the entire branch in the hierarchy) to avoid any potential leakage
> of subdomains within alt. It could potentially also reduce error message
> logs if someone starts using .alt not as a real hierarchy or using non-DNS
> valid characters in their name, eg Ulabel stuff or even binary stuff like
> 0x00010001000000003616c7400. They could also just return NXDOMAIN instead
> of forwarding the query to the root servers to avoid a privacy leak. Or it
> could modify the question foo "foo.alt" and only send "alt" to the root. I
> see no reason such additional protection mechanisms need to violate this
> "SHOULD NOT" clause. Why not flip the statement around?
> 4. Caching DNS servers MAY recognize names in the .alt pseudo-TLD as
> special and MAY perform special privacy preserving methods to return
> (DNSSEC signed) NXDOMAIN answers to prevent leaking entries under the .alt
> pseudo-TLD into the global DNS.
> 5. Authoritative DNS servers SHOULD NOT recognize names in the
> .alt pseudo-TLD as special and should not perform any special handling
> with them.
> Any reason the second "should not" is lowercase ? Note that I do agree
> here, and would even say MUST NOT so that people can use DNS technology
> even if not rooted in the global DNS for their
> .alt names without having to modify existing DNS software (eg run a shadow
> .alt using DNS on port 666 or something)
> 6. DNS server operators will treat names in ...
> I find the use of "will" here a little odd. Perhaps:
> 6. DNS servers and operators, which whave no special handling for the .alt
> pseudo-TLD will end up treating names in ...
> 7. DNS registries/registrars for the global DNS will never register names
> in the .alt pseudo-TLD because .alt will not exist in the global DNS root
> "will never" seems wishful thinking. I've seen some very fraudulent stuff
> happen with DNS registries/registrars. eg what if one of them will support
> pseudo-TLDs along with real DNS domains, and includes bogus .alt
> registrations? Perhaps:
> 7. DNS registries/registrars for the global DNS can never legitimately
> register names in the .alt pseudo-TLD because .alt will never exist in the
> global DNS root

Oh, good point. Your proposed text still make it sound like they are not
allowed to support non-DNS names, and so I'm proposing:
"7. It is not possible for DNS registries/registrars to register names in
      the .alt pseudo-TLD as the .alt will not exist in the global DNS

This threads the needle of not trying to tell registries and registrar what
they are allowed to do by simply point out that's it's an impossibility for
them to register *DNS* names in an undelegated name.

> Again, my apologies to Warren for not balloting a blanc YES :)

Nah, thanks for the comments…. and it's still a YES :-p