Non-private rules and TLD validation

[Simone Carletti]

Hi,

I saw the follow up and closing action on

https://github.com/publicsuffix/list/pull/518#issuecomment-593848747

and I wonder whether this is the correct outcome.

Historically, we've approved and applied changes to the ICANN section when we could validate changes from official registry records. The reason is because not all registries are collaborative. Some existing entries in the ICANN section were never provided by the registries. Some registries never cared about the PSL itself.

https://github.com/publicsuffix/list/pull/518#issuecomment-593848747

seems to fall exactly in this scenario.

Are we changing the policy and expecting the IT registry (which never contributed) to be the only one with the power to change those entries, and also requesting DNS validation (which is notably even more complicated from registries)?

I question whether is a good idea to make such policy change. To me, that PR should have been validated according to public registry records (the Nic.it provides a list of regional entries) and we should have applied the change (if any).

-- Simone

[Ryan Sleevi]

Did I miss something? I read through that issue, and the public registry records do not appear to have been updated. That is, they still include the domain, hence *not* removing that domain is the correct answer.

If the parent has set a policy, the child should not be able to override it. For example, !foo.appspot.com should never be validatable in the presence of an appspot.com record for a wildcard.

As far as I understand it, the ccTLD has declared a (potentially incorrect) policy, and unless/until that documentation is updated, we shouldn't attempt to second-guess it. 

[Jothan Frakes]

I am glad to un-close the issue in question, especially if I took the incorrect approach on it.

That was a bias for action -  I was not attempting to rewrite policy so much as to just look at the age of the PR and a number of other factors.

I took this specifc action in the interests of clearing the backlog.  

The rationale was that the submission was for a number of reasons that seem perfectly valid.

1] did not include a pr validation _psl txt entry, 

2] there was not a posted policy, 

3] the submitter identified that they had made a workaround, so the further need was ambiguous or unclear,

4] unclear if this was a representative of the registry or not,

5] the age of the request

I only looked at the queue of PR from a merge, clarify, or close point of view.  If I took the wrong action here, or too much of a rash action this is a good learning experience.

-Jothan

--
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 on the web, visit https://groups.google.com/d/msgid/publicsuffix-discuss/CACvaWvbxAuyEnMZJzfTo_xgjENQrY1_e5TQEH75wN0QXnsd1Dw%40mail.gmail.com.

[Jothan Frakes]

The policy listing URL is moved and is here: https://www.nic.it/sites/default/files/archivio/docs/Regulation_assignation_v7.1.pdf
The registry policy defined it, and the domain is sitting there in that list from the .it registry, at the bottom of page 21

IF #518 was re-opened, and the appropriate _PSL TXT record was placed in the zone for altoadige.it it would complete the loop on verification/validation to MY satisfaction and I would have squash/merged it

[Ryan Sleevi]

I'm not sure we would/should approve it in that case (that was my appspot example), if the parent still says it.

[Jothan Frakes]

On Tue, Mar 3, 2020 at 9:16 AM 'Ryan Sleevi' via psl-discuss <publicsuff...@googlegroups.com> wrote:

I'm not sure we would/should approve it in that case (that was my appspot example), if the parent still says it.

Not trying to set any policy here, but to me, in this instance, the _psl txt record with the PR would indicate direct administration and stronger authority than documentation - my rationale is that it would be proof of that the written policy is no longer the guiding principle for the specific domain in question.

There is a valid argument against what I am saying, which could be that the registry failed to technically enforce their own policy and released the domain name in error.  This PR was submitted in 2017.  This scenario would have evidenced itself and been caught within a year or two at most competent registries, of which .IT should arguably be considered.  

[Ryan Sleevi]

On Tue, Mar 3, 2020 at 1:15 PM Jothan Frakes <jot...@jothan.com> wrote:

On Tue, Mar 3, 2020 at 9:16 AM 'Ryan Sleevi' via psl-discuss <publicsuff...@googlegroups.com> wrote:

I'm not sure we would/should approve it in that case (that was my appspot example), if the parent still says it.

Not trying to set any policy here, but to me, in this instance, the _psl txt record with the PR would indicate direct administration and stronger authority than documentation - my rationale is that it would be proof of that the written policy is no longer the guiding principle for the specific domain in question.

I don't think a subdomain can ever be said to be stronger evidence than the parent domain.

I agree, that if they were at the same domain label, the existence of technical control would be much stronger than the policy. But when comparing across parent/child labels, I think we should err on the side of the parent.

 

There is a valid argument against what I am saying, which could be that the registry failed to technically enforce their own policy and released the domain name in error.  This PR was submitted in 2017.  This scenario would have evidenced itself and been caught within a year or two at most competent registries, of which .IT should arguably be considered.  

I'm wanting to explicitly avoid that judgment, because of the liability it brings with it. Judging whether or not .it is competent, and whether or not the requestor is an attacker, shouldn't be something we're doing. If the parent has a policy, we should observe it above all.

That explicitly means children shouldn't be able to remove themselves if their parent added them. Again, the appspot example is, I think, incredibly germane here. If appspot added itself-and-its-subdomains, it should be totally fine to allow an administrative or domain boundary to delegate out those subdomains, and they should not be able to contradict the parent policy.

After all, that's the hierarchical nature of DNS.

Yes, I realize it penalizes the party who may have had the name released to them. That's unfortunate. But it shifts the liability/blame/resolution on to the parent, not us.

[Jothan Frakes]

I do agree that a request for !foo.appspot.com should be rejected if appspot.com is present with wildcard.

I think it is germane as a basis for rejection in the presence of no other substance to validate the request, and a reasonable rationale for the rejection. 

I am not sure that I agree the appspot.com example is an apples->apples comparison but I think you make a good point - in the presence of policy listing something is restricted.  That is hard to scale, as it makes for a lot of extra validation homework.

I found another PR with the request for remove an entry for a stub zone from the ICANN section of a ccTLD   https://github.com/publicsuffix/list/pull/530  for removal of sector-based domains in .FR.  Still, it quotes policy changes that can be validated at the registry, which is why it was merged.  

That was missing here.

I still stand by the outcome of closing this, and you -might- have convinced me that the DNS validation should not be an absolute override, but I think these may have to be case by case.

[Simone Carletti]

I was under the impression that the policy was validable via registry data.

I admit I did not have the time to verify, and I based it on what I recall was my verification at the time the PR was opened.

If there aren't any registry published records that can confirm/deny the change, then I'm fine to close it.

-- Simone