Comment by 1vuio0pswjnm7 | Hacker News Reader

Comment by 1vuio0pswjnm7 | Hacker News Reader

You can also serve a root.zone on that DNS server and it does not have to a carbon copy of ICANN's root.zone. I have been doing this for over 15 years. I've tried many DNS server software projects over that time and I always come back to djbdns

Multiple comments in this thread refer to TLS certificates

Why is payment to and/or permission from a third party "necessary" to encrypt data in transit over the a computer network, whether it's a LAN or an internet. What does this phoney "requirement" achieve

For example, why is it "necessary" to purchase a domain name registration from an "ICANN-approved" registrar in order to use a TLS certificate

Is obtaining a domain name registration from an "ICANN-approved" registrar proof of identity for purposes of "authentication". What purpose does _purchasing_ a registration serve. For example, similar to "free" Let's Encrypt certificates, domain names could also be "free"

Whatever "authentication" ICANN and its "approved" registries and registrars are doing, e.g., none, is it possible someone else could do it better using a different approach

This comment is not asking for answers to these questions; the question are rhetorical. Of course the questions may trigger defensive replies; everyone is entitled to an opinion and opinions may differ

Yes, you can have a different root zone which includes some or all of ICANN's root servers, or none of them. However if the root zone doesn't match ICANN's then DNSSEC will fail ("fruit of the poisoned tree"). But you could sign your alternate, custom root, and issue DNSSEC keys all the way down.

You don't need ICANN for TLS or encryption. You can create your own CA and sign your own certs. In fact, this is typically how it's done to authenticate for example clients of a web server using certs (you install the cert in the browser).

You can use your CA to sign a cert for your ICANN-registered domain and install it in the web server; there are no internet police who are gonna stop you. Web browsers will complain about this "self-signed cert", unless you install your CA's public key in your browser. (Security-wise, you probably shouldn't go around installing random people's CA certs in your browser. You need to trust them not to issue certs for e.g. google.com. On the other hand you need to trust China and Morocco not to do that already, so maybe you're willing to accept that risk.)

> Is obtaining a domain name registration from an "ICANN-approved" registrar proof of identity for purposes of "authentication".

People make the mistake of conflating an FQDN or address with identity all the time. People point at resources in domains which don't exist (this includes DNS resources), and people register those abandoned domains and then click "forgot password" and take over whatever account was tied to that email address in that domain.

I don't know that ICANN requires any proof. There are CAs which have enhanced identity verification, this applies to the certs they issue for both servers and clients / people.

> What purpose does _purchasing_ a registration serve.

Makes you a member of ICANN's club. There are pseudo-TLDs which are registered in ICANN's tree where you can register a (sub)domain, without interacting with ICANN at all.

Rhetorically speaking, of course.

Reply on news.ycombinator.com