Hacker News

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

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?

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

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

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

Sounds like poor risk pooling. If that room crashed, we'd have nobody to fix this.

Sounds like Australian police. I remember 15 or so years ago being in a big team assisting the Australian police with something on a remote farm. There were 20 people that needed to be taken back to base and one 10 seater car. Someone asked the police if everyone could get in the car and policeman shrugged and said you can try. So the policeman drove a four wheel drive across farmland with 16 people stuffed into the back.

That only worked because the attacker didn't understand dnssec. If they had unsigned the domain first and then hijacked it they would have succeeded.

I haven't been able to find any cases of genuine dns hijack attacks in the last few years. Would love to know if anyone else can?

Only about 40% of the crypto companies seem to use dnssec. Seems like a target rich environment.

There's no commercial compliance regime that requires DNSSEC (FedRAMP might be the only exception --- I'm uncertain about the current state of FedRAMP DNSSEC rules --- but that makes sense given that DNSSEC is a giant key escrow scheme.)

Probably the most common reason to use TLS is to check a box on a list of compliance rules. Is that bad?

It's a pretty hard argument to work around: WebPKI certificates should go in the DNS, and also the largest DNS providers might at any moment decide not to validate DNSSEC anymore to get through an outage.

Sorry! status message was not clear. DNSSEC validation is temporarily disabled only for .de domains.

[flagged]

Which is fine. Not because KSK rollover is supposedly complicated, but if you can't manage to keep your private keys and PKI safe in the first place then key rotation is just a security circus trick. But if you do know how to keep them safe, then...

Pretty sure that rant doesn't exist.

In my experience, that error is a lie and is what you get if they've IP blocked you. (Easy to hit on a VPN, in particular)

I get "content not viewable in your region", from the UK. Not an ideal image sharing website nowadays.

A protection against bad networks, including VPN.

It's been like that for over two years now.

> but how would one verify the signature if the DNSKEY expired and you cannot fetch a fresh one because the organisation providing those keys is down?

In theory, this shouldn't happen, because if you use the same TTLs for your DNSSEC records and your "regular" records, then if the regular records are present in the cache, the DNSSEC records will be too.

> So if they are down for more than an hour and all RRSIG caches expire, DNS zones which have a higher TTL than 1h but use DNSSEC would also be down?

Yes, but I'd argue that the DNSSEC records should have the same TTLs for exactly this reason. That's how my domain is set up at least:

  $ dig +nocmd +nocomments +nostats +dnssec @any.ca-servers.ca. maxchernoff.ca. DS
  ;maxchernoff.ca.                        IN      DS
  maxchernoff.ca.         86400   IN      DS      62673 15 2 487B95FEFF04265826F037C9DB2E1F14FF9ADBF2C7BE246A2B9F9BFD 481BE928
  maxchernoff.ca.         86400   IN      RRSIG   DS 13 2 86400 20260512131336 20260505104433 46762 ca. ppc9LrWniPWdAI2Xq1g3FrYJGQVYayA5TtgFRkJfqOqNfe6zu/n0gwti IO3c9pOoUpIum5gPB6GLOGbGU+sfhg==
  
  $ dig +nocmd +nocomments +nostats +dnssec @ns.maxchernoff.ca. maxchernoff.ca. DNSKEY
  ;maxchernoff.ca.                        IN      DNSKEY
  maxchernoff.ca.         86400   IN      DNSKEY  257 3 15 DYs9mPDMRx/hQ9R9iGLi1Ysx1eFdhlXeCujY6PqJWeU=
  maxchernoff.ca.         86400   IN      RRSIG   DNSKEY 15 2 86400 20260518072823 20260504055823 62673 maxchernoff.ca. RgPyEvB/kjXIvoidRNF/hfm7utzDs0kxXn4qJL17TUAVYOdbLl0Vd8zt E52bGBBFv2TNEnf9O9LkiT2GBH0jAA==
  
  $ dig +nocmd +nocomments +nostats +dnssec @ns.maxchernoff.ca. maxchernoff.ca. A
  ;maxchernoff.ca.                        IN      A
  maxchernoff.ca.         86400   IN      A       152.53.36.213
  maxchernoff.ca.         86400   IN      RRSIG   A 15 2 86400 20260518072823 20260504055823 62673 maxchernoff.ca. bRfTVHnMjCFRaIh5uc0aT1vD4yh1UZrqOZDRunLbxFI1eth6nNlTiOOC xti7axVoXwB6VAoHOAnW0nL0eeJNDQ==

Resolvers are free to cache each TLD's keys. There's a finite, well-known list of TLDs and their keys - you can download all the root zone data from IANA: https://www.iana.org/domains/root/files (it's a few megabytes in uncompressed text form)

The world might be a little bit better with more decentralization of the root zone.

And then fax the form to the correct authority, so that the request is Official(tm).

I know that people are joking, but of course we also have (extra paid) on call shifts.

And send it by post for approval, which will take 5-30 business days.

Luckily it's not Sunday. Everyone would be out in the country hiking.

:D... before tax!

I just checked and the can of Paulaner in the fridge is not affected by the outage so far, thus my trust into German economy remains unshaken.

> Yeah it's only the third largest economy in the world

You can both be the 3rd biggest economy in the world and still only be 1/10th of US+China GDPs combined.

And only three companies in the Top 100 for Germany:

https://companiesmarketcap.com/

Germany is the kingdom of the "mittelstand": many, many, many SMEs.

Both GP and you are right: it's the 3rd largest economy in the world and yet it's simply not that big.

https://en.wikipedia.org/wiki/Mittelstand

In other words: I expect this German DNS SNAFU to have 0.000000001% impact on the world's GDP this year.

You definitely forgot Merkel and Habeck.

I can live with that

Or only accessible through a german dns server

That's cool, ty for that. The only one I put credentials into is Amazon it is unsigned. [1] There probably needs to be a DNSSECv2 .vbis that reduces risk somehow to get more adoption.

[1] - https://dnssec-analyzer.verisignlabs.com/amazon.com

Parmigianino-Reggiano is aged milk, so I'm not sure what people have against aged milk. Aged milk can be great

My poor fellow. You wrote about how something is a bad tool for a long list of serious reasons. Then it failed spectacularly because everybody decided to depend on it anyway - exactly what you were cautioning against. But somehow you have to respond to people who think you are the one who got it wrong! As a third party the whole affair gave me a good chuckle at least ;)

Almost certainly /s. "Danke Merkel" ("Thanks Merkel") was once a sincere criticism from conservatives regarding her policies (esp. during 2015 refugee crisis), but it quickly evolved into a sarcastic, deadpan joke used to blame her for literally anything that goes wrong in daily Germany - even years after she left. Interesting phenomenon...

A complex thing where making a mistake makes your domains drop off the internet seems like a pretty big "only problem".

can confirm, at least another 54k seconds from where i sit

Unfortunately, even domains that did not have DNSSEC enabled earlier today are affected.

We observed issues on a non-DNSSEC .de domain at 19:45Z and confirmed around 20:12Z it wasn't just us, but also more high profile domain names.

Any .de domain is affected, regardless of the domain's dnssec deployment status, as long as you use a resolver which validates dnssec.

That's weird cause 8.8.8.8/1.1.1.1 will already answer with SERVFAIL right now, unless the domain is still in the cache.

That squint loses too much nuance. I don't think of a site data leak as an availiability problem.

Bad UX and bugs are in general not always an availiability problem.

If it hard to get what you want due to bad design but the site is up, the site is still up.

You mean the big undersea cable between the Netherlands and Germany? ;-)

$ nslookup bmw.de ~ Server: 8.8.8.8 Address: 8.8.8.8#53

Non-authoritative answer: Name: bmw.de Address: 160.46.226.165

$ nslookup www.bmw.de ~ ;; Got SERVFAIL reply from 8.8.8.8, trying next server Server: 8.8.4.4 Address: 8.8.4.4#53

* server can't find www.bmw.de: SERVFAIL