> do browsers have a wildcard suffix list
Yes: https://publicsuffix.org/ and they have discussed this situation here: https://github.com/publicsuffix/list/issues/2306
> We have no plans to modify the .name entries at this point in time. We are aware of the implications of adding a wildcard, therefore we won't.
So does that mean that in practice, .name domains were always treated by browsers like regular 2LDs, meaning the cookie and origin protection was always broken for those domains?
Doesn't sound like good news for the guy in the OP...
IIRC orgs like letsencrypt also use the PSL for rate limits, so there are probably more issues that are not browser-based.
But letting arbitrary customers take arbitrary 3 level domains, and others take 2 level domains, seems like a mistake as it's not very reasonable for every 3LD customer to put the 2LD on the public suffix list, but mixing 3LD and 2LD registrations means you can't public suffix *.name.
Seems the whole idea of having both was always misguided.
The issue is that .jp registered outside of a few Japanese registrars are legally not allowed to offer Whois privacy.
But that was simply the easiest way to market your website as a trusted government entity. And now nobody has ever heard of .us domains in active use.
This is a bug, not a feature.
There was an effort to properly handle the .name 2LDs, but it was never resolved because there’s no easy way to tell a reserved 2LD (open for 3LD registrations only) apart from a normal 2LD on .name: https://github.com/publicsuffix/list/issues/2306
So yes, this TLD’s setup is in fact pretty insane.
In a world without advertising, there's no reason why google.com couldn't also allow *.youtube.com to set cookies for it, but of course that would cause a tremendous privacy freakout. Though in practice they can and do just send every login/logout through a 302 redirect roundtrip to take care of the cookies on youtube.com.
That said I don't know about making cookies shareable across TLDs. That seems like allowing more privacy nightmares; at least today if you want to share you need complicated redirect dances that make you question if the user perf hit is worth it. I think there was some proposal for a mechanism for allowing non partitioned 3rd party cookies which seemed more sane to me, forget what the details were and if it ever made it beyond just a proposal.
Maybe it could be opt-in or opt-out via some markers at the DNS level, though? The public suffix list having to exist at all is bizarre.
Surely a better solution would involve an actual request. login.foo.com could send a request to foo.com with Origin: login.foo.com asking to set a cookie, and foo.com could make its own decision.
If you require domain wide cookies be set from a webserver on the domain apex, the domain apex (for high volume destinations) needs to be set up for high volume webserving. High volume webserving often means at least geotargetted DNS, maybe a CDN, often anycast in today's reality.
Back in the day, it was common for high traffic domains to run their DNS with a normal DNS server and then delegate (typically via CNAME) high volume subdomains off to a 3rd party DNS server for geotargetting (usually Akamai DNS, but there were others). But you can't CNAME the apex domain away. You'd have to delegate the whole domain to your DNS provider and then you have no way to manage an outage of your fancy DNS provider. Especially if you go back to the days where NetworkSolutions did a single daily zone update for .com ... if you wanted to switch to a new DNS provider for your domain, you would submit the change request and hope it happened in the 24 hours, but sometimes you'd miss the window (or there would be some process error) and it would happen much later.
Less of a problem in today's world, where registries typically update the glue records in near real time (although many TLD servers have a 2 day TTL for glue, so you can't switch off a dead provider very quickly) and lots of domains seem comfortable with delegating the whole thing to their CDN.
That said the dumbest thing with cookies is not sending their attributes in the cookie header which makes it impossible to distinguish expected cookies from tampered cookies set by insecure subdomains. __Host prefix is basically a workaround for this but took more than a decade to get into browsers. Samesite similarly was bolted on after the fact.
Cookies aren't the only web security feature that follow sites instead of origins but they are the only one that was clearly designed without thinking through the consequences.
And that's one reason why the public-ness of a hierarchy level belongs on a DNS record on that level and not some separately-distributed side list.
I mean: why not have cookie policy set by a flag in DNS? Not unlike DKIM or even SSHFP.
Of course, we wouldn't need the entire certificate industry if we simply looked up a site's PK along with its DNS record...
Really hard to understand why that hasn't happened yet!
There would be no issue at all if Verisign, or maybe Global Name Registry, decided to stick to the 3rd level registrations exclusively. Problem is, the chucklefucks over there decided it was a good idea to also hand out 2nd level registrations. Those 2nd level registrations outnumber the 3rd level registrations by an order of magnitude, so the PSL decided to just let joe.smith.name and john.smith.name share cookies. Which, IMO, was not a good decision, but it is what it is.
Yup. The original statement was dangerous FUD which should be urgently corrected.
Needing to be familiar with all the special cases (like the VERY special case of x.y.name which I previously knew nothing about) kind of ruins everything and introduces yet more security risk.
I'm sorry, what ? Admit ? Confusion ?
In the case of .co.uk it has been around since 1996. HN is a technical forum, most people here should be well aware it is a serious SLD. I honestly can't believe it even needs clarifying.
Hell, if you use AWS Route 53 you'll see they use co.uk as one of their nameserver suffixes[1].
[1] https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/SO...
It's been around for years. I seem to remember this issue coming up around 2001 where originally .name was for third level registration (i.e. john.doe.name) and changed to second level it a few years later and caused some problems... https://publicsuffix.org/ talks about it in light of architectural limitations of domain names.
> can Joe set a cookie on all of .smith.name?
That can happen. I seem to remember ancient browsers made it so .name (and other non-generic TLDs) required three periods. I think country code domains and new generic TLDS caused the browsers to change it.
It's pretty screwed up, but a lot of the people with .name domains have had them for a very long time. Sad to see them all lose their identity online that way.
Imho email is missing a feature for nameless email addresses for when somebody just buys their full name as a domain name. If I get "firstname-lastname.name", having the email be "firstname@firstname-lastname.name' kinda ruins it.
they'll grumpily sign up to gmail just so they can get a verification email, and that'll be all it gets used for. Messaging their irl friends will be done in apps like Discord.
lol I ran a sizeable team around 2020 and I had to educate a couple of our new hires straight from college that they actually needed to check their work email, after they missed important HR related stuff and they had just completely not realized it was an avenue for company communication, with an assumption that everything was available on our heavily used slack.
If email was a commercial product, the company would have done something about that. Email died because it was an open platform, with nobody to address this systematic issue.
I've successfully renamed an old account with an email address I no longer liked. It works quite well on everything 1st party, but does have the potential of causing issues with OAuth on poorly-coded websites that key on email instead of user ID (ie. most of them). You do get to keep your old email address though, so it still ends up working fine in practice.
edit: apparently not all second level domains in .name are public suffixes anymore, so a wildcard addition wouldn't be correct.
It has to be a money problem. Something they want to do will be simpler if this is no longer a quirky registry. And they know they'll get the money back that they lose from not having bob.smith pay -- probably by throwing all the "last names" once registered this way into some "premium name" bucket and selling them for $1000 and up instead of the ~$10 that zyzgdhaf234.name fetches.
In fact, I'm not sure that scheme isn't the reason itself.
Different from .co.uk.
> The first appearance of reversed DNS strings predated the Internet domain name standards. The UK Joint Academic Networking Team (JANET) used this order in its Name Registration Scheme, before the Internet domain name standard was established. For example, the name `uk.ac.bris.pys.as` was interpreted as a host named `as` within the UK (top level domain .uk)
from the History section of https://en.wikipedia.org/wiki/Reverse_domain_name_notation
But I don’t know if uk.co.somethingsomething did or did not exist at that time. Or if it was only introduced after the Internet domain name standards we use today existed and so was .co.uk from the beginning.
Back then the code in various pieces of software had hand-written exceptions for domain processing. The joke was that all Computer Science departments in the UK (uk.ac.university-name.cs) ended up in Czechoslovakia.
.uk was opened up relatively recently.
If .gov and .mil and .com make sense, then .gov.cc and .mil.cc and .com.cc make sense.
Of course, I think having more than one non-cc TLD was a mistake, but that's just me. If it makes sense to have topical TLDs for international and US institutions, it make sense to have national ones.
Nominet and therefore .co.uk has been around since 1996.
.co.uk is not going anywhere, and neither is Nominet.
The only "problem" is the original poster did not do their homework. I suspect they were inferring `uk.co` which is a completely different kettle of fish. The original poster should urgently correct their post.
I don't have some nefarious desire to scare people away from the TLD of their choosing. Really I'm bringing it up to be like "why would you even, like, want some 3rd rate domain instead of getting a .com" so I don't think there's anything to correct
It's not reverence? I think that you're missing that it was a requirement. Basically every country (that followed ICANN's original rules) does this: .com.au, .co.nz, .co.jp, .com.mx, .co.ke (+ the org/net variants for each country)
The US is the only country where registering .com was allowed by ICANN (and not .com.us or something).
ICANN relaxed these rules in the 2010s I think, so now you can register 2LDs at most/all of those country TLDs.
Its not hard to tell for things like ".uk" or other serious suffixes.
It only (maybe) becomes hard(er) to tell for all the vanity ccTLDs that came along in the 2000s. But even then 10 seconds on WHOIS and Google should fix any doubt.
> about the reverence of `co.uk`
What are you on about ? Lots of other countries do it too. Japan is one example given already here, but there are dozens. It is very common practice for country tlds.
5 seconds on wikipedia or google would have stopped them spreading completely dangerous FUD about .co.uk.
Implying lack of trust in `co.uk`
Implying `co.uk` may suffer the same fate at `.name`
Complete FUD.
;)
(Edit: although I should add that I'm hopeful that things have improved there over the last few years).
No.
Oversimplified summary:
There was a period around 2010 when the management at the time wanted to follow a more commercial route with various unrelated "investments".
Nominet members made it impeccably clear in a very loud manner to management that it would not be tolerated.
Management insisted on a vote which they inevitably lost.
Management departed.
TL;DR Don't piss off Nominet members