It kind of seems like an insane TLD structure to begin with, right? I always thought .co.uk was bad (you're just pinning yourself to whoever owns the .co. part, but at least browsers have some suffix list where you can't, I don't know, hijack some login cookie for all of .co.).
Joe Smith and John Smith can independently register joe.smith.name and john.smith.name, do browsers have a wildcard suffix list for the 2nd level of `.name` specifically, or can Joe set a cookie on all of .smith.name?
.co.uk is run by the same people as .uk. There is no additional org that you trust when you register a .co.uk: https://en.wikipedia.org/wiki/.uk#Second-level_domains
> 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
I know about the public suffix list - I was wondering about the wildcard specifically. In the very issue you linked to, as of 2025, it seems this was still unresolved...:
> 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.
Yeah, apparently they both (used to) offer unbounded registrations of 3LDs and unbounded registrations of 2LDs? So if I see j.doe.name, the only way to find out if "doe.name" is a public suffix or not, i.e. if I should (not) be able to set a cookie on it, would be to email the registrar?
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...
I'm just saying that they have discussed the situation. They seem to have no answer and for cookies and similar things the answer probably is "maybe don't run security critical web stuff in the third level under .name".
IIRC orgs like letsencrypt also use the PSL for rate limits, so there are probably more issues that are not browser-based.
Yes, Japan does the same with .co.jp but also .ne.jp, ac.jp, etc.
There are many examples; k12.<state>.us is another.
It is (or was for a long time, IDK) a strongly recommended practice from ICANN. I imagine nearly all countries to do that.
There end up being some weird edge cases where there are some countries which have both the equivalent of .co.uk but also allow registrations directly under the two-letter country code as well. .mx is one such case where most business are, e.g., costco.com.mx, but it’s also possible to register directly under .mx as well so Toyota Mexico is toyota.mx and not toyota.com.mx (the latter is registered, and ostensibly to Toyota, but the whois and nslookup records give very different results and the website doesn’t load when I try to visit it).
This isn't so bad as .com.mx and .mx should be on the public suffix list then.
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.
uk is one example - they opened up x.uk later, and gave x.co.uk registrations first dibs.
Except nobody uses the .us tld, but pretty much every every Japanese company is on a .co.jp
It used to be that only Japanese corporations could register a .co.jp while anyone else anywhere could register for a .jp. So I had several .jp domains registered through Gandi.net.
The issue is that .jp registered outside of a few Japanese registrars are legally not allowed to offer Whois privacy.
The .us domain should’ve been universally useful for state and municipal governments, but most of those began registering directly under .gov, and not even in an orderly hierarchy under .st.gov
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.
.us was primarily a hierarchy structure which in practice made confusing and hard to remember domain names, whereas .gov addresses hand out single domains which are generally easy to remember.
Personally, I never saw anything confusing about city.state.us; the hierarchy was organized perfectly logically in the 3-tier jurisdictional structure that every American schoolboy knows by 3rd grade.
https://en.wikipedia.org/wiki/.us
But your point about them being rather longer and difficult to remember stands, and the same for a .gov, which could be shorter and catchier.
However amusingly, .us opened up second-level registrations 24 years ago, which means that any qualifying entity could have their name registered directly under .us, which is obviously recognizable, and also one character shorter, than a .gov registration. However, by that time, I believe that .gov had increased in stature so that registering governmental entities under .gov carried more certainty of conveying official status than anything under .us.
Also sadly, QR Codes and URL shorteners today sort of obviate the need to directly register the shortest possible domain name. I don't know: I was always kind of fond of the .us hierarchy, and I'm just personally sad that it's fading away.
> city.state.us
In reality, it wasn't that simple, and a lot of those .us domains looked like line noise.
Government sites are used to distribute public information. They need something they can print on a poster/sign. Not some bogus 'logical' hierarchy.
City/state/US is logical, the problem is most other hierarchies confuse people. For instance k12 subdomains for schools couldn't use that nomenclature because school districts do not map cleanly to towns. And that's before you talk about fire departments, townships, libraries, park districts, and countless other governmental bodies and districts which have overlapping boundaries of their own.
.gov certainly cares a level of exclusionary access that isn't really true of .us. Only one entity, the US federal government, can decide to hand someone a .gov address. And generally there is few signals harder to fake or impersonate than one.
Schools use it!
Based on my small sample of schools, all of the ones that were using locality based names under ca.us have migrated elsewhere, including to 2nd level domains under .us.
> Except nobody uses the .us tld
This is a bug, not a feature.
Sure, it is right now. What if they decide to sell it off?
Since neither smith.name nor the wildcard *.name appear in the Public Suffix List (https://publicsuffix.org/), browsers would likely allow any page on a *.smith.name domain to set cookies for .smith.name.
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.
I think this says more about how the cookies security model is stupid. They should always have been scoped to the single, exact name they were set from and nothing else. Websites would have had to be designed a bit more thoughtfully.
It seems like it would be easily resolvable with TXT records these days. Anyone could try, say, on www.google.com to set a cookie for all of google.com, and the browser can fetch TXT records on google.com to see what, if any subdomains, it wants to allow this privilege for. Google could return a list or a wildcard; co.uk wouldn't allow any.
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.
Totally agree that a DNS based replacement to the suffix list would make sense. Especially with more secure forms of DNS like DoH or Dnssec.
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.
[dead]
[dead]
It’s not nearly just cookies, and I think interpreting domain hierarchies as administrative structure generally does make sense.
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.
An “administrative structure” seems fine, but the fact that a subdomain gets any sort of privilege over the parent has always seemed absurd to me.
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.
That might be reasonable today, but it's not really reasonable at the time the policies were formed.
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 seems strange to me: why shouldn't policy leverage name resolution? sort of like dkim, but taken further. for instance, for site.com, I'd much rather retrieve its public key from DNS (some DNS++ version, of course).
There are use cases for cookies to affect multiple domains, like shared logins. Keep in mind multiple domains let's you run completely independent servers for different parts of your web presence but that doesn't mean that you want them to act independently.
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.
> no easy way to tell a reserved 2LD (open for 3LD registrations only) apart from a normal 2LD on .name
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'm always mystified why we haven't leveraged DNS.
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...
No, we wouldn't, you're right. We'd just replace LetsEncrypt and the ISRG with the security track records and policy integrity of the major DNS providers, many of which are state-controlled, and the largest of which are too important to revoke.
Really hard to understand why that hasn't happened yet!
You're talking about DAME (which email uses). It has it's own issues like not having transparency logs, and if a DNSSEC signing keyholder goes rogue, there is no easy way to revoke trust (unlike CRLs for Web PKI).
So, this kind of thing happens all the time, and there's the Public Suffix List for exactly this problem.
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.
Nobody owns the .co part of .co.uk. If you buy foo.co.uk, that is registered with Nominet, who are the registry for .uk.
> Nobody owns the .co part of .co.uk. If you buy foo.co.uk, that is registered with Nominet, who are the registry for .uk.
Yup. The original statement was dangerous FUD which should be urgently corrected.
Yes, but you have to admit that the existence of these SLDs (like co.uk) is always going to be a point of confusion for anyone with a basic knowledge of how the domain hierarchy _usually_ works.
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.
> but you have to admit that the existence of these SLDs (like co.uk)
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 kind of seems like an insane TLD structure to begin with, right?
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.
About 20 year ago I registered {lastname}.name and have dozens third level domains below it. So there are "privately owned" second level domains under .name for quite some time...
I'm working on same for my family since I want to properly degoogle a bit. One thing I think long term - if I give my kids first-name @ last name , that means that I forever hold power over their email. Which isn't great. But what's the alternative? Register one full domain name per kid? Even ignoring the cost, the ergonomics are awful.
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.
A child born today sees email like we see the telegraph...
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.
Truth.
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.
tbh I'm with the zoomers on this one. Work email is 99% junk. Newsletters from every SaaS product we use, "A meeting started", invitations for calendar events that I can just accept ON the calendar, notifications for every transaction on every system ("X posted a comment on Y,") and spam from salespeople, recruiters, etc. And then 1% of it is actionable important stuff that I don't get through Slack.
Email died because of the junk/spam issue. And it's self-fulfilling - when most emails are junk, nobody sends a love-letter or party invitation by email because the recipient probably won't notice it, which in turn lowers the usefulness even further.
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.
[dead]
From what I can tell most people do something like me@myname.whatever or hi@domain.
Not to mention some of those kids may end up changing their names at some point if they get married and decide to take their partner’s last name.
Aside: I'm honestly bewildered that Google doesn't have the ability to handle that in gmail accounts. If somebody gets married or otherwise needs to change their name, their answer is "just make a new google account" when all your stuff is still tied to the old account.
They rolled this out in March this year in the US (and December last year in India).
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.
Holy crap really? Yay! I know a couple of trans folks that will be ecstatic.
The feature is about fifteen years too late for me, unfortunately. By this point I need this feature to let me "merge Google accounts". But then I barely use Google anything anymore anyways.
[dead]
Surprisingly the public suffix list doesn't list `*.name`. So they're indeed not properly isolated from each other.
https://publicsuffix.org/
edit: apparently not all second level domains in .name are public suffixes anymore, so a wildcard addition wouldn't be correct.
It wouldn't surprise me if that is (maybe even a large) part of the reason for this change.
What does Verisign care though? It's been that way for way over a decade since they started allowing 2LD registrations. I very highly doubt they are suddenly so worried about random individuals' personal internet security.
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.
Note that the posted link talks about .uk.co, which currently does not exist but I guess may have in the past. Where .co is the ccTLD of Colombia.
Different from .co.uk.
Originally there was uk.co.orgname.
Huh? I don’t follow.
They might be referring to this kind of thing:
> 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.
Oh, uk.co definitely existed for companies. The other 2nd-level domain (besides the academic uk.ac and uk.co) was uk.mod (Ministry of Defence), equivalent to the US .mil. And then, because life is never this simple, things appeared that were neither universities nor companies nor military, so uk.bl was given to the British Library. There might have been others as well, I don't remember.
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.
In the UK Nominet (the UK domain namr registrar - nic.uk) only permitted 3rd domains - co.uk. org.uk, me.uk. then there were "prove your status" ones such as ltd.uk, plc.uk and ac.uk plus ones like gov.uk, mod.uk, sch.uk, nhs.uk etc.
.uk was opened up relatively recently.
I own a .uk and it still feels weird not having something in-between.
.uk.co (mentioned in the blog) isn't .co.uk
It wasn't obviously wrong in 2001. .pro started with a similar structure around the same time.
To me that sounds like reasonable structure. I hold that every single edu, gow and mil domains should be moved under respective ccTLDs. After this sort of move that doesn't seem unreasonable thing.
Agree that the .name 3rd level domains are silly, disagree on .co.uk being a problem.
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.
The 3rd level .name domains are the original ones. They didn't hand out 2nd level domains until three years after they started.
> disagree on .co.uk being a problem
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.
[dead]
[flagged]
Ok, co.uk was perhaps a bad example, because it's owned by the same registry as the TLD, but perhaps there are other 2nd level TLDs where that is not the case. My point is both that it's hard to tell, and more broadly why would anyone want their domain to be tacked on to some 3rd level subscript anyway, when there's so many plain top level domains available. Surely most of us (present company excluded perhaps) do not feel so passionately about the reverence of `co.uk`
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
> so passionately about the reverence of `co.uk`
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.
Sovereignty? If you live in the UK, choosing a registry in the UK is a pretty good idea even if they only offered 3rd levels. You’ll have someone to contact and possibly sue locally. Your domain will be subject to UK law and standards, not those of a foreign registry.
> My point is both that it's hard to tell,
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.
geez, dude, someone woke up on the wrong side of the bed this morning...
> geez, dude, someone woke up on the wrong side of the bed this morning...
5 seconds on wikipedia or google would have stopped them spreading completely dangerous FUD about .co.uk.
What's so dangerous about it?
> What's so dangerous about it?
Implying lack of trust in `co.uk`
Implying `co.uk` may suffer the same fate at `.name`
Complete FUD.
Actually, the fact that you have to cite official registrar docs is exactly the problem. There are 200+ country TLDs, and by now probably thousands of other self-governed TLDs like .name.
For instance, in Serbia, there is a similar scheme to UK: .gov.rs, .co.rs, edu.rs, but also in.rs (for individuals) and top-level .rs. So someone has registered "iz.rs" and offers free subdomains to individuals.
The fact that there is implied hierarchical trust is what the problem is, and keeping track of individual rules for each TLD is prone to errors.
You're absolutely right, when it's Nominet's actions that actually inspire a lack of trust in .co.uk, given they've been a bit of a hot mess since the early 2010's-ish.
;)
(Edit: although I should add that I'm hopeful that things have improved there over the last few years).
> given they've been a bit of a hot mess since the early 2010's-ish
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
[flagged]