That's pretty shit. You'd think changes like this would need to go through a public comment period with the affected users (much like city planning decisions do)
To be faiiiir, when your partner is absolutely zonked out in the minutes post-delivery, what else is there to do when you're by their side and still half-asleep? Time to start announcing your pride and joy to the world, starting with a domain zone file.
I mean, you've already had 10 months to come up with some name ideas. It's not like it's a huge surprise when it happens. You could even register the names before they're born.
I even suspect that the name of the child was dependent on the domain name being free... but then, it shouldn't be too hard to set up the request in advance and just press the button once the child is born. Maybe there was some rule that names could only be registered for living (i.e., born) persons?
Pretty crazy to be focused on anything other than your immediate family in after a birth... but not exactly unprecedented when you look at social media posts!
Consider whether you'd be questioning this if the author had written that within minutes of his daughter being born, her photo was on Facebook. The only thing it suffers from is not being normalized and taking marginally more* effort, while being nowhere nearly as creepy.
* or arguably the same amount or less; for additional context: the author is an ex-Googler
I think the “not applicable” is to the elided second sentence of the question:
> 3.6. Have you communicated with any of the entities whose products or services might be affected by the introduction of your proposed service? [→ No.] If so, please describe the communications. [→ Not applicable.]
Gotta say that the entire form feels not applicable. The proposed service is the discontinuation of an existing service. I see from their website that other similar things do the same, but it feels broken when so many of the questions become nonsense.
> 2.1. What effect, if any, will the proposed service have on the life cycle of domain names?
> None. There will not be any effect on the life cycle of domain names.
If they're dropping existing domain names, that seems like it has an effect on the life cycle of those domain names. I suspect I must be misunderstanding what they mean by that question, because it otherwise seems like it shouldn't have passed basic muster.
From the Verisign application [0] for this change:
> 2.1. What effect, if any, will the proposed service have on the life cycle of domain names?
> None. There will not be any effect on the life cycle of domain names.
ehhh, how is that possibly true? This change (deleting all third level names) by definition affects the lifecycle of domain names ... by terminating them!
Many years ago I wrote articles bringing attention to the negative effects of Verisign's SiteFinder [1] - if you don't remember this, it's when Verisign hijacked NXDOMAIN by redirecting any unresolvable domain to a site they owned and controlled.
"Well, it doesn't affect the lifecycle of domain names. The lifecycle is defined in some RFC somewhere, and this change doesn't modify that. Now, these particular domain name instances might be adversely affected, but you didn't ask about that." -- lawyers, probably.
You're closer than you think. Big companies and institutions just change the definition of words they don't like. In this case, they could argue that a domain's lifecycle is registration, renewal (optional), deletion. Deletion is part of the expected lifecycle, so this doesn't change it.
The ambiguity is a feature so they can do whatever they want. We all know it's bullshit, but it gives the parties involved the ability to disenfranchise one group to benefit another while claiming they're following the rules.
Here's an example of someone genuinely making that argument in another hacker news post. I'm having a laugh about how spot on I was.
> Changes to the life-cycles of domains is a question meant to ask if this seeks to modify the life cycle policy, which is a separate type of change from termination of the service as a whole. I.e. this does not seek to change the life cycle policy, it seeks to terminate the service offering completely - making the life cycle policy irrelevant.
As a lawyer myself who also has rather a bit of a technology background, I do not see how any lawyer could possibly consider that such an argument holds water.
Ok I don’t get it. Why not register `fraser.nameˋ directly? Or pick any TLD and register ˋ a 2nd-level domain (ˋfraser.tld`)? It just feels easier, plus this way you don’t have to pay for any new member of your family?
You might want to write to the CA attorney general. Former AG Xavier Becerra was able to dissuade ICANN from letting the .org fuckery happen, maybe Bonta could try to strong arm ICANN in this case.
EDIT: seems like Ethos Capital private equity firm wanted the .org registry, and Xavier Becerra (Attorney General of California at the time) wrote a letter that played major role in transaction being rejected
> Dear Messrs. Botterman and Marby:
>
> I urge ICANN to reject the transfer of control over the .ORG registry to Ethos Capital.
> The proposed transfer raises serious concerns that cannot be overlooked.
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?
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.
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.
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...
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.
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.
It’s not something anyone else in the world seems to struggle with, where there are *.gov.uk, *.edu.au etc.
If anything the .gov, .mil and .edu being just American is confusing, as well plainly inappropriate (it feels like an American cultural imperialist thing to people from outside the US). It would have been much better if those had been retired decades ago and moved to under the .us TLD, so e.g. whatever.edu would become whatever.edu.us like every other country. Any existing domains on .gov, .mil, .edu etc. should only be allowed to exist as 301 redirects.
It's imperialist to own and control the thing you created?
If .gov had been an international TLD that was at some point available to everyone, or had been created by everyone, ok. But .gov was created as part of the work the US government did to build out the initial DNS structure. It probably wasn't even a given at the time that arpanet would be international in nature
Also, 301 redirects are not a DNS thing, that is an HTTP thing. Not sure how that would solve your problem since HTTP is intrinsically at the base of it tied to A or AAAA records. DNS does a lot more than pointing to websites
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.
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).
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 stub records in near real time and lots of domains seem comfortable with delegating the whole thing to their CDN.
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.
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.
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).
Web PKI also has not had transparency logs until fairly recently. And Web PKI revocation is a joke as well. At least a "rogue" DNSSEC signer can only sign domains they have been delegated authority over and not literally everything.
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 can chose under which registry you can register your domain. You cannot choose which (in many cases also state controlled) web PKI certificate authority can sign certificates for your domain name. And Web PKI revocation is a joke that many clients don't check at all and others do using privacy-hostile mechanisms.
But sure, keep spreading FUD like you always do on this topic.
For the last 2 years, I've tracked the Tranco Top 1000 sites, continuously checking DNS to see if any major sites have turned on DNSSEC (6% of the Top 100 do --- many of them government sites). Over those last 2 years, a total of 8 sites in the Tranco list have enabled it. It happens so rarely I could reasonably call them on the phone and share my misinformation about how moribund DNSSEC is to them directly.
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.
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.
They probably didn't realize why they needed multiple apps to communicate inside the company.
I was in a situation where we had slack for communication between teams, email for corporate stuff similar you described, zoom for calls, personal messengers like WA for communicating with people in the company who didn't have slack, SMS/phone calls for alerts and various on-call staff. Total nonsense. No surprise I missed something.
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.
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.
Funnily I did exactly this, so the {lastname}.name is now legacy for me and nobody else of my family ever picked up the offer to have {firstname}@{lastname}.name adresses anyway.
Later (but before my name change) I managed to secure {lastname}.de which I stupidly missed during the early internet due to being a stupid teenager with stupid convictions. If I had secured this back in the day I think they would happily started using it but now they are all too settled in their provider/free webmail addresses.
Nice twist: The father of my wife owned {newlastname}.de since the dawn of the internet. So I'm still fine on that front. ;)
1. ANY 2LD ending '.uk' is managed by Nominet[1] (co.uk, sch.uk, gov.uk etc. etc.)
2. FUN FACT ... Nominet introduced the ability to register directly under `.uk` much, much later, in 2014. Before 2014 your only option was to register under the auspices of a Nominet managed 2LD, e.g. `co.uk`.
I suspect you meant 'uk.co' and other such shenanigans. Please correct your post accordingly.
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
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.
> 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.
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.
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.
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.
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.
> 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.
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.
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 and .co.uk are both run by Nominet, the UK registry.
Quirky stuff like .co.uk / .org.uk / .sch.uk 2nd level domains partly come around from .uk being the worlds first CCTLD outside the US (and as other parts of this thread say, .us isn't that popular a CCTLD).
Everything was new and different people tried different hierarchy and structures to 2LD and 3LD's. .co.uk is also far from unique, I know this is common in many other places (UK/NZ/IN/ZA/KR/MX).
The UK now allows directy foo.uk registrations as well, but many people still have SLD's registered and will continue to do so.
It definitely makes sense for stuff like (non-US) gov domains. Have a federal agency control the `gov.<ccTLD>` domain and hand out subdomains to other agencies. See https://dachmarke.gov.de/ for example.
> Once the 3rd-level domains are terminated, it is assumed that the now vacant 2nd-level domains will become available for registration. Should someone (other than me) scoop up fraser.name (...)
What's to stop someone from doing that, and keeping the status quo? Sure, it might be expensive, but pool together a few frasers for the initial buy, and make the money back on the sublets.
Well, nothing, but it does assume that Verisign doesn't have an unstated plan to do something else with .name. Domain registration is the real estate of the Internet and very little that has happened in the last 30 years of domain name policy has been for the benefit of anyone outside the the registrars.
For all we know, this is simply the first step in a series of moves for Verisign to better monetize the .name TLD in some novel fashion.
My evidence for this is that Verisign's own arguments for terminating the third-level domains are highly dubious. They claim that the third-level domains are too hard for them to manage. Bollocks: there are only 22,000 of them in use. That is a VERY small database that practically fits on a calculator and I refuse to believe that any manual labor around it is an outsized burden compared to pretty much any other semi-popular TLD. The second claim is that "the majority of those are not in use." Okay, if that's true, then where is the management burden coming from? That means tens of thousands of people are giving them money and getting nothing in return, isn't that the definition of an ideal business model?
It just doesn't pass the sniff test.
And finally, having read both of the linked documents, it sounds like people who have registered their .name for years in the future are not getting their money back. Are they likely to pay a second time, to a sub-registrar with no history?
Not just someone, Verisign managed to run this registry since its delegation.
Restrict future 3rd level registrations, offer a path to upgrade a 3rd level registration to a 2nd level registration for those 2nd level domains with a single registrant and the burden will decrease over time.
There is a problem with registrars dealing with the third level domain because it requires a different UI at the very least and many of them just decline to do it. It has become increasingly hard over the years to find one that will do it.
Verisign could create a work-around by defining a format at the second level - such as ml--2-4-johnsmith.name in which the first number is the number of levels, then there are n - 1 numbers to identify the number of characters at this level, so in this case it would map to john.smith.name at the registry level. There are only about 5 or 6 existing second level domains that are too long for that to work and they could be remapped as, say, ml--id-1 through to ml--id-6.
Since the double dash at that position is reserved for registries (the registry should reject a registration with double dash at that position outside of its own defined uses and xn-- for punycode domains) , this would allow Verisign to facilitate those domains being managed (or even created afresh as long as they are not too long) as if they were second level domains while continuing the third level domain service, avoiding the registrar implementation problem.
They won't do it though because Verisign has never been known for the customer-focus or corporate responsibility.
That's 22k people with third level domains like first.last.name. There are close to 100,000 second level last.name registrations, which are not going anywhere.
Surely the author must have anticipated some heightened level of risk in pegging important parts of his personal and business life on a nonstandard TLD like this.
It's a pretty bizarre exception to the normal, intuitive ways that domains work.
I'll admit that it's a crappy situation and I would be frustrated in his place. But if I were in his place, I probably would have also thought it prudent to have a backup plan.
What exactly is non-standard about an ICANN-approved TLD? Yes, the multi-level structure is a little odd, but given that ICANN approved it in the first place, one has a reasonable expectation that they would work as advertised.
I mean, we could say much the same of any other non-country TLD, and probably half the country TLDs. That doesn’t mean one shouldn’t expect it to be administered responsibly
Non-standard as in "it's not up to my usual standards" not "is not part of a technical standard". I.e. it's a gTLD rather than a "standard" (in the previous sense) TLD.
.name is in no way a "nonstandard TLD." It has been in existence for a quarter of a century and was part of the first batch of new gTLDs approved after the dot-com boom had begun, in 2000.
For the first couple of years of .name's existence, it only allowed registration of third-level domains, and the ability to register second-level domains was added later (and only if no third-level domains existed for that second-level domain).
The author is in no way at fault here, and I don't think I would have assumed there was a heightened level of risk if I were him.
Anything other than .com, .net, .org, and well-known ccTLDs I see in search results subconsciously get skipped over as "probably SEO spam or other useless content". These new weird TLDs are like the .tk and .us of old.
We were rescued from that dot org scam by the fact that ICANN is a California non profit. I wonder if the AG can lean on them again. This is an outrageous thing to do.
MagicMoonlight was [dead]ed for not knowing what "dot org scam" refers to. Since I can't reply there right now and it's not reasonable to expect everyone to know what this refers to:
ICANN, a 501(c)(3), proposed to remove the price cap on .org, a TLD commonly used for non profits, registration so the registrar PIR, also a 501(c)(3), could then announce it planned to sell .org operations to private equity investment firm Ethos Capital. Thankfully the overwhelming response caused the proposal to be scrapped.
> MagicMoonlight was [dead]ed for not knowing what "dot org scam" refers to.
This is a very hn thing (shadow-banned accounts should not be able to comment though and should be treated differently than "dead" because I could see the comment). I was accused by a fellow hn'er just a few days back I was performing ignorance because I didn't know something very US specific legal term and had asked in a sub thread. Another person said I could just google that, or ask an AI.
Coming back to the scam - it's bizarre to think ICANN could begin to do that! TLDs are such a basic aspect of online identity today and just to think that an outrage, i.e an overwhelming response, caused the proposal to be scrapped, is unsettling.
I am not sure but we should rather move to something else or remove this power from such for profit companies or non-profits that often behave worse than for profits, or at the behest of them.
I wonder how long that'll last. If the regulators in Califonrnia keep forcing them to act in the public's interest, won't they just move to a more favorable jurisdiction?
This crossed my mind too. At least such a move could serve as an indication to the international community that ICANN is not a good steward of name and number resources. If they're paying attention. I know our (the US) governance is full of crap like this.
I've had a .name domain forever and I had no idea first.last.name was even a thing, meaning that it was possible to register this without owning last.name.
That said, my domain is simply unusual.name, and everybody in my family has email addresses in the form first@unusual.name. So this is a no-op for me, and I gather www.unusual.name will also continue to work, since I own the 2nd level outright.
This is silly question, but is your family managing trust in you as lone guy - cousin, father, brother - having potentially access to all their emails?
I feel that I more trust some corpo (Google, etc) that one particular person.
I don't imagine setup where you can effictevely guarantee them full privacy.
Some people in my family use it as their main address, others don't, it's entirely their call.
But yes, ultimately I control the domain and could be nefarious if I wanted to. But there's a certain baseline level of trust as a family, I'm reasonably certain my wife won't poison the milk in the fridge and she's reasonably certain I'm not going to read her emails.
There's a document explaining how it all works, and I have Google's Inactive Account Manager setup to transfer credentials to my trusted contacts if I go permanently offline.
I'm reasonably certain my wife won't poison the milk in the fridge and she's reasonably certain I'm not going to read her emails.
This is only a safe bet until it isn't. If she starts asking about your life insurance and hiding her phone from your view, you will know it isn't a safe bet anymore.
> This is silly question, but is your family managing trust in you as lone guy - cousin, father, brother - having potentially access to all their emails?
I believe this is a very common setup: the "computer wizard" kid of the family manages the computers for the whole family. Not just emails, they have access to the whole computer (and have to fix when it breaks).
I manage the email accounts for the others in my household because it's free for them and I'm happy to do it. Plus, they trust me more than they trust a random tech company. Maybe that is not a universal thing among all families or parts of the world.
The implication, that one should make a plan for that, is a valid reminder not enough of us probably do.
But it hardly needs to be difficult. If you're running dovecot and postfix on a server somewhere then yes, family is screwed. But it's simple to use either some mail forwarding service that you pay for with a credit card, or something like fastmail (etc). Leave 2 pages of instructions for how to log into and renew the domain (print the QR code used for the 2fa enrollment!) and how to log in and pay for whatever the underlying services are. Place in a binder and label "Family.Name Email Management" and put it with your other important documents.
But more seriously, my domain and VPS is on auto-pay, so it doesn't just shut off the day I die. My survivors will have plenty of time to back up their emails and do whatever they want with them afterward.
Plus, the password for my computers and keychain is in a safe-deposit box if they feel like handing it over to a trusted tech-savvy friend of the family to shut down properly.
It was deemphasized pretty early because people didn't understand it.
It made sense to us because our starting point was an email service letting people share lastname.sometld, but we never got close to as many registrants on .name as we had users on the webmail service (we had a couple of million accounts on that when it was sold to one of Marc Cubans companies for a relative pittance in the aftmath of the dot com bubble bursting)
I'm sure Verisign would be thrilled to have a bidding war between the legitimate owners of fraser.name and a bunch of third parties they suddenly enabled.
> In April 2019, ICANN proposed an end to the price cap of .org domains and effectively removed it in July in spite of having received 3,252 opposing comments and only six in favor. A few months later, the owner of the domain, the Public Interest Registry, proposed to sell the domain to investment firm Ethos Capital. After intense criticism from nonprofit groups and significant figures in Internet history, the proposal was scrapped.
Surprisingly not by Verisign, who gave up .org in 2003.
It seems like the right thing they should do is discontinue new registrations but continue to honour existing ones (+ continuing to reserve any 2LD that has a 3LD registered on top). It’s a bit insane that they can decide to just terminate all existing 3LD registrations. One would hope that they’d at least continue to reserve the 2LDs for some period to avoid domain squatting, but this isn’t mentioned in the proposal and I doubt Verisign would graciously do so.
I'm surprised they don't just do that, and maybe even to go a little further, disallow renewals so you can phase people out and reclaim domains you can sell.
Whether disallowing renewals or terminating them tomorrow, there's still the same core problems, only the date of the offense changes: (1) seizing people's names that they've established, breaking innumerable things including email and server hostnames, and (2) the possible resale of the 2LD fraser.com to a third party who will be free to do malicious things like reading OP's email, redirecting his traffic, or extorting him, to sell continued access at any price demanded.
There's one less core problem: those who just bought/renewed their domain e.g. yesterday are fucked out of both their money and forced to migrate sooner than they could have reasonably planned for. People's who registrations expire and they are unable to renew is a very different level of unfairness and inconvenience.
In either case, the security concern should be directly addressed.
Well, I'm guessing that Verisign will throw people a bone in terms of refunds just to avoid getting repeatedly hit with justifiably spiteful lawsuits that (I hope) would be trivially easy for customers to win.
That will cost them very little in terms of cash, as I doubt that many people register that many years ahead, plus in terms of accounting, they won't have accrued that revenue anyway so it wouldn't even hurt their books. Not that a couple hundred K would even matter on the financial statements of a giant, money-printing corporation like that.
The reason why they wouldn't go the route of waiting for expiry is that at least a few have nearly a decade left, and clearly they really want these gone, not just reduced in number. By 2036 when they would finally get to that point, I doubt whatever's driving this concern would even matter.
If hosting a zone and handling the odd customer transaction is "too much work", giving a refund to avoid all the aggravation of getting sued seems a lot like the easiest and best option
That would be so cool and would make these limited hot commodities.
.name was one of the very first expansions of gTLDs back in the very early 2000s. It's a shame that it's being shut down as it was spearheaded by the ICANN itself rather than some registrar / investor like Donuts, Inc.
I suppose this is impractical as someone has to run the registry and there are costs associated with that. But don't the domain fees cover it?
From having worked in that space what feels another lifetime ago, I vaguely recall that you can just offload the registry work to a registry that would manage this together with a mountain of other TLDs.
As I recall it. This was mostly a money scam that targeted private users with ads like "make sure to claim to your .name domain so no one else does it and use it to impersonate you". It was stupid from the beginning and never took off.
Maybe they want to avoid the ambiguity between john.doe.name versus john-doe.name, and I assume they prefer the latter scheme because it probably sells better. Nevertheless, discontinuing existing domains is disgraceful.
Even that doesn't pass basic scrutiny. The same ambiguity can and always will exist with tim-apple.com and tim.apple.com - there's nothing here that needs fixing.
> The same ambiguity can and always will exist with tim-apple.com and tim.apple.com
Similarly, I recently got a scam email that linked to de-apple.com (not a domain owned by APPLE) and also used apple.com-18221.com (also not apple.com).
I reported those domains to the registrar, but apparently it is not impersonating enough to take action.
Was it even possible to register just a second level .name domain name? It sounds like it wasn't, so therefore no one would be using john-doe.name and there'd be no ambiguity.
It's exceedingly charitable of you to try to infer a good reason for what they're proposing. I say "exceedingly" because in their proposal they had the opportunity to present a good reason, and they chose not to use that opportunity.
Another thing that should be obvious and yet they refuse to do: when there is a single third-level customer for a given second-level, offer them a way to get the second level domain. I've been asking VeriSign this for 15+ years, they always said no, even if at some point they confirmed that there were no other third-level than mine under that second-level domain. They're insane and should not be in charge.
I remember back when we had to write mechanize scripts to drive a browser through the renewal process, because if you had dozens, hundreds, or thousands of domains there was no nonmanual way, especially if you wanted extended verification or something silly like that.
So what I'm saying is, agreed and that has always been true.
I was working for a company that had hundreds and thousands of domains. It was a fortune 50 company, and they had a policy generally against wildcard domains.
Instead of registering foo.com, and having bob.foo.com, they would register bobfoo.com - they had hundreds or thousands of certs, as a result, and had to renew them all annually or biannually. We didn't even manage all of the domains, we just had to renew the ones our group was responsible for, and it was in the dozens, and each form was ~30-40 actions to fill out correctly. I forget whether they were quarterly or we just ended up doing it all the time, but it was a maddening task.
Part of the explosion was that domains were not just in one TLD, they were bobfoo.com bobfoo.bar bobfoo.xyz and in many cases regionalized to bobfoo.co.uk or whatever. It wasn't "domain hoarding", because if you registered bobfoo.info you'd just get UDRP'd by corporate anyway, and nobody really wanted domains of the form somelongnamebobfoo.com
This was also before something like LetsEncrypt where you could automatically generate certs for programmatic usage, so they were all done manually.
Should Google be allowed to keep Google dot lol if it doesn't do anything useful with it? What about Google dot wtf? Any person with two brain cells would say these domains should belong to a fervent critic of Google, not to Google.
Sadly neither our world not its legal system is built on common sense.
Why would they want to drop the possibility of selling some as premium domains? If they have their shells setup right they will probably be able to get a premium from some 3rd level domain owners wrongly afraid someone else is interested.
The main problem with the Internet today is that we didn't destroy ICANN when they started this TLD sell off crap. A replacement institution may have at least told Verisign a TLD they can't run transfer to someone who can meet its promises can only be destroyed.
Because it's not worth it financially. After icann is the tld registrar, and after that above. So, if anyone is destroying it, it's not the registrar, it's the tld.
>> In light of the fact that Verisign and ICANN are in the process
of discussing the upcoming renewal of the .NAME Registry Agreement, ICANN is issuing Verisign this letter in lieu of a contract amendment to the expiring
It's clear to me ICANN can say no agreement change or total destruction. You are correct that they could do something else and show every indication that they would never do the right thing and that is why they should be destroyed.
The .name predates the TLD well-off crap. The first huge bulk of new TLDs happened in 2014, .name dates back from 2001. Also, .name filled an actual need for general non ccTLD: companies had .com, organizations had .org, Internet related stuff had .net, there was .gov, .edu, .mil, and ccTLDs, but nothing made for individuals. It filled this use case, it actually made sense.
> Also, .name filled an actual need for general non ccTLD
That's a silly idea. While there are laws that ensure to a decent extent that there is a single company called "Google", so that it's relatively unambiguous who `google.com` should refer to, there is no uniqueness whatsoever to personal name. There are likely hundreds of thousands of people called "John Smith", so the FQDN `john.smith.name.` would not really tell you anything.
This is without even going into the fact that "first-name.last-name" is culturally specific (though, to be fair, a large proportion of cultures in the world use this format).
> While there are laws that ensure to a decent extent that there is a single company called "Google"
There aren't laws to ensure that. Within specific jurisdictions, sure, but not globally.
A lot of companies also don't trade under their full name. Apple, famously, wasn't founded as Apple but as Apple Computer, and was only able to rename after achieving a deal with Apple Records.
The lack of more namespaces also led to things like nissan.com being owned by Uzi Nissan (and now his family, I assume) rather than the car company.
While you're right that there are many duplicates, one extra TLD still broadened the namespace a lot, and the most important part of the idea was that by giving people less of a reason to register <lastname>.com or <lastname>.cctld, we'd give far more people the option to get <firstname>@<lastname>.name as an email address.
(The cultural aspect is irrelevant - it was not enforcing a specific order. If people wanted to register lastname.firstname.com, nothing would stop that)
By the time we applied for .name we actually had experience running a webmail service where people shared ~60,000 domain names, and had ~2 million accounts on that, and we'd done extensive modelling before acquiring those, and as a result at the time we probably had better data than anyone on the distribution of names worldwide.
What we seriously overestimated (every applicant overestimated how popular the new TLDs would be, but the generic ones, generally did better) was how many people were in the intersection of people who'd figure out how to buy a domain name and people who wanted firstname@lastname.name as an e-mail address.
> There aren't laws to ensure that. Within specific jurisdictions, sure, but not globally.
Many trademarks are indeed more or less global.
> A lot of companies also don't trade under their full name. Apple, famously, wasn't founded as Apple but as Apple Computer, and was only able to rename after achieving a deal with Apple Records.
That's irrelevant - Apple Computers owns the Apple trademark (for certain industries).
> The lack of more namespaces also led to things like nissan.com being owned by Uzi Nissan (and now his family, I assume) rather than the car company.
It's not perfect and not guaranteed to be unique, yes. But people's names have many orders of magnitude more collisions.
> <firstname>@<lastname>.name as an email address.
No, you'd at best get `??@firstname.lastname.name` as your email address. Which, again, is irrelevant, as it's impossible to say which of the many thousands of Firstname Lastname people this might belong to.
> (The cultural aspect is irrelevant - it was not enforcing a specific order. If people wanted to register lastname.firstname.com, nothing would stop that)
I wasn't referring to a specific order, but to the cultural idea that people have 1 firstname and 1 lastname. In Spain, for example, people typically have 1 first name and 2 last names - but you couldn't get `a.b.c.name` as an address. Having a first name, a middle name, and a last name is also very common.
There are also cultures where people simply have one name, not first + last. For example, a person's full legal name in Tibet might just be "Woeser".
And the vast majority are not, so this has no relevance.
> That's irrelevant - Apple Computers owns the Apple trademark (for certain industries).
And yet you yourself concede in this very same statement that it is not absolute. Even with one of the most famous examples from one of the largest companies in the world.
> It's not perfect and not guaranteed to be unique, yes. But people's names have many orders of magnitude more collisions.
For most people our data was very clear that for most names the number of collisions are in fact relatively low, further significantly mitigated by the combination of nicknames and ability to use middle names. Very few last names are highly frequent, and very few of those with common last names have an intersection of a very common first name and a very common last name. The vast majority of people fall in a long tail of last names held by a few thousand people, and first names held by a few thousand people.
For the webmail service that preceded .name, the vast majority of the two million accounts registered were for names for people who would have no way of getting their firstnam@lastname.<tld> addresses without it because of colissions. That some of those would not be able to get one of our addresses either because their specific combination was particularly common does not alter the objective fact that we massively broadened the availability.
> No, you'd at best get `??@firstname.lastname.name` as your email address. Which, again, is irrelevant, as it's impossible to say which of the many thousands of Firstname Lastname people this might belong to.
No, that was categorically not how it worked. I personally designed the system to handle this. We provided firstname@lastname.name e-mail forwarding to an address of the registrants choice, and provided a reference platform for registrars to support that, that I also designed, and managed the implementation of.
Given that you haven't even bothered to understand what it provided before criticising it, it's hard to assign much value to your arguments.
> I wasn't referring to a specific order, but to the cultural idea that people have 1 firstname and 1 lastname. In Spain, for example, people typically have 1 first name and 2 last names - but you couldn't get `a.b.c.name` as an address. Having a first name, a middle name, and a last name is also very common.
Spanish people are perfectly capable of using their firstname and their fathers first lastname when limited to one last name. They are also capable of using 2, 3, or 4 last names depending on context and preference. For any that wanted to use more, they had more flexibility, because they could similarly register b.c.name, and use a.b.c.name, or register any combination preferred for the last two labels and set up the rest themselves.
Same if you insisted on using your middle name. We only provided the increased ability to share among those with overlapping two last labels, but that did not change the ability to use regular DNS features.
> There are also cultures where people simply have one name, not first + last. For example, a person's full legal name in Tibet might just be "Woeser".
While you're right that exists, firstly it's a miniscule proportion of people. We collected stats on that two. If you fell in that group, your options were either to use another TLD, or use another indicator. In Europe as well, in cultures that used to use only one legal name, people would still regularly use distinguishing attributes, such as place names or occupations. In fact, both of those are the source of most legal lastnames in Europe today. E.g. my last name is the name of the farm my great great grandfather came from, and names like Baker and Smith are occupations.
There is no need to be able to be a perfect match to a given format for everyone to still meaningfully and significantly enlargen the available ...
Fun fact: The Peter Morgan listed on that page was an actual employee of Global Name Registry. I believe he agreed to sign a contract to let us use the name as example.
That's the crazy part - they can take your money, prorated to some future-period but, upon cancellation, the remaining future period of YOUR money becomes THEIR immediate revenue recognition. Is it fraud or theft? To me, it has to be one or the other...
And lets be clear here, refunding the registration fees should NOT be considered even close to sufficient compensation as Neil and others like him have reasonable assumed they would control the name for that time and made choices that depend on that.
Having a mix of both 2LD and 3LD registrations under the same TLD is a bit of a nightmare in terms of public-suffix list [0], which is kind of important thing when enrolling your domain for some services, cloudflare among them.
The problem DMARC solves is different than the problem the PSL solves, though. DMARC prevents a 3LD from pretending to be a different 3LD on the same 2LD. But the PSL handles things like what it means to make a "cross-site request" or how to handle cookies.
I mean now I'm thinking if DMARC _could_ solve that... but I don't think it could, unless I'm missing some extension or rare use case.
I think DMARC works well because email tends to blindly trust DNS (opportunistic encryption). On the web we expect authenticated TLS, often strictly enforced (organization policy, HSTS). So it would feel weird if a website changes how it handles HTTPS cookies based on an insecure DNS record, perhaps delivered by the resolver on an untrustworthy WiFi router.
Specifically, if I register subdomain attack.co.uk and set up a malicious WiFi router, I trick some *.co.uk cookies to get set on co.uk and then steal them from attack.co.uk by tampering with the (proposed) SVCB record.
I think the signal needs to be secure, which means DNSSEC. Adding a hard requirement for DNSSEC validation in all web browsers is a huge change from where we are now.
And essentially boils it down to ‘either the client implements wire-security to a known dns server using DoH or DoT, implements dnssec to verify the untrusted response as legitimate, or the client risks being mitm’d to attacker addresses’. They ultimately sidestepped the problem by structuring it to be hints rather than guarantees and thus allowing DNSSEC to be optional, and so as of today, it’s definitely not sufficient to implement this.
I think that adding a CORS rejection to DNS — declaring subdomains independent of a TLD, that is — does not require DNSSEC, so long as clients adhere to the steps to prohibit attacker interference described. But it still asks a great deal of DNS that I’m unsure is possible today, not just in DNSSEC but in ripple-subward records that somehow tie into client responses.
More likely, I assume browsers will simply permanently end all service to the concept of subdomains at all; no cookie sharing across domains at all, no inherent cross-origin just because tld and www.tld share a few characters, etc. rather than either depending on the PSL or having to implement strange and complex DNS anything. Admins will throw their hands up about it, but the net is no longer a place where control of a TLD defines the trust of its subordinates, so it’s certainly time to rip that bandaid off if they haven’t yet.
The PSL is a giant hack that gives the PSL maintainers authority over something that should be a hierarchical delegation. It's an affront to the DNS system and should not be considered to have any relevance by ICANN or any standards bodies.
In the tech industry of yore, the concept of corporations being responsible for tech stewardship was a quaint necessary evil to placate the developer crowd so you could hire them. Today, c-suites consider that indulgent soft-hearted hippie nonsense utterly gauche.
It seems insane because it seems like a big point was to have a permanent site for your name. This just devalues all domain names, showing that they can do a rug-pull at any time because they don't want to manage it (how about turn it over to a private company that can adjust costs so they can make a profit and keep it running?).
This is why new gTLDs are insane and stupid. It is about time there is some _yours for life_ DNS system.
In this age, allowing domain names to be owned by other entities is almost like allowing a company business registration number or one's national id card number to be transferred to others.
I think name squatting is a problem, but it is not like that current system has solved it.
DNS names are never permanent, they are in fact extremely im-permanent, always requiring periodic re-registration (though, to be fair, with pre-emption rights, so you have some guarantee of keeping your registration if you don't forget).
Wow! Years ago I initially bought my firstname.lastname.name, then I let it expire and then bought lastname.name. So glad I did!
Never dreamed that such a supposedly durable thing would just disappear. How hard is it really to preserve a global resource like this that exists only in software?
So, where is our fully decentralized TLD alternative, free of ICANN or any central authority to handle how we grant names by conventions, without any money scheme in the game that attracts malevolent actors moving only through greed strings?
Also, this time let’s make it like usenet, so "person:named:Neil Fraser" or even "::Neil Fraser" (harder to type but less culturally entangled into English).
> So, where is our fully decentralized TLD alternative, free of ICANN or any central authority to handle how we grant names by conventions, without any money scheme in the game that attracts malevolent actors moving only through greed strings?
We can all edit our hosts file.
The problem with a lack of a central authority is domain names are most useful if they follow the highlander principle. There can only be one neil.fraser.name ... otherwise it's not usable for routing traffic if every webserver a Neil Fraser runs uses that address. (Yes, there are useful ways for one name to resolve to different webservers, but almost always those are webservers under at least loose control of a single entity or very exceptional cases)
386 comments
[ 0.22 ms ] story [ 13.2 ms ] thread...minutes?
* or arguably the same amount or less; for additional context: the author is an ex-Googler
> 3.6. Have you communicated with any of the entities whose products or services might be affected by the introduction of your proposed service? [→ No.] If so, please describe the communications. [→ Not applicable.]
Gotta say that the entire form feels not applicable. The proposed service is the discontinuation of an existing service. I see from their website that other similar things do the same, but it feels broken when so many of the questions become nonsense.
> 2.1. What effect, if any, will the proposed service have on the life cycle of domain names?
> None. There will not be any effect on the life cycle of domain names.
If they're dropping existing domain names, that seems like it has an effect on the life cycle of those domain names. I suspect I must be misunderstanding what they mean by that question, because it otherwise seems like it shouldn't have passed basic muster.
How is this possible? I thought there was a 10 year limit.
Many years ago I wrote articles bringing attention to the negative effects of Verisign's SiteFinder [1] - if you don't remember this, it's when Verisign hijacked NXDOMAIN by redirecting any unresolvable domain to a site they owned and controlled.
[0] https://itp.cdn.icann.org/en/files/consensus-policies/rsep-2... [1] https://en.wikipedia.org/wiki/Site_Finder
The ambiguity is a feature so they can do whatever they want. We all know it's bullshit, but it gives the parties involved the ability to disenfranchise one group to benefit another while claiming they're following the rules.
> Changes to the life-cycles of domains is a question meant to ask if this seeks to modify the life cycle policy, which is a separate type of change from termination of the service as a whole. I.e. this does not seek to change the life cycle policy, it seeks to terminate the service offering completely - making the life cycle policy irrelevant.
EDIT: seems like Ethos Capital private equity firm wanted the .org registry, and Xavier Becerra (Attorney General of California at the time) wrote a letter that played major role in transaction being rejected
> Dear Messrs. Botterman and Marby:
>
> I urge ICANN to reject the transfer of control over the .ORG registry to Ethos Capital.
> The proposed transfer raises serious concerns that cannot be overlooked.
(from https://itp.cdn.icann.org/en/files/correspondence/becerra-to...)
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?
> 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.
IIRC orgs like letsencrypt also use the PSL for rate limits, so there are probably more issues that are not browser-based.
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...
This is a bug, not a feature.
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.
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.
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.
If anything the .gov, .mil and .edu being just American is confusing, as well plainly inappropriate (it feels like an American cultural imperialist thing to people from outside the US). It would have been much better if those had been retired decades ago and moved to under the .us TLD, so e.g. whatever.edu would become whatever.edu.us like every other country. Any existing domains on .gov, .mil, .edu etc. should only be allowed to exist as 301 redirects.
If .gov had been an international TLD that was at some point available to everyone, or had been created by everyone, ok. But .gov was created as part of the work the US government did to build out the initial DNS structure. It probably wasn't even a given at the time that arpanet would be international in nature
Also, 301 redirects are not a DNS thing, that is an HTTP thing. Not sure how that would solve your problem since HTTP is intrinsically at the base of it tied to A or AAAA records. DNS does a lot more than pointing to websites
Different from .co.uk.
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.
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 stub records in near real time and lots of domains seem comfortable with delegating the whole thing to their CDN.
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.
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!
But sure, keep spreading FUD like you always do on this topic.
https://dnssecmenot.fly.dev/
The PKI run by state-level actors isn't going to happen.
Are there any remaining CAs in browser root stores that don’t enforce CAA record validation?
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.
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.
Nice twist: The father of my wife owned {newlastname}.de since the dawn of the internet. So I'm still fine on that front. ;)
What the hell are you talking about ?
1. ANY 2LD ending '.uk' is managed by Nominet[1] (co.uk, sch.uk, gov.uk etc. etc.)
2. FUN FACT ... Nominet introduced the ability to register directly under `.uk` much, much later, in 2014. Before 2014 your only option was to register under the auspices of a Nominet managed 2LD, e.g. `co.uk`.
I suspect you meant 'uk.co' and other such shenanigans. Please correct your post accordingly.
[1]https://nominet.uk and https://www.nominet.uk/wp-content/uploads/2025/03/UK-rules-o...
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
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.
> 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.
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.
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.
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.
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.
.uk was opened up relatively recently.
Quirky stuff like .co.uk / .org.uk / .sch.uk 2nd level domains partly come around from .uk being the worlds first CCTLD outside the US (and as other parts of this thread say, .us isn't that popular a CCTLD).
Everything was new and different people tried different hierarchy and structures to 2LD and 3LD's. .co.uk is also far from unique, I know this is common in many other places (UK/NZ/IN/ZA/KR/MX).
The UK now allows directy foo.uk registrations as well, but many people still have SLD's registered and will continue to do so.
What's to stop someone from doing that, and keeping the status quo? Sure, it might be expensive, but pool together a few frasers for the initial buy, and make the money back on the sublets.
For all we know, this is simply the first step in a series of moves for Verisign to better monetize the .name TLD in some novel fashion.
My evidence for this is that Verisign's own arguments for terminating the third-level domains are highly dubious. They claim that the third-level domains are too hard for them to manage. Bollocks: there are only 22,000 of them in use. That is a VERY small database that practically fits on a calculator and I refuse to believe that any manual labor around it is an outsized burden compared to pretty much any other semi-popular TLD. The second claim is that "the majority of those are not in use." Okay, if that's true, then where is the management burden coming from? That means tens of thousands of people are giving them money and getting nothing in return, isn't that the definition of an ideal business model?
It just doesn't pass the sniff test.
And finally, having read both of the linked documents, it sounds like people who have registered their .name for years in the future are not getting their money back. Are they likely to pay a second time, to a sub-registrar with no history?
Restrict future 3rd level registrations, offer a path to upgrade a 3rd level registration to a 2nd level registration for those 2nd level domains with a single registrant and the burden will decrease over time.
Verisign could create a work-around by defining a format at the second level - such as ml--2-4-johnsmith.name in which the first number is the number of levels, then there are n - 1 numbers to identify the number of characters at this level, so in this case it would map to john.smith.name at the registry level. There are only about 5 or 6 existing second level domains that are too long for that to work and they could be remapped as, say, ml--id-1 through to ml--id-6.
Since the double dash at that position is reserved for registries (the registry should reject a registration with double dash at that position outside of its own defined uses and xn-- for punycode domains) , this would allow Verisign to facilitate those domains being managed (or even created afresh as long as they are not too long) as if they were second level domains while continuing the third level domain service, avoiding the registrar implementation problem.
They won't do it though because Verisign has never been known for the customer-focus or corporate responsibility.
I don't know what that history is, but did it really make a tld used by only 22k people more appealing?
https://www.icann.org/resources/pages/name-2014-03-03-en
It's a pretty bizarre exception to the normal, intuitive ways that domains work.
I'll admit that it's a crappy situation and I would be frustrated in his place. But if I were in his place, I probably would have also thought it prudent to have a backup plan.
What exactly is non-standard about an ICANN-approved TLD? Yes, the multi-level structure is a little odd, but given that ICANN approved it in the first place, one has a reasonable expectation that they would work as advertised.
Uh, 99% of people would assume a .name address is a scam. Hate to break it to you.
For the first couple of years of .name's existence, it only allowed registration of third-level domains, and the ability to register second-level domains was added later (and only if no third-level domains existed for that second-level domain).
The author is in no way at fault here, and I don't think I would have assumed there was a heightened level of risk if I were him.
ICANN, a 501(c)(3), proposed to remove the price cap on .org, a TLD commonly used for non profits, registration so the registrar PIR, also a 501(c)(3), could then announce it planned to sell .org operations to private equity investment firm Ethos Capital. Thankfully the overwhelming response caused the proposal to be scrapped.
This is a very hn thing (shadow-banned accounts should not be able to comment though and should be treated differently than "dead" because I could see the comment). I was accused by a fellow hn'er just a few days back I was performing ignorance because I didn't know something very US specific legal term and had asked in a sub thread. Another person said I could just google that, or ask an AI.
Coming back to the scam - it's bizarre to think ICANN could begin to do that! TLDs are such a basic aspect of online identity today and just to think that an outrage, i.e an overwhelming response, caused the proposal to be scrapped, is unsettling.
I am not sure but we should rather move to something else or remove this power from such for profit companies or non-profits that often behave worse than for profits, or at the behest of them.
I wonder how long that'll last. If the regulators in Califonrnia keep forcing them to act in the public's interest, won't they just move to a more favorable jurisdiction?
That said, my domain is simply unusual.name, and everybody in my family has email addresses in the form first@unusual.name. So this is a no-op for me, and I gather www.unusual.name will also continue to work, since I own the 2nd level outright.
I feel that I more trust some corpo (Google, etc) that one particular person.
I don't imagine setup where you can effictevely guarantee them full privacy.
Some people in my family use it as their main address, others don't, it's entirely their call.
But yes, ultimately I control the domain and could be nefarious if I wanted to. But there's a certain baseline level of trust as a family, I'm reasonably certain my wife won't poison the milk in the fridge and she's reasonably certain I'm not going to read her emails.
https://support.google.com/accounts/answer/3036546?hl=en
This is only a safe bet until it isn't. If she starts asking about your life insurance and hiding her phone from your view, you will know it isn't a safe bet anymore.
I believe this is a very common setup: the "computer wizard" kid of the family manages the computers for the whole family. Not just emails, they have access to the whole computer (and have to fix when it breaks).
But it hardly needs to be difficult. If you're running dovecot and postfix on a server somewhere then yes, family is screwed. But it's simple to use either some mail forwarding service that you pay for with a credit card, or something like fastmail (etc). Leave 2 pages of instructions for how to log into and renew the domain (print the QR code used for the 2fa enrollment!) and how to log in and pay for whatever the underlying services are. Place in a binder and label "Family.Name Email Management" and put it with your other important documents.
But more seriously, my domain and VPS is on auto-pay, so it doesn't just shut off the day I die. My survivors will have plenty of time to back up their emails and do whatever they want with them afterward.
Plus, the password for my computers and keychain is in a safe-deposit box if they feel like handing it over to a trusted tech-savvy friend of the family to shut down properly.
It made sense to us because our starting point was an email service letting people share lastname.sometld, but we never got close to as many registrants on .name as we had users on the webmail service (we had a couple of million accounts on that when it was sold to one of Marc Cubans companies for a relative pittance in the aftmath of the dot com bubble bursting)
[1] https://blog.asmartbear.com/free-markets-bad/
Gotta wonder what other possible disasters introduced with gTLDs.
> In April 2019, ICANN proposed an end to the price cap of .org domains and effectively removed it in July in spite of having received 3,252 opposing comments and only six in favor. A few months later, the owner of the domain, the Public Interest Registry, proposed to sell the domain to investment firm Ethos Capital. After intense criticism from nonprofit groups and significant figures in Internet history, the proposal was scrapped.
Surprisingly not by Verisign, who gave up .org in 2003.
it'd fit like a PE firm focusing on chemical weapons
Also, all common names with any of those prefixes have been registered a long time ago.
In either case, the security concern should be directly addressed.
That will cost them very little in terms of cash, as I doubt that many people register that many years ahead, plus in terms of accounting, they won't have accrued that revenue anyway so it wouldn't even hurt their books. Not that a couple hundred K would even matter on the financial statements of a giant, money-printing corporation like that.
The reason why they wouldn't go the route of waiting for expiry is that at least a few have nearly a decade left, and clearly they really want these gone, not just reduced in number. By 2036 when they would finally get to that point, I doubt whatever's driving this concern would even matter.
.name was one of the very first expansions of gTLDs back in the very early 2000s. It's a shame that it's being shut down as it was spearheaded by the ICANN itself rather than some registrar / investor like Donuts, Inc.
I suppose this is impractical as someone has to run the registry and there are costs associated with that. But don't the domain fees cover it?
Similarly, I recently got a scam email that linked to de-apple.com (not a domain owned by APPLE) and also used apple.com-18221.com (also not apple.com).
I reported those domains to the registrar, but apparently it is not impersonating enough to take action.
I remember back when we had to write mechanize scripts to drive a browser through the renewal process, because if you had dozens, hundreds, or thousands of domains there was no nonmanual way, especially if you wanted extended verification or something silly like that.
So what I'm saying is, agreed and that has always been true.
Use the system as it was intended, people!
Part of the explosion was that domains were not just in one TLD, they were bobfoo.com bobfoo.bar bobfoo.xyz and in many cases regionalized to bobfoo.co.uk or whatever. It wasn't "domain hoarding", because if you registered bobfoo.info you'd just get UDRP'd by corporate anyway, and nobody really wanted domains of the form somelongnamebobfoo.com
This was also before something like LetsEncrypt where you could automatically generate certs for programmatic usage, so they were all done manually.
You'd be surprised
and renewing annually is a great way to accidentally forget some of these and let someone use them to hack your customers
Sadly neither our world not its legal system is built on common sense.
The main problem with the Internet today is that we didn't destroy ICANN when they started this TLD sell off crap. A replacement institution may have at least told Verisign a TLD they can't run transfer to someone who can meet its promises can only be destroyed.
It's clear to me ICANN can say no agreement change or total destruction. You are correct that they could do something else and show every indication that they would never do the right thing and that is why they should be destroyed.
https://en.wikipedia.org/wiki/.me
That's a silly idea. While there are laws that ensure to a decent extent that there is a single company called "Google", so that it's relatively unambiguous who `google.com` should refer to, there is no uniqueness whatsoever to personal name. There are likely hundreds of thousands of people called "John Smith", so the FQDN `john.smith.name.` would not really tell you anything.
This is without even going into the fact that "first-name.last-name" is culturally specific (though, to be fair, a large proportion of cultures in the world use this format).
There aren't laws to ensure that. Within specific jurisdictions, sure, but not globally.
A lot of companies also don't trade under their full name. Apple, famously, wasn't founded as Apple but as Apple Computer, and was only able to rename after achieving a deal with Apple Records.
The lack of more namespaces also led to things like nissan.com being owned by Uzi Nissan (and now his family, I assume) rather than the car company.
While you're right that there are many duplicates, one extra TLD still broadened the namespace a lot, and the most important part of the idea was that by giving people less of a reason to register <lastname>.com or <lastname>.cctld, we'd give far more people the option to get <firstname>@<lastname>.name as an email address.
(The cultural aspect is irrelevant - it was not enforcing a specific order. If people wanted to register lastname.firstname.com, nothing would stop that)
By the time we applied for .name we actually had experience running a webmail service where people shared ~60,000 domain names, and had ~2 million accounts on that, and we'd done extensive modelling before acquiring those, and as a result at the time we probably had better data than anyone on the distribution of names worldwide.
What we seriously overestimated (every applicant overestimated how popular the new TLDs would be, but the generic ones, generally did better) was how many people were in the intersection of people who'd figure out how to buy a domain name and people who wanted firstname@lastname.name as an e-mail address.
Many trademarks are indeed more or less global.
> A lot of companies also don't trade under their full name. Apple, famously, wasn't founded as Apple but as Apple Computer, and was only able to rename after achieving a deal with Apple Records.
That's irrelevant - Apple Computers owns the Apple trademark (for certain industries).
> The lack of more namespaces also led to things like nissan.com being owned by Uzi Nissan (and now his family, I assume) rather than the car company.
It's not perfect and not guaranteed to be unique, yes. But people's names have many orders of magnitude more collisions.
> <firstname>@<lastname>.name as an email address.
No, you'd at best get `??@firstname.lastname.name` as your email address. Which, again, is irrelevant, as it's impossible to say which of the many thousands of Firstname Lastname people this might belong to.
> (The cultural aspect is irrelevant - it was not enforcing a specific order. If people wanted to register lastname.firstname.com, nothing would stop that)
I wasn't referring to a specific order, but to the cultural idea that people have 1 firstname and 1 lastname. In Spain, for example, people typically have 1 first name and 2 last names - but you couldn't get `a.b.c.name` as an address. Having a first name, a middle name, and a last name is also very common.
There are also cultures where people simply have one name, not first + last. For example, a person's full legal name in Tibet might just be "Woeser".
And the vast majority are not, so this has no relevance.
> That's irrelevant - Apple Computers owns the Apple trademark (for certain industries).
And yet you yourself concede in this very same statement that it is not absolute. Even with one of the most famous examples from one of the largest companies in the world.
> It's not perfect and not guaranteed to be unique, yes. But people's names have many orders of magnitude more collisions.
For most people our data was very clear that for most names the number of collisions are in fact relatively low, further significantly mitigated by the combination of nicknames and ability to use middle names. Very few last names are highly frequent, and very few of those with common last names have an intersection of a very common first name and a very common last name. The vast majority of people fall in a long tail of last names held by a few thousand people, and first names held by a few thousand people.
For the webmail service that preceded .name, the vast majority of the two million accounts registered were for names for people who would have no way of getting their firstnam@lastname.<tld> addresses without it because of colissions. That some of those would not be able to get one of our addresses either because their specific combination was particularly common does not alter the objective fact that we massively broadened the availability.
> No, you'd at best get `??@firstname.lastname.name` as your email address. Which, again, is irrelevant, as it's impossible to say which of the many thousands of Firstname Lastname people this might belong to.
No, that was categorically not how it worked. I personally designed the system to handle this. We provided firstname@lastname.name e-mail forwarding to an address of the registrants choice, and provided a reference platform for registrars to support that, that I also designed, and managed the implementation of.
Given that you haven't even bothered to understand what it provided before criticising it, it's hard to assign much value to your arguments.
> I wasn't referring to a specific order, but to the cultural idea that people have 1 firstname and 1 lastname. In Spain, for example, people typically have 1 first name and 2 last names - but you couldn't get `a.b.c.name` as an address. Having a first name, a middle name, and a last name is also very common.
Spanish people are perfectly capable of using their firstname and their fathers first lastname when limited to one last name. They are also capable of using 2, 3, or 4 last names depending on context and preference. For any that wanted to use more, they had more flexibility, because they could similarly register b.c.name, and use a.b.c.name, or register any combination preferred for the last two labels and set up the rest themselves.
Same if you insisted on using your middle name. We only provided the increased ability to share among those with overlapping two last labels, but that did not change the ability to use regular DNS features.
> There are also cultures where people simply have one name, not first + last. For example, a person's full legal name in Tibet might just be "Woeser".
While you're right that exists, firstly it's a miniscule proportion of people. We collected stats on that two. If you fell in that group, your options were either to use another TLD, or use another indicator. In Europe as well, in cultures that used to use only one legal name, people would still regularly use distinguishing attributes, such as place names or occupations. In fact, both of those are the source of most legal lastnames in Europe today. E.g. my last name is the name of the farm my great great grandfather came from, and names like Baker and Smith are occupations.
There is no need to be able to be a perfect match to a given format for everyone to still meaningfully and significantly enlargen the available ...
Can someone explain why a product "registered and paid for until 2040" can be unilaterally voided like this without compensation?
> As your .name can be registered for up to 10 years and ownership is renewable, your .name really can be yours for life.
It seemed like there was an offer of renewable registration at least for a life term.
[1] https://web.archive.org/web/20020609132126/http://nic.name/c...
[0] https://publicsuffix.org/
The problem DMARC solves is different than the problem the PSL solves, though. DMARC prevents a 3LD from pretending to be a different 3LD on the same 2LD. But the PSL handles things like what it means to make a "cross-site request" or how to handle cookies.
I mean now I'm thinking if DMARC _could_ solve that... but I don't think it could, unless I'm missing some extension or rare use case.
Specifically, if I register subdomain attack.co.uk and set up a malicious WiFi router, I trick some *.co.uk cookies to get set on co.uk and then steal them from attack.co.uk by tampering with the (proposed) SVCB record.
I think the signal needs to be secure, which means DNSSEC. Adding a hard requirement for DNSSEC validation in all web browsers is a huge change from where we are now.
And essentially boils it down to ‘either the client implements wire-security to a known dns server using DoH or DoT, implements dnssec to verify the untrusted response as legitimate, or the client risks being mitm’d to attacker addresses’. They ultimately sidestepped the problem by structuring it to be hints rather than guarantees and thus allowing DNSSEC to be optional, and so as of today, it’s definitely not sufficient to implement this.
I think that adding a CORS rejection to DNS — declaring subdomains independent of a TLD, that is — does not require DNSSEC, so long as clients adhere to the steps to prohibit attacker interference described. But it still asks a great deal of DNS that I’m unsure is possible today, not just in DNSSEC but in ripple-subward records that somehow tie into client responses.
More likely, I assume browsers will simply permanently end all service to the concept of subdomains at all; no cookie sharing across domains at all, no inherent cross-origin just because tld and www.tld share a few characters, etc. rather than either depending on the PSL or having to implement strange and complex DNS anything. Admins will throw their hands up about it, but the net is no longer a place where control of a TLD defines the trust of its subordinates, so it’s certainly time to rip that bandaid off if they haven’t yet.
That doesn't sound simple at all.
In this age, allowing domain names to be owned by other entities is almost like allowing a company business registration number or one's national id card number to be transferred to others.
I think name squatting is a problem, but it is not like that current system has solved it.
Never dreamed that such a supposedly durable thing would just disappear. How hard is it really to preserve a global resource like this that exists only in software?
So, where is our fully decentralized TLD alternative, free of ICANN or any central authority to handle how we grant names by conventions, without any money scheme in the game that attracts malevolent actors moving only through greed strings?
Also, this time let’s make it like usenet, so "person:named:Neil Fraser" or even "::Neil Fraser" (harder to type but less culturally entangled into English).
We can all edit our hosts file.
The problem with a lack of a central authority is domain names are most useful if they follow the highlander principle. There can only be one neil.fraser.name ... otherwise it's not usable for routing traffic if every webserver a Neil Fraser runs uses that address. (Yes, there are useful ways for one name to resolve to different webservers, but almost always those are webservers under at least loose control of a single entity or very exceptional cases)