Trailing dots and the PSL.

[mikewest]

w3c/webappsec-fetch-metadata#15 raises a reasonable question about whether we consider www.example.com. (note the trailing .) to have the same registrable domain as sub.example.com (no trailing .).

Chrome's implementation currently does not: the former has a registrable domain of example.com., the latter example.com (see https://cs.chromium.org/chromium/src/net/base/registry_controlled_domains/registry_controlled_domain.h?rcl=9d1648d08e73cb3b60b4f7ace59f71644a30ee77&l=195).

The algorithm in https://publicsuffix.org/list/, on the other hand, suggests the opposite ("Empty labels are not permitted, meaning that leading and trailing dots are ignored.").

In https://chromium-review.googlesource.com/c/chromium/src/+/1536180/2#message-f6f56727b010950cf4cf13372b2cd2838102e257, @sleevi suggested that this might be a bug in the algorithm, or it might be a bug in Chrome. It would be helpful to get some clarity about the desired outcome.

Thanks!

[sleevi]

@annevk @bzbarsky Do you know who at Moz is following PSL issues since Gerv passed?

Historically, the lack of textual equivalence meant that a trailing dot was not same-origin as that with a trailing dot, and until recently, would not match certificates either. I’m not aware of Mozilla’s implementation canonicalizing away the zero-length root DNS label either.

@cdumez Can you share more about how CFNetwork has implemented this?

My take is that it’s a bug in the description of the algorithm and does not reflect what clients have implemented. The canonicalization of entries to compare against the PSL has not been historically addressed by the PSL, which would determine the form of the input label, and the list itself omits the trailing . as it uses the preferred name syntax for representing entries.

The question at play, as I see it, is whether or not the PSL should be canonicalizing inputs; if example.com. returns example.com as the registerable domain / com as the public suffix, then we’ve transformed and canonicalized the input.

[bzbarsky]

@sleevi that is a good question. I don't know offhand. @rvandermeulen, @valenting, it looks like you've been involved in touching https://hg.mozilla.org/mozilla-central/log/tip/netwerk/dns/effective_tld_names.dat somewhat recently. Do you know the answer to @sleevi's question?

@ehsan might also have an opinion here.

[weppos]

My take is that it’s a bug in the description of the algorithm and does not reflect what clients have implemented. The canonicalization of entries to compare against the PSL has not been historically addressed by the PSL, which would determine the form of the input label, and the list itself omits the trailing . as it uses the preferred name syntax for representing entries.

@sleevi It's also possible to see the other way around: the suggested way was never implemented.

The PSL is a list, hence it doesn't carry on specific knowledge of processing. As you pointed out, the decision to not use canonical entries as a syntax is primarily simplicity (it would be redundant, as it can easily be added as pre-processing step by any consumer).

@sleevi Do you have any insight why historically example.com. and example.com has been considered different, for example in chrome? Are there specific use cases for which an user would need to have these 2 names being handled differently?

I am asking because my experience from the domain industry has been that different providers generally have different preferences (some may use the dot version, others the non-dot version). Regardless, they generally consider both versions being equivalent (and normalized behind the scenes, ending up in using the canonical version when reaching the network level).

I don't think the PSL should change the format (that would actually be tricky as it's a breaking change). However, I concur and I see the positive outcome of having an algorithm that describes the actual implementation (either by updating the algorithm description or the implementations).

[annevk]

This seems like a symptom of #27.

From the perspective of document.domain, the story has always been that it allows cross-port and cross-subdomain communication. This seems a bit different. At least, as @sleevi explained to me an intranet DNS mapping x.example to x.example.mycompany.com could get access to a public x.example. this way. On the other hand, some public sites redirect to the dotless version (e.g., google.com.) and users would basically never explicitly navigate to a domain ending in a dot either, so I'm not sure what to make of it.

[weppos]

@annevk for what is worth, Google (to follow up on your example) has both and you can navigate to them in parallel:

• https://www.google.com./
• https://www.google.com/

I discovered it by accident (ironically) no longer than 3 weeks ago when I followed a link and I was not logged in automatically (and I realized it was due to cookies not being shared).

I confess that was unexpected.

[sleevi]

Yes, that was the issue I was mentioning with trailing dots only recently being accepted to match certificates in UAs.

[annevk]

Oh, my bad, I navigated to https://google.com. which redirects to https://www.google.com.

[dnsguru]

@sleevi @mikewest is this still a straggling issue or can I close?

[annevk]

@dnsguru does the algorithm ignore trailing dots? (Yes it does, so it's still an issue.)

[dnsguru]

Can you help me understand what algorithm are you referring to?

I may have missed something while I am volunteering time to help the PSL... I need some help understanding what algorithm you refer to @annevk - are you referring to our test suite for submissions to the PSL?

Otherwise, the list is just a text file. The PSL does not govern or prescribe what is done with it.

[annevk]

OP points to it, it's at https://publicsuffix.org/list/.

[dnsguru]

any insight why historically example.com. and example.com has been considered different, for example in chrome? Are there specific use cases for which an user would need to have these 2 names being handled differently?

I am asking because my experience from the domain industry has been that different providers generally have different preferences (some may use the dot version, others the non-dot version). Regardless, they generally consider both versions being equivalent (and normalized behind the scenes, ending up in using the canonical version when reaching the network level).

The trailing dot behavior is something that happens in the resolver and DNS as a means to tell DNS that it is the fully qualified domain name, with the trailing dot inferring the root. It is hidden typically, and assumed to be there, which is why software often treats the two identically. Technically, they are not identical.- Often, putting a dot at the end of a domain name would force DNS query vs WINS/NETBIOS stuff on a LAN, or overcome where there may have been DHCP or network definitions established by an IT department for computers on a network, or resolvers that add on LAN or corporate network suffixes to keep lookups within their network.

Is that what's meant here? We can leave the issue here, but I want to push this closed or understand what the objective is better.

[dnsguru]

OP points to it, it's at https://publicsuffix.org/list/.

Ah.... "Formal algorithm" thank you

Let's see if that's needing an update.

[annevk]

The objective is to yield different public suffixes and registrable domains for input.example and input.example..

[dnsguru]

Seems like the documentation label 'algorithm' needs updating.
Currently it says:

Algorithm
1. Match domain against all rules and take note of the matching ones.
2. If no rules match, the prevailing rule is "*".
3. If more than one rule matches, the prevailing rule is the one which is an exception rule.
4. If there is no matching exception rule, the prevailing rule is the one with the most labels.
5. If the prevailing rule is a exception rule, modify it by removing the leftmost label.
6. The public suffix is the set of labels from the domain which match the labels of the prevailing rule, using the matching algorithm above.
7. The registered or registrable domain is the public suffix plus one additional label.

Needs an 8th added

8. There is, like in DNS, presumption of a trailing dot in a given FQDN that is not visible

Would that solve?

[annevk]

No, as OP indicates

A domain or rule can be split into a list of labels using the separator "." (dot). The separator is not part of any of the labels. Empty labels are not permitted, meaning that leading and trailing dots are ignored.

is problematic.

[dnsguru]

Alternatively, we could modify 1 to say "Match Fully Qualified Domain Name against all rules and take note of the matching ones."

Going back to the original comment, I cannot personally think of any reason that treating foo.bar differently than foo.bar. (with trailing dot) because of how DNS would treat them.

With all the use cases that have evolved around it, most all operate under the premise that they are evaluating the rightmost portion of an FQDN with the list.

What developers do with the list, is of course, not something intended to be prescribed by the list.

[sleevi]

Jothan: As you can see, this issue is still relevant. I also don’t think it’s an easy one for you to solve because it matters what implementations do and should do.

[sleevi]

What developers do with the list, is of course, not something intended to be prescribed by the list.

Gerv would not have agreed with this, nor would I. The very goal of this project and specifying is to be prescriptive here.

[dnsguru]

What developers do with the list, is of course, not something intended to be prescribed by the list.

Gerv would not have agreed with this, nor would I. The very goal of this project and specifying is to be prescriptive here.

We are trying to prescribe a common approach to the List's entries, and what to expect they mean. I agree violently on that.

I think that's different than what I said, which is that the we are not prescribing, for example, what Chrome the browser, any CA or other group shall actually chose to do with that interpretation.

The challenge here is that there is divergence in how various different groups seem to have approached that dot at the right most position. I suspect it is a large challenge to make these french fries back into a potato.

Here's the scientific answer and maybe what Gerv and I should have put there...

I found this in RFC 1034, 3.1, p7, 5th paragraph, final sentence

The most common interpretation
uses the root "." as either the single origin or as one of the members
of the search list, so a multi-label relative name is often one where
the trailing dot has been omitted to save typing.

[dnsguru]

Jothan: As you can see, this issue is still relevant. I also don’t think it’s an easy one for you to solve because it matters what implementations do and should do.

Agreed. On to the next one

[sleevi]

I think that's different than what I said, which is that the we are not prescribing, for example, what Chrome the browser, any CA or other group shall actually chose to do with that interpretation.

We disagree here. Many of the ongoing issues are precisely this.

I appreciate your input on this issue, and I think the most productive thing would be to leave it open. This is partly a question of what implementations do, and what they should do, and the impact that has.