You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While preparing PR #163, I noticed several drivers that have the hardwired assumption that the apex domain is exactly two components long. That is, from domain_name.split('.'), they collect the last two splits, and only the last two splits, as the domain to which to add or remove a record identified by the other parts of the split. Quick counterexample: in forums.bbc.co.uk, the apex domain (or zone, though I saw at least one upstream provider who seems to use the terms backwards, ugh) is truly bbc,co.uk.
This includes the drivers cloudns, dnspod, gandi, and hurricane, at least. There are a couple (not enumerated) that use tldextract which, at the cost of a moderately large list that needs occasional updating, does the job right. Some others appear to search the service provider's records to find what it considers to be the apex, which can be expected to work for submitting changes to that service provider whether its results agree with the publicsuffix info or not.
What is it that you would like to propose to add/remove/change?
tldextract is the only off the shelf fix I know of, not that I've researched this further than a quick look at tldextract that I did in order to examine whether it was covering for the *.domain.tld bug. (it doesn't, and happily identifies "*" as the host (was that the term it uses?).
How do you want to go about adding/removing/changing that?
I'd really prefer to see the original authors of the drivers assess and address these issues as I don't have the understanding of the service providers' APIs. In the meantime, this bug will at least give people something to find when they trip over the problem.
The text was updated successfully, but these errors were encountered:
Memo to the future: tldextract isn't a perfect answer, even ignoring the considerable bulk and need to refresh its tables. It might not be common, but if you have internal subdomains that act as the apex for a DNS zone... I think tldextract has some provision for that - private domains? But then we have to have a way to inject those.
I am suddenly feeling more kindly disposed to schemes that query the dns service's records (eg. powerdns), as that avoids the problem. I think. Also that's not always an option.
While preparing PR #163, I noticed several drivers that have the hardwired assumption that the apex domain is exactly two components long. That is, from
domain_name.split('.')
, they collect the last two splits, and only the last two splits, as the domain to which to add or remove a record identified by the other parts of the split. Quick counterexample: in forums.bbc.co.uk, the apex domain (or zone, though I saw at least one upstream provider who seems to use the terms backwards, ugh) is truly bbc,co.uk.This includes the drivers cloudns, dnspod, gandi, and hurricane, at least. There are a couple (not enumerated) that use tldextract which, at the cost of a moderately large list that needs occasional updating, does the job right. Some others appear to search the service provider's records to find what it considers to be the apex, which can be expected to work for submitting changes to that service provider whether its results agree with the publicsuffix info or not.
What is it that you would like to propose to add/remove/change?
tldextract is the only off the shelf fix I know of, not that I've researched this further than a quick look at tldextract that I did in order to examine whether it was covering for the
*.domain.tld
bug. (it doesn't, and happily identifies"*"
as the host (was that the term it uses?).How do you want to go about adding/removing/changing that?
I'd really prefer to see the original authors of the drivers assess and address these issues as I don't have the understanding of the service providers' APIs. In the meantime, this bug will at least give people something to find when they trip over the problem.
The text was updated successfully, but these errors were encountered: