danderson
commented
4 days ago Doh, I guess I can't assign myself due to not being a maintainer. I guess I'll just say it instead then: I plan to implement this, this bug is not a request for someone else to do it :)
Request from maintainers: now that there's automated TXT record checking for PRs, the next pain point is checking domain expiration for PRs. I plan to implement this, I'm just taking some notes here in case I have to wander off for a while before I can pick it up.
It seems we really want to use RDAP for this checking rather than whois. It's a nicer json-over-http protocol. A few years ago it was still niche, but ICANN currently requires that all TLDs support RDAP querying.
Lookup is in a tree similar to whois. ICANN has a json bootstrap file with pointers to the RDAP servers for every TLD in the root zone. We'll want to import a copy of that and auto-update it, probably using a similar cronjob github action to the TLD suffix autopull.
One challenge is that the suffixes added to the PSL don't always match the registered domain object that RDAP knows about, and empirically querying for a subdomain yields a 404, rather than a response with the "nearest domain" in the tree. That means we have to take a guess at what the RDAP domain name is, and possibly do a couple of tries to find the most specific registration available.
The other challenge is that RDAP servers, like whois, have some unpublished rate limits enforced by the registries. Unless we can get some kind of sponsorship from one of the various aggregation services, we'll have to be careful with the query rate. That probably means restricting domain expiry validation to just PRs for the time being (small number of domains to check, so low query volume at any one registry), and see how that goes.
The implementation also needs to support exceptions to the standard 2-year expiration requirement, because some TLDs do not allow extending registration more than 1 year into the future. From vague memory, .it is one such TLD? But I need to re-investigate and figure that out. It's not a big deal, encoding such exceptions is easy enough.
All in all, this is fairly easy to implement, I don't foresee any issues aside from what might crop up with registry rate-limiting, but we can deal with that if/when it happens.