How to help vs "help" maintain the list - _psl txt record DNS validation crucial

[dnsguru]

Hello, gratefully, to those that review the list and submit PR as updates to listings that they are not the admin/registry/manager of. These help the volunteers keep up the freshness of the PSL, and it is absolutely and always appreciated.

That said, there is a validation step used for ensuring that the NIC or domain owner is in the loop and supports the change, to ensure these are intentional and match their desired namespace operation. We do this by requiring that a _psl txt record be added on affected zones or domains that matches the PR # - and this helps as connection between the PR and the DNS record show administration proof.

When submitting a PR, understand that we as the PSL maintainers are volunteers and are not resourced to chase up the NIC or adminstrators of domains; while there are some of us who participate in ICANN or who have the opportunity to make presentations inside the TLD registry community and regional ccTLD events to help with awareness of the PSL, and we describe what it is and isn't and all of the benefits to maintaining entries for a ccTLD or gTLD, it is ultimately they the registries who must be involved in at very least approving / showing validation in the DNS.

When submitting a request for a TLD or domain name that you are a third party to, please include within your efforts the outreach to the party that will be affected by the PR and a request to review the change that you've proposed and for them to add the _psl txt leaf into the affected zones so that the change can be approved and merged.

Otherwise, the effort of the submission often sits without update or change, until we ultimately may close it due to absense of response from the administrator or ability to verify it. These circumastances are bad from our perspective, as we are far too familiar with the loss of some volunteer time to 'disposible effort' that comes from things like #1245 with subsequent rollbacks or where the requestor was 'experimenting'.

So please do the additional outreach and contact the respective domain owner or admins. And assume this has been tried previously. No, we do not have a contact list to share, we use the IANA.org db listed contacts for ccTLDs just like anyone.

Thank you to community members and submitters who are taking their time to help offload the burden from us, and hopefully this issue identifies how to ensure that effort is most effective.

Examples: #1437 #1436 #1435 #1432 #1213 #1021 #1032 #1182

[sleevi]

@dnsguru Beyond the validation side, this swath of PRs seems to be net-negative (in the bloaty sense). Do you have any concerns with me closing these all as WontFix?

[dnsguru]

Can we leave them open for a few weeks? i will be speaking at centr.org tech day and they are good reference

…

On Fri, Oct 1, 2021, 4:10 PM Ryan Sleevi ***@***.***> wrote: @dnsguru <https://github.com/dnsguru> Beyond the validation side, this swath of PRs seems to be net-negative (in the bloaty sense). Do you have any concerns with me closing these all as WontFix? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1439 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACQTJPFTYFCWMJP3K5PYRDUEY5YBANCNFSM5E57NVMA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[sleevi]

Not sure I follow? Some of these are adding explicit values where wildcards suffice, and that seems… not useful/necessary?

[dnsguru]

Perhaps... Truly the TLD administrator's intent is what should be represented. There are also consumers or integrators of the PSL who benefit from the articulated subspaces for them, so I really do not want to discourage them being defined.

…

On Fri, Oct 1, 2021, 5:21 PM Ryan Sleevi ***@***.***> wrote: Not sure I follow? Some of these are adding explicit values where wildcards suffice, and that seems… not useful/necessary? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1439 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACQTJLYHIBHAF5ZZBN4BNDUEZF7LANCNFSM5E57NVMA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[sleevi]

I’m not sure how to square this with the existing format, though. For the same reason .name was rejected, I think it’s worth questioning whether that enumeration benefits the primary purpose of the PSL: cookie management. If a more abbreviated listing achieves that, we should absolutely prefer it. I don’t see how, short of forking or defining a new format, we can balance the “exhaustive listing” vs the “functionally equivalent” listing, where wildcards are advantageous to most PSL consumers.

[dnsguru]

I think this is not an apple to apple comparison if comparing .name to the various ccTLDs on the matter of subspaces. .name, with all the thousands of potential surnames that might expect 3ld registrations, would be a large impact to the PSL file size and scale, but as a gTLD it really truly is an entirely different case than the ccTLDs which might create local distinct namespace segmentation. Anyway, rather than be distracted in that meta discussion, I have been doing a number of outreach sessions to registry tech gatherings and have one coming up in a couple of weeks, and I was asking that the ccTLD PRs that were just filed not be closed as wontfix as they are good examples that I use in the presentation with CENTR.org coming up. We can close them after, should we see no input or validation DNS from the respectively affected IANA delegated parties.

…

On Fri, Oct 1, 2021 at 9:22 PM Ryan Sleevi ***@***.***> wrote: I’m not sure how to square this with the existing format, though. For the same reason .name was rejected, I think it’s worth questioning whether that enumeration benefits the primary purpose of the PSL: cookie management. If a more abbreviated listing achieves that, we should absolutely prefer it. I don’t see how, short of forking or defining a new format, we can balance the “exhaustive listing” vs the “functionally equivalent” listing, where wildcards are advantageous to most PSL consumers. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1439 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACQTJMYXQN3BXKCE3KF3ULUE2CJ5ANCNFSM5E57NVMA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[sleevi]

I think the meta discussion here is relevant: if your goal is to have these merged, then there’s a disagreement among maintainers that we should strive to sort. I would hate to burn what little ccTLD goodwill if we say, on the one hand, send us your domains, but on the other, we won’t take them.

[dnsguru]

Let me start by saying I agree with wontfix, but also wanted to afford the person who took the time to submit them, as well as the community of other eyeballs here the opportunity to contact the ccTLD admins and get their feedback before closing them. My very narrow goal/objective here with the 'leave them open for a little longer' is to show the ccTLDs that I'll be presenting to that we receive PR on TLDs from third parties all the time, but only to merge PR for which the ccTLD administrator that has the delegated control can look at them, review and determine the appropriate articulation of them, and place the DNS records into those zones to demonstrate their oversight / administration. Some ccTLD *might* be possible to be articulated with a single entry or a wildcard, but others not so much. I want to see ccTLDs defining this for themselves.

[sleevi]

Thanks for clarifying. 👍 I thought your goal was to help the ccTLDs make the same request, which may be unnecessary or suboptimal.

[dnsguru]

I thought your goal was to help the ccTLDs make the same request, which may be unnecessary or suboptimal.

Nope + Agree.

Meanwhile, the presentation to the CENTR.org technical operations group went well, and resulted in #1456 update directly from the NIC, which is precisely what we'd want to have happen.

I do not want to discourage 3rd party inputs, and am loathe to undo all the work that @brian-peter-dickson made towards updating the legacy entries in the ccTLD space, but perhaps closing them and re-opening them upon NIC inputs would help shorten our open PR queue.