Backfill of _psl records

[Ian Williams]

Hello, PSL community,

By now, we're likely all familiar about the part of the PSL guidelines that talks about DNS authentication. One of the pieces mentioned is that the _psl records should persist into perpetuity:

LEAVE THESE _psl IN PLACE WITHIN YOUR ZONES POST-VALIDATION IN ORDER TO ANNOUNCE CONTINUED INCLUSION IS DESIRED. At some point in the future, automation will be used to remove stale entries from the PSL, and missing _psl records will be a flag used in determination of domains to remove from the PSL.

As an organization of a certain size, Amazon holds a variety of (historic) PSL records that:

• do not have a _psl record, because one was not required at the time, and/or
• predate the pull request process (e.g. updates by emailing maintainers directly), and/or
• predate the PSL's use of GitHub entirely, back when it was still authoritative in Firefox's source.

Here's a good example - this commit is actually from this BMO / this Mozilla hg rev, and was included in the Mozilla HG -> GitHub migration.

---

For these types of PSL suffixes where a GitHub pull request was never filed - what would an appropriate _psl value be, if a DNS record were created today (to bring that suffix into compliance)?

Our thoughts here include one of the following options, ranked in order of "easiest-to-hardest" with regards to implementation:

1. A static value, e.g. legacy, to indicate this predates the current GitHub-based process, but was approved by the authority of that domain at some point.
2. A link to this thread on Google Groups, indicating that it's a "backfill" record.
3. The commit URL on GitHub which added the suffix - this would cover most of the modern-day private section, but not the original members of the modern-day "ICANN" section.
4. The BMO URL which added the suffix - there's a minor procedural difference here, in that BMOs were often filed by proxy, not by the actual requester (the one above is an example).

Happy to hear alternative options as well.

Regards,
--Ian

[Jothan Frakes]

Ian 

Happy Holidays!

I think picking 'legacy' (or something else as long as it is not NX reply on the record/type/class for _PSL IN TXT lookup) for the domains is a good idea.

There is a majority of legacy / backfill entries in the PSL that do not have DNS TXT vs newer ones that  might have the DNS TXT   -  ( I say 'might' because sometimes folks put the _PSL TXT leaf in place but drop it once the pull request gets merged).

I don't think that we should remove entries that do not have the TXT record , but rather think that the presence of one indicates robust, ongoing interest and intentionality to keep the record in place.

-Jothan
Jothan Frakes

--
You received this message because you are subscribed to the Google Groups "psl-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to publicsuffix-dis...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/publicsuffix-discuss/53940709-2f72-44bf-a610-e52123b80d0dn%40googlegroups.com.

[Ian Williams]

Jothan,

Happy Holidays to you+yours.

We'll keep that in mind - as long as there is an intelligent response for the query, it seems like that's all that's needed. We understand there's no plans to remove suffixes that lack these records anyways.

We're looking at unifying our processes for some of our services, old and new, which includes ones that have been on the PSL for a long time.
In such cases, we'd need to have the "previously-expected" DNS verification value ready, and we plan on including "historic" suffixes in that backfill where possible.

Regards,
--Ian