Comment by krystofbe

As the CPU/RAM resources to run an authoritative-only slave nameserver for a few domains are extremely minimal (mine run at a unix load of 0.01), it's a very wise idea to put your ns3 or something at a totally different service provider on another continent. It costs less than a cup of coffee per month.

On Google cloud it's always four nameservers like

    ns-cloud-c1.googledomains.com
    ns-cloud-c2.googledomains.com
    ns-cloud-c3.googledomains.com
    ns-cloud-c4.googledomains.com

Would not make any sense to do four of them if it's a single AZ. Also, they are geo-aware and routed to your nearest region.

DNS is barely centralized. Is there an alternative global name lookup system that is less centralized without even worse downsides?

Normally it should not have been, with cache and all, but that was the past...

Think about what would happen the day that letsencrypt is borken for whatever reason technical or like having a retarded US leader and being located in the wrong country. Taken into account the push of letsencrypt with major web browsers to restrict certificate validities for short periods like only a few days...

Not really? .com and .net are still up

If Let's Encrypt goes down, half of the Internet will become inaccessible in a week.

Us non pod-people caught his drift.

I think I see the point you're making here and I agree.

There is designing something to be fail-closed because it needs to be secure in a physical sense (actually secure, physically protected), and then there's designing something fail-closed because it needs to be secure from an intellectual sense (gatekept, intellectually protected). While most of the internet is "open source" by nature, the complexity has been increased to the point where significant financial and technical investment must be made to even just participate. We've let the gatekeepers raise the gates so high that nobody can reach them. AI will let the gatekeepers keep raising the gates, but then even they won't be able to reach the top. Then what?

I think the point you're trying to make, put another way is in the context of "availability" and "accessibility" we've compromised a lot of both availability and accessibility in the name of security since the dawn of the internet. How much of that security actually benefits the internet, and how much of that security hinders it? How much of it exists as a gatekeeping measure by those who can afford to write the rules?

Backwards compatibility is unfortunately not something security folk care about.

This is why I still run my blog on HTTP/1.1 only.

You're not wrong but objecting to fail-closed in a security sensitive context is entirely missing the point.

Prove it? I’m sure many lifespans were lost to stress

Would be interesting to know how something could get missed. You'd think the system was set up so that new keys could not be published without being verified working in a staging system.

This is actually startlingly true.

Every FAANG company has their own fiber backbone. Why invest the internet that everyone uses when you can invest in your own private internet and then sell that instead?

That was my experience too until I decided that just running email systems for 30 odd years when HN says that is unnatural piqued my weird or something!

I ran up three new VMs on three different sites. I linked all three systems via a private Wireguard mesh. MariaDB on each VM bound to the wg IP and stock replication from the "primary". PowerDNS runs across that lot. One of the VMs is not available from the internet and has no identity within the DNS. The idea is that if the Eye of Sauron bears down on me, I can bring another DNS server online quite quickly and fiddle the records to bring it online. It also serves as a third authority for replication.

I also deployed https://github.com/PowerDNS-Admin/PowerDNS-Admin which is getting on a bit and will be replaced eventually but works beautifully.

Now I have DNS with DNSSEC and dynamic DNS and all the rest. This is how you start signing a zone and PowerDNS will look after everything else:

  # pdnsutil secure-zone example.co.uk
  # pdnsutil zone set-nsec3 example.co.uk
  # pdnsutil zone rectify example.co.uk

Grab a test zone and work it all out first, it will cost you not a lot and then go for "production".

My home systems are DNSSEC signed.

How simple sysadmin was in 1994 with no cryptography on any protocol. Everything could be easily MITM'd. Your credit card number would get jacked left and right in the 90s.

I know quite a bit about PKI and X.509, and I can tell you that much: the overlap with how DNSSEC works is limited.

Is that actually true, though? Even though it's not really my job, I find myself debugging certificates and keys at least once a month, and that's after automating as much as possible with certbot and cloud certificates. PKI always seems to demand attention.

It's not made easier by the fact that a lot of cryptography is either very old and arcane or it's one hell of a mess of code that doesn't make sense without reading standards.

I had the misfortune of having to dig deep into constructing ASN.1 payloads by hand [1] because that's the only thing Java speaks, and oh holy hell is this A MESS because OF COURSE there's two ways to encode a bunch of bytes (BIT STRING vs OCTET STRING) and encoding ed25519 keys uses BOTH [2].

And ed25519 is a mess in itself. The more-or-less standard implementation by orlp [3] is almost completely lacking any comments explaining what is going on where and reading the relevant RFCs alone doesn't help, it's probably only understandable by reading a 500 pages math paper.

It's almost as if cryptographers have zero interest in interested random people to join the field.

End of rant.

[1] https://github.com/msmuenchen/meshcore-packets-java/blob/mai...

[2] https://datatracker.ietf.org/doc/html/rfc8410#appendix-A

[3] https://github.com/orlp/ed25519/tree/master