Live data from Hacker News

DNSSEC disruption affecting .de domains – Resolved

status.denic.de

141–150 of 440 posts

Re: DNSSEC disruption affecting .de domains – Resolved

#142

I've considered hard-coding some addresses into firmware as a fallback for a DNS outtage (which is more likely than not just misconfigured local DNS.) Events like this help justify this approach to the unconcerned.

The irony is that DNS is a global and distributed system meant to be resilient. It’s the DNSSEC layer on top in this case causing problems.

denic is the single source of truth for zones under .de.

The only problem with DNSSEC here is that it's complex.

Re: DNSSEC disruption affecting .de domains – Resolved

#144

Earlier quoted context omitted.

I love how I work with IT for 20 years and don't understand a single acronym here other than DNSSEC

To be fair, advanced real world knowledge of public/private key PKIs (x.509 or other), things like root CAs, are a fairly esoteric and very specialized field of study. There's people whose regular day jobs are nothing but doing stuff with PKI infrastructure and their depth of knowledge on many other non-PKI subjects is probably surface level only.

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

Re: DNSSEC disruption affecting .de domains – Resolved

#147

Earlier quoted context omitted.

To be fair, advanced real world knowledge of public/private key PKIs (x.509 or other), things like root CAs, are a fairly esoteric and very specialized field of study. There's people whose regular day jobs are nothing but doing stuff with PKI infrastructure and their depth of knowledge on many other non-PKI subjects is probably surface level only.

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.

In my initial comment, I meant more in terms of complexity and planning from the perspective of the people who are running the public/private key infrastructure on the other side/upstream of what you're doing as a letsencrypt end user.

Broadly similar general concept to the team responsible for the DNSSSEC signing keys for an entire ccTLD.

Yeah a x509 PKI / root CA is a very different thing than DNSSSEC but they have a number of general logical similarities in that the chain of trust ultimately comes down to a "do not fuck this up" single point of failure.

Re: DNSSEC disruption affecting .de domains – Resolved

#148

I must be early. There's not a single tptacek DNSSEC rant in this thread yet.

doesn't this event speak for itself though?

Kind-of. But there are worse things than outages when it's PKIs we're talking about. DNSSEC is also extremely opaque and unmonitored. Any compromise will not be noticed. Nor will anyone have any recourse against misbehaving roots.

Fun fact, CloudFlare has used the same KSK for zones it serves more than a decade now.

Re: DNSSEC disruption affecting .de domains – Resolved

#149

Earlier quoted context omitted.

A real party killer if I have ever seen one.

At least all of the appropriate people were in a room together when the outage happened

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

Re: DNSSEC disruption affecting .de domains – Resolved

#150
post #65

Earlier quoted context omitted.

Security = Confidentiality + Integrity + Availability or alternatively, Security = (exclude unauth'd reads) + (exclude unauth'd writes) + (include auth'd reads and auth'd writes) Gotta satisfy all parts in order to have security.

If you squint at it, you can convert all three to just availability. Confidentiality = available to us, but nobody else. Integrity = available to us in a pristine condition. It's a bit reductive, I'll admit, but it can be a useful exercise in the same way that everything in an economy can be reduce to units of either: "human time", "money" or "energy". Roughly speaking they're interchangeable. E.g.: What's the benefi…

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.

Post reply on HN