Re: [dbound] The proposals before us

[Casey Deccio <[e-mail]>]

> On Sep 10, 2016, at 11:44 PM, John R Levine <[e-mail]> 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":

https://tools.ietf.org/html/draft-deccio-dbound-organizational-domain-policy-03#section-6

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 "_odup.uk", then anything under "_odup.uk" doesn't need to be looked up in the DNS.  That includes: a._odup.uk, g.co._odup.uk, and _odup.uk, for example.

> 
> Could you tell us what the queries would be for abc.def.com if the org
> domain is def.com

See example for: b.a.uk

> , or for ghi.blogspot.com, where the org domain is
> ghi.blogspot.com

See example for: c.b.a.uk
(not an exact match, but it's close enough)

> jkl.mno.uk and jkl.mno.co.uk, where the org domains
> are mno.uk and mno.co.uk?

See the examples for b.a.uk and g.co.uk.

>  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.

Casey