Re: [dbound] The proposals before us

Casey Deccio <> Mon, 12 September 2016 11:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF48112B24E for <>; Mon, 12 Sep 2016 04:40:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c0DGCpRmh_zD for <>; Mon, 12 Sep 2016 04:40:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7A1E012B212 for <>; Mon, 12 Sep 2016 04:40:16 -0700 (PDT)
Received: by with SMTP id h8so50087608qka.1 for <>; Mon, 12 Sep 2016 04:40:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C8Y24HTbpew/PhBYdRqFZQfpcRCTeuvKGHkKlfn5jao=; b=R1d50eoKRERC4P+R5ko+HkcP4Hb2vYTxf8hjolDAz+Q2Rfldxf0vmaMwrC9UQby/9D Y/ApU1gMDtGSBPFYEYrK2DEDUv4RHWkFnRkOrZ/9JfA5FVwcSfzLVQJ42KuBppk7G1cN l0IK1PWAXWtCGyIxcRgDtvmuq+tr2ZMtvQUT4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C8Y24HTbpew/PhBYdRqFZQfpcRCTeuvKGHkKlfn5jao=; b=SZHuERr94VVJ0AnzrxPwdLGDyGhUFwplQBrCoPcZPIQefw5Rc+lV2DiqYnGm4TtvGR lT66E0yUgbqbew8w9MNTfqxu9N6FIC8UdyIPXQ7+5dKDTWMr+F2t3d+lAkmAo+wwYRPH moGBwxV8Ugs5QnOiVadso3qFy2krTx3d+k9yybcfZyVKg7890q92VUBRALw3LgqJ9FVe Ve8BfJU07cqSWsalBISZZpbBB7hav5oj3ZWA8/kFVkicDDT0pYRhqGg3cwB7bP7inyU4 1M6rIyseL6YeBLNBUxJvBRjpy5LkWoYNu1ALnyQCyNyLvsoOP/0OWLrVnJvI459d7/GJ us5A==
X-Gm-Message-State: AE9vXwNNuma6KaojCs0mF4MAzirfYYgb/KFTGNhOt6KWmq/5HMh8ywS2mNCMGOEfudfrVg==
X-Received: by with SMTP id o125mr19018627qkd.17.1473680415567; Mon, 12 Sep 2016 04:40:15 -0700 (PDT)
Received: from ([]) by with ESMTPSA id z34sm4819820qta.29.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 12 Sep 2016 04:40:14 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Casey Deccio <>
In-Reply-To: <alpine.OSX.2.11.1609102313420.53927@ary.lan>
Date: Mon, 12 Sep 2016 07:40:15 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <20160910211314.47140.qmail@ary.lan> <> <alpine.OSX.2.11.1609102313420.53927@ary.lan>
To: John R Levine <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Subject: Re: [dbound] The proposals before us
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: DNS tree bounds <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Sep 2016 11:40:19 -0000

> On Sep 10, 2016, at 11:44 PM, John R Levine <> wrote:
>> The pertinent information was included in the text that immediately followed the snippet that you included above.  Since it was omitted, I'll include it again here (some emphasis added):
> I have a problem, in that I have read this document multiple times and have no clue what the actual series of queries and responses would be, given the complexity of the lookup algorithm and the situation where some subtrees can be cached via a fetch result. It'd be a big help if you could give some examples.

Sure.  Please see Section 6, "Examples":

Table 1 has all the ODUP-related DNS entries.  Figure 1 shows a representation of the affected namespace tree in question.  Figure 2 shows all the queries and responses to ODUP-resolve each and every name in the tree, as the rule in the algorithm corresponding to each response.  Table 3 shows the resolution result.

If you have some local data via fetch, then it's simply as if you didn't have to perform those DNS lookups.  For example, if I have fetched "", then anything under "" doesn't need to be looked up in the DNS.  That includes:,, and, for example.

> Could you tell us what the queries would be for if the org
> domain is

See example for:

> , or for, where the org domain is

See example for:
(not an exact match, but it's close enough)

> and, where the org domains
> are and

See the examples for and

>  That would certainly clarify things for me.

Hope that helps.

>>> The current behavior is typically to look in the PSL and if the domain
>>> isn't there, the code does whatever it does. ...
>> The algorithms on the Public Suffix List page [2] and in section 3.2 of RFC 7489 [3] seem pretty clear.  The algorithm is longest match--there really isn't a notion of "if the domain isn't there".
> Let's say you're looking up the domain bulgaria.xn--90ae.  That's a
> name in a real TLD, and the TLD doesn't appear in the PSL.  What does
> the code do now?  Looking at some of the PSL libraries, the results
> look pretty random.  Some raise exceptions, some fall off the ends of
> routines and return null or a random result.

Fair enough.  Admittedly, the principles behind the current PSL are actually more robust than the current algorithm, data, and implementations.  In theory, given a perfectly complete and accurate PSL, if there's no match, the "public suffix" is the root, which makes the organizational domain the TLD.  In the past this doesn't necessarily make sense, particularly for the cases for which the PSL was originally designed.  However, TLDs aren't what they used to be.  It is clear that many are not intended for general registration, and the TLD itself very well could be the organizational domain.