Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/net/publicsuffix: ICANN flag returned not aligned with public suffix location in the list #22985

eminano opened this issue Dec 4, 2017 · 7 comments


Copy link

eminano commented Dec 4, 2017

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.9.2

Does this issue reproduce with the latest release?


What operating system and processor architecture are you using (go env)?

goos: darwin
goarch: amd64

What did you do?

Call PublicSuffix with input domain ""

What did you expect to see?

ICANN flag set to true

List contains "be" within the ICANN delimiters:
// be :
// Confirmed by registry 2008-06-08

and "*" outside.

// TransIP : htts://
// Submitted by Rory Breuk

What did you see instead?

ICANN flag set to false

I am not sure if this behaviour is expected. Should match *, given it doesn't have a 3rd level domain?
Also, since the public suffix domain returned is "be" , I would expect for that rule to be the one being matched, and therefore having ICANN set to true.

There are more occurrences of this scenario, such as "".

@gopherbot gopherbot added this to the Unreleased milestone Dec 4, 2017
Copy link

meirf commented May 7, 2018

I think this behavior is expected at least from the perspective of the official PSL repo.
I forked the repo and added test cases.

Build 7 which has change:

+// TLD wildcard with subdomain:

results in failure.

Build 8 which has change: null

results in success.

Build 9 which has change: null

results in success.

Note that there were no other changes between these builds. Compare the cases here:, note the pattern of swapped with mm.

This answer is purely based on the official repo behavior. Perhaps @vdobler, @weppos can give some additional insights/correct my results.

Copy link

weppos commented May 8, 2018

Thanks for bringing it to the attention.

At first glance, I'd say the match should be against * as this is the longest matching suffix. In fact, for wildcard rules the match is against the token without the *

However, it's interesting we don't have a proper test case.

I also checked it against 2 libraries I maintain. The Go lib matches against the be (it currently uses a very naive sequential scan approach), whereas the Ruby lib matches against the private TLD (it uses a more optimized Hash-based approach).

I'll bring this issue to the PSL list to make sure the interpretation is correct and make sure we address it.

Copy link

vdobler commented May 8, 2018

Fro my reading "" would be matched only by the rule "be" and not by "*" as the nothing in "" matches the *.

This icann should be true. So it is a real bug.

Copy link

weppos commented May 8, 2018

Fro my reading "" would be matched only by the rule "be" and not by "*" as the nothing in "" matches the *.

I believe this is the source of the confusion.

From the formal algorithm:

A domain is said to match a rule if and only if all of the following conditions are met:

  • When the domain and rule are split into corresponding labels, that the domain contains as many or more labels than the rule.
  • Beginning with the right-most labels of both the domain and the rule, and continuing for all labels in the rule, one finds that for every pair, either they are identical, or that the label from the rule is "*".

Emphasis is mine. It means, given two rules:

  • be
  • *

If you try to match, it should match both as the second rule falls into the very last case:

or that the label from the rule is "*".**

In other words, in case the rule contains ! or *., the match is performed against the token without the char.

  • !
  • *

should all match

I think this is one of those cases where it's worth to invest some effort on the PSL side to reach a consensus and standardize all the implementations. I am definitely bringing it up for discussion (I'll add a reference to the ticker and/or thread here).

Copy link

vdobler commented May 8, 2018

@weppos I doubt that this reading is correct.

* has three labels. From right to left these are "be", "example" and "*". has two labels: "be" and "example"

So the domain can never match the rule * because the domain has fewer labels than the rule. The * is a label; it is not "a label or no label".

Copy link

vdobler commented May 14, 2018

While trying to fix this bug I found one more thing I think is underspecified:

What is the icann flag for "bd"? There is just one rule for bd:


(the rule is in the ICANN section).

With the official PSL algorithm the domain "be" would not match the rule ".bd"
due to "too few labels". But then PublicSuffix("be") would be handled by the
implied default rule "
" and I doubt that this should be considered a ICANN managed
But maybe this is intentional and bd itself is not ICANN managed while
all subdomains like are?

(Note: The strange rule "*.bd" seems to be a "fix" for some test case break.
The rules switch between



// bd :

Where the later with the explicit rule for "bd" seems saner.

Copy link

weppos commented May 21, 2018

It looks like this is an old issue. I've resurrected the discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

5 participants