Hacker News Reader

Comment by kwanbix | Hacker News Reader

Why would they even want to close it? It is probably close to 0 cost tot hem. Or am I wrong?

It works differently than pretty much every other TLD, which means it's different code paths to support.

Many registrars don't support the unique 3rd level domain setup for .name, so it can be hard to find registrars that properly support it.

There's also an associate email redirect service, which is unique to .name and probably costs money to run and maintain.

It's probably easier to support, and more valuable to sell second level .name domains.

Pretty terrible that they were considering just dropping tens of thousands of customer registrations however.

> It works differently than pretty much every other TLD, which means it's different code paths to support.

but I was told that AI has made code obsolete and free

How is it different than others like .co.jp or .ne.jp?

Those ones have a fixed list of second level domains.

.name was something where you could register a two part domain, picking both the third and second level, to represent your first and last name.

So you could own my_name.lastname.name, and someone else could own their_name.lastname.name ?

A bit weird, as to me the first part reads like a 'subdomain'.

Yes, that's how it works. lastname.name is the TLD.

Firefox highlights neil as the subdomain for fraser.name for me, but there's no subdomain involved in the URL.

Messes like this is why we have to maintain the Public Suffix List,[1] but even then, .name caused problems.[2]

"Do we need to do this? Softer walls exist to beat our heads against."

[1] https://publicsuffix.org/

[2] https://github.com/publicsuffix/list/issues/2306

It has weird interactions with some modern browser features. For example domain isolation doesn't apply between subdomains of the same TLD, so john.smith.name and drew.smith.name don't get isolation in naive implementations.

wouldn't that be a problem with a lot of other domains? like locality domains

It definitely is. <ingress>.k8s.<mydns>.com regularly confuses what password I want to use if I have different authentication per ingress. More commonly if I run something else at <name>.<mydns>.com firefox and chrome are both happy to offer up my password for <other service>.<mydns>.com.

Closed. Wont fix.

yes, but other locality domains are fairly static and well-known

.co.uk wouldn't have the same problem because everyone knows that combo is a TLD in and of itself. with a seemingly infinite possible combinations of blah.name that could be a TLD itself, or, might just be a subdomain of .name, it gets really weird

> with a seemingly infinite possible combinations

Verisign claimed approximately 22,000 third level domains [1] in July 2026. I don't see an estimate of the number of shared second level domains, but it's finite. The current public suffix list includes 10414 names [2]; so at maximum, the list would approximately triple in size --- not ideal, but feasible.

Edit: another post [3] claims approximately 2000 second levels names with multiple registrations; that's only a 20% increase in size for the existing list, which is again a lot, but feasible. There's some more specific data in an issue for the suffix list [4], that shows there were nine second level domains with multiple registered names underneath them, one of which might all be the same registrant (domain.name)...

Nine would be totally doable, if the request came from Verisign...

[1] https://itp.cdn.icann.org/en/files/consensus-policies/fessen...

[2] including some with wildcards, re: your other post

[3] https://news.ycombinator.com/item?id=50446780

[4] https://github.com/publicsuffix/list/issues/2306

22,000 now, but there was no limit and more importantly no rhyme or reason or other way to tell what was a third level registration and what was a subdomain on a normal second level registration

Verisign could have published a list of every third level registration, it wasn't an impossible problem to solve, but it is different than static regional TLDs like .co.uk or .<state>.us

We solve that problem with the public suffix list. The problem is there's a lot of .name domains, each of which would need to be added to the list.

The real problem is that we'd have to add a wildcard to the public suffix list. That's it.

The public suffix list is the big list of all the URL suffixes that should not imply shared ownership of all their subdomains. For example the line

com

says "XYZ.com" and "ABC.com" should not be assumed to be controlled by the same entity.

Problem is, all 1st level domains registered to the .name TLD should be added to the list, and that's a lot of domains. The correct answer, IMO, would be to add a wildcard

*.name

but that would involve updating all the code that relies on the public suffix list to support said wildcard.

*.name isn't a good solution either, because the vast majority of registrations are at the second level.

If you want to do it properly, you really do need to include all of the second level domains that have more than one third level registrant. And update that periodically as domains expire... there might be three registrants under .example.name today, but if they all (or all but one) stop paying, example.name is no longer a public suffix and it should be removed.

Having "no cookies shared between subdomains" as a restriction on the entire TLD isn't completely beyond the pale. There are other TLDs that have restrictions, like HTTPS being required for .dev

Having it imposed on existing registrants after the fact really is beyond the pale, IMHO.

It'd be one thing if it was there since the beginning, like https for .dev, but it would probably break existing sites if you add it after the fact.

With only 22000 registrants, the number of sites broken might be just a handful.

It's not 22000 registrants for .name, it's 22000 registrants of third level domains. There's lots more second level registrations in .name; it is massively more popular to register a second level domain, but it wasn't always an option.

How can they enforce that? If my DNS config points www.mydomain.dev to my vps, what can prevent me from answering on port 80?

No cookie sharing between subdomains is enforced client-side, not server side.

The "real" problem is the public suffix list. All domains should be considered public, that is, a sub domain gains no trust from it's parent domain.

There is a good argument that the public suffix list should be distributed via dns, and it is easy to propose a scheme for it. Two I know of are. A specific public suffix record marking a domain public or private. The presence of a soa record which already transfers the authority of a domain, should be used to determine if that sub domain is public or private.

But private unless in some third party list is the worst way to handle it.

The public suffix list is a stupid hack that should be replaced by formal protocols allowing boundaries to be defined by either DNS entries, or a file on the web server.

I personally think the public suffix list should be replaced by zero sharing even amongst subdomains, and if you want to talk between x.y.example.org and example.org you can use CORS just like any other cross-domain request.

I think the real challenge is the millions of sites which rely on the existing behaviour.

Do it for every new TLD. Do it for every new domain in an existing TLD. Add an opt-in for security, then start pushing for the security measure, then get browsers to start carrot-and-stick enforcing it...

It's possible to make things better.

Ah yes the millions they broke with CORS

My thoughts also, but maybe they can make more from a few sites like baby.name than they can from personal domains.

There would be great money to be made if you could auction off domain.name, instead of being stuck just getting $20 per year because some geezer registered his.domain.name.

Reply on news.ycombinator.com