Live data from Hacker News

.name Termination

neil.fraser.name

331–340 of 559 posts

Re: .name Termination

#331

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…

> the right thing they should do Can someone explain why a product "registered and paid for until 2040" can be unilaterally voided like this without compensation?

Because they haven’t been sued enough yet?

Re: .name Termination

#332
post #315
post #224

Earlier quoted context omitted.

From what it sounds like, unlike domains under other TLDs, when you purchase a domain under .name you always purchase specifically the three-segment domain. i.e. I own john.doe.name, you own george.joe.name. Once this change goes through, only "doe.name" can be owned, so who gets it?

I own a .name domain that is an initialism for my wife and I, and Namecheap never gave me any problems adding a record for vpn.mwai.name, for example. In fact I never even realized you could register a 3LD, much less that this was the intended(?) behavior.

The idea is:

* .name is open for everybody

* a company called "Global Name Registry" scooped up a BUNCH of common last names, including fraser.name

* Global Name Registry then sold access to neil.fraser.name for far cheaper than the fraser.name domain would cost on its own; someone else could also buy john.fraser.name or jane.fraser.name, so the single fraser.name domain that they owned could have dozens of customers associated to it. They worked with ICANN to allow each domain to have its own registered owner.

* The article in the OP bought neil.fraser.name and has used it for years

* Verisign bought Global Name Registry; later they realized, hey, we're sorta not making a lot of money on this idea, and we're spending a lot of time/resources maintaining these domains "for cheap" and chasing renewals, and not scooping up more customers. Let's just stop it and stop paying for fraser.name and the potentially hundreds of other domains we own.

* Neil Fraser, not the only Fraser in the world, is upset because he might lose the domain he's had forever

So one CAN buy the mwai.name domain, as you have, and continue using vpn.mwai.name just fine. It's just you can't "officially" start selling out these subdomains as a separate registrar entry.

Re: .name Termination

#333
post #327

Earlier quoted context omitted.

You say "registered" to you as though this was via an official registrar but surely you mean that someone rented ca.us and decided on their own to lease out subdomains to people? (Aside, I always see "owned" and "bought" but you can only ever "lease" under the ICANN system as the present situation so clearly demonstrates.)

Historically, xx.us (where xx is a two letter state code) domains have been owned* by the named US state, which then would issue subdomains on top. I believe this was originally planned and set up by ICANN themselves. *: I realize that “owned” is a loaded word here, but (1) I’m referring to a registrar/issuer, which makes it yet more complicated as to how much “ownership” (de facto or otherwise) a given entity may ha…

My aside wasn't intended to be pedantic, rather observing the apparent inconsistency in how it appears people think about these matters versus what the present situation illustrates the reality to be.

> but (1) I’m referring to a registrar/issuer, which makes it yet more complicated

We're also talking about a ccTLD which makes it even more complicated. AFAIK those fall entirely under the jurisdiction of the respective UN recognized government although I don't know how strong that agreement is in practice (treaty versus something else).

So at that point I guess we've roughly got ICANN -> US federal government -> CA state government -> registrar -> private party -> sublet.

Re: .name Termination

#334

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…

[deleted]

Re: .name Termination

#335

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…

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.

[0] https://publicsuffix.org/

Re: .name Termination

#336
post #116

Earlier quoted context omitted.

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://githu…

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.

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.

Re: .name Termination

#337
post #335

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…

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. [0] https://publicsuffix.org/

Yeah, that’s why RFC 9989 replaced use of PSL with a dns signifier.

Re: .name Termination

#338
post #205
post #116

Earlier quoted context omitted.

I think this says more about how the cookies security model is stupid. They should always have been scoped to the single, exact name they were set from and nothing else. Websites would have had to be designed a bit more thoughtfully.

It seems like it would be easily resolvable with TXT records these days. Anyone could try, say, on www.google.com to set a cookie for all of google.com, and the browser can fetch TXT records on google.com to see what, if any subdomains, it wants to allow this privilege for. Google could return a list or a wildcard; co.uk wouldn't allow any. In a world without advertising, there's no reason why google.com couldn't als…

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.

Re: .name Termination

#339
post #205

Earlier quoted context omitted.

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 als…

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…

[dead]

Re: .name Termination

#340
post #220

Earlier quoted context omitted.

You are technically correct, but Verisign billed buying an x subdomain as if the y domain was part of a stable infrastructure. Which it kind of was until they decided to pull the rug.

Presumably Verisign is the owner of the y domain and wouldn't dare sell it off to the highest bidder...

[dead]
Post reply on HN