Live data from Hacker News

.name Termination

neil.fraser.name

511–520 of 562 posts

Re: .name Termination

#511

Earlier quoted context omitted.

.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.

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

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 just A or AAAA records. DNS does a lot more than pointing to websites

Re: .name Termination

#512

Earlier quoted context omitted.

Luckily the average person has no idea what a TLD or a subdomain are

They do if they are employed in a non-tiny company where they work at least partially on a computer and paid attention during security training.

Even if I agree with you that the "average person" meets the 3 specific criteria you list (which I don't), I don't believe the claim that the typical security training includes specific instruction in how TLDs and domain registration work, at least not in enough detail for a person to be able to follow the discussion we're having here.

Re: .name Termination

#513

One of the reasons I stick with Big Email for my primary email is cases similar to this. If I host email and lose the domain one day, I’ve lost two factor on a thousand different services (the single factor on some). Big Email’s policy is to not reissue my address, should I lose it or die. The .name scenario is even worse. One domain gives you access to tens of thousands of users email. It seems like a privacy nightm…

I don’t see the problem if you stick with .com or the ccTLD for the country you live in. To me, the risk these registries screwing me over is smaller than Big Email deciding I broke their ToS and shutting down my account. I wouldn’t use these novel TLDs either.

.com is probably okay, but like .name, it’s also managed by Verisign. .org is run by a non-profit, PIR, so I’d argue it’s a safer choice (especially since they already got the slap on a wrist for trying to sell it off [1] and likely won’t attempt it again for the time being).

Both of these are in the US jurisdiction. If you’re not prepared to sue in the US if somebody screw you over, the ccTLD route is probably better, and the country you live in is usually a good choice indeed (unless you live in, say, Russia, in which case the government might be the ones doing the screwing-over).

[1]: https://icannwiki.org/.org#Proposed_Sale_to_Ethos_Capital

Re: .name Termination

#514

Earlier quoted context omitted.

(That's DMARC, to save others the trouble.) 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 o…

Yes, DMARC isn't solving the same problem — but DMARC is showing how the category of PSL problems can be solved with DNS. With HTTP/3 now fully expecting browsers to be able to benefit from transparent-upgrade record responses, i.e. `www IN HTTPS 1 . alpn="h3,h2"`, then it is possible for the style of solution shown by DMARC to be applied to other problems that PSL solves today. CAA isn't a good fit as-is either, bec…

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.

Re: .name Termination

#515
post #331

Earlier quoted context omitted.

> 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?

I guess I’m confused why the author isn’t pursuing this legally.

Re: .name Termination

#519

Earlier quoted context omitted.

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.

https://dnssecmenot.fly.dev/

The PKI run by state-level actors isn't going to happen.

Re: .name Termination

#520

Earlier quoted context omitted.

Yes, DMARC isn't solving the same problem — but DMARC is showing how the category of PSL problems can be solved with DNS. With HTTP/3 now fully expecting browsers to be able to benefit from transparent-upgrade record responses, i.e. `www IN HTTPS 1 . alpn="h3,h2"`, then it is possible for the style of solution shown by DMARC to be applied to other problems that PSL solves today. CAA isn't a good fit as-is either, bec…

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

The SVCB HTTPS rfc considers downgrade attacks here: https://www.rfc-editor.org/info/rfc9460/#name-handling-resol...

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.

Post reply on HN