CC @nigeltao

CC @vdobler @weppos

I'm not sure if I understand what you are trying to accomplish.

The suggestion to "add an additional bool to the PublicSuffix return to represent whether it was on the list or not" would be an incompatible API change is is therefore not a real option.

Exposing find() seems very strange to me as this is a pure helper to work with the internal representation of the public suffix list. Exporting it alone is not enough: To make it useful we would have to export all the implementation details---especially the whole tree structure used to store the list. Note that find() operates on single labels (like "iwanta"), not on domains like "iwanta.purpleunicorn").

If I understand your intention you want to be able to distinguish between "invalid" and "valid" hostnames. Depending on what exactly "invalid" means this might be simple or outright impossible.

Some domain names are malformed like "payme.$$$" as "$" is not allowed in a label or "4.5.6.7" should be treated as an IP address in doted decimal form. See RFCs 1034 and 1123 as an intro. So some types of "invalid" domain names can be detected without consulting the public suffix list.

Regarding "iwanta.purpleunicorn": I assume you want some way to determin that "iwanta.purpleunicon" is not a valid host name simply because "purpleunicorn" is not a TLD in use?
This use case is not well covered by the PSL at all: the PSL is about the public suffix and the eTLD+1 and several existing TLDs might be covered by the implicit * rule of the PSL. According to the public suffix list maintained under https://github.com/publicsuffix/list "purpleunicorn" is a public suffix and
package x/net/publicsuffix is about public suffixes only, not about TLDs.

If your use case is about determin whether "purpleunicorn" is a TLD or not I would suggest inspecting the official list of TLDs available via https://www.icann.org/resources/pages/tlds-2012-02-25-en .

The attempt here was to identify whether or not a TLD is valid, not the hostname.

Validity is determined by available TLDs provided by registries.
http://data.iana.org/TLD/tlds-alpha-by-domain.txt

PublicSuffix does incorporate all of these TLDs, but does not offer validation against them.

I do see your stance on how this request is likely out of intended scope, but it certainly seemed to be the most appropriate package to incorporate said function.

Perhaps an additional function within the PublicSuffix package would be appropriate or is it in best fashion to have an entire TLD package which incorporates this use?

Essentially what is accomplished here:
https://github.com/inhies/go-tld/blob/master/tld.go

@Agronis FYI there is no guarantee that the PSL contains all the IANA suffixes, nor that it is up to date with the latest changes that may be pushed at any time by IANA.

Moreover, some TLDs may be reserved, others revoked and there's no way to capture these informations in the PSL. As a result, the final behavior may not be what you are looking for. For instance, you may want to ignore the revoked TLDs if you only care about validating actual real domains, but you may be care for certain other uses where any TLD ever created matters.

The PSL is really not the best way to accomplish such validation. You should probably have a custom function for that, or use a package that offers that feature.

@Agronis

PublicSuffix does incorporate all of these TLDs

No it doesn't. TLDs covered by the implicit * rule are not part of the PSL.
I doubt that package publicsuffix is the right place for TLD verification. Package publicsuffix computes the public suffix and the eTLD+1 but does not validate TLDs which is a completely
different topic.

What prevents using github.com/inhies/go-tld for your purpose?

While I think that TLD validation is useful I doubt that package publicsuffix is the right place.
I also do not think that TLD validation qualifies for inclusion into golang.org/x/net: The main reason we do have package publicsuffix is to provide an implementation for net/http/cookiejar.PublicSuffixList because a cookie jar without a proper PSL might be a security issue. I think it is okay to delegate TLD validation to other open source packages like github.com/inhies/go-tld.

For this reasons I would recommend closing this issue.

I agree with @vdobler. As explained in my previous comment, I confirm there is no guarantee that the PSL includes all the TLD and therefore it's not safe to use it for such type of validation.