Remix.run Logo
.de TLD offline due to DNSSEC?(dnssec-analyzer.verisignlabs.com)
501 points by warpspin 4 hours ago | 226 comments
krystofbe 4 hours ago | parent | next [-]

Looks like a DNSSEC issue, not a nameserver outage. Validating resolvers SERVFAIL on every .de name with EDE:

RRSIG with malformed signature found for a0d5d1p51kijsevll74k523htmq406bk.de/nsec3 (keytag=33834) dig +cd amazon.de @8.8.8.8 works, dig amazon.de @a.nic.de works. Zone data is intact, DENIC just published an RRSIG over an NSEC3 record that doesn't validate against ZSK 33834. Every validating resolver therefore refuses to answer.

Intermittency fits anycast: some [a-n].nic.de instances still serve the previous (good) signatures, so retries occasionally land on a healthy auth. Per DENIC's FAQ the .de ZSK rotates every 5 weeks via pre-publish, so this smells like a botched rollover.

qazwsxedchac 3 hours ago | parent | next [-]

So a single configuration mistake in a single place wiped out external reachability of a major economy. It happened in the evening local time and should be fixable, modulo cache TTLs, by morning. This will limit the blast radius somewhat.

Still, at this level, brittle infrastructure is a political risk. The internet's famous "routing around damage" isn't quite working here. Should make for an interesting post mortem.

gerdesj 8 minutes ago | parent | next [-]

"The internet's famous "routing around damage" isn't quite working here."

DNS is a look up service that runs on the internet.

Internet routing of IP packets is what the internet does and that is working fine (for a given value of fine).

You remind me of someone using the term "the internet is down" that really means: "I've forgotten my wifi password".

belorn an hour ago | parent | prev | next [-]

I am reminded of the warning that zonemaster gives about putting your domain name servers on a single AS, as is common practice for many larger providers. A lot of people do not want others to see this as a problem since a single AS is a convenient configuration for routing, but it has the downside of being a single point of failure.

Building redundant infrastructure that can withstand BGP and DNS configuration mistakes are not that simple but it can be done.

pocksuppet 2 hours ago | parent | prev | next [-]

DNS is a centralization risk, yes. Somehow we've decided this is fine. DNSSEC isn't the only issue - your TLD's nameservers could also be offline, or censored in your country.

skywhopper 2 hours ago | parent | next [-]

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

pocksuppet 44 minutes ago | parent [-]

BGP, but the names in question are limited to 128 bits, of which at most 48 will be looked up, and you don't get to choose which 48 bits are assigned to you.

greatgib an hour ago | parent | prev | next [-]

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

muvlon an hour ago | parent [-]

Let's Encrypt has to be down for days before people begin to feel the pain. DNS is very different, it breaks stuff immediately everywhere.

tharkun__ 8 minutes ago | parent [-]

No it doesn't. DNS breaks as soon as TTLs run out. It's your choice to set them so low that stuff breaks immediately.

cyberax 2 hours ago | parent | prev [-]

Not really? .com and .net are still up

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

sllabres 4 minutes ago | parent | next [-]

So it seems we need something like this [1] for IT infrastructure? ;)

[1] https://outerspaceinstitute.ca/crashclock/

akerl_ 24 minutes ago | parent | prev [-]

Presumably if LetsEncrypt goes down and stays down for a week, the sites that go down are the ones that see that their CA went down and at no point in the week take the option to get certs from a different CA?

Muromec an hour ago | parent | prev | next [-]

>So a single configuration mistake in a single place wiped out external reachability of a major economy.

And fuck nothing at all happened as a result.

Our_Benefactors an hour ago | parent [-]

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

lschueller 2 hours ago | parent | prev | next [-]

I have a bad feeling, that the impact will be quite severe for some services, as monitoring, performance, and security services might get disrupted. and just cleaning up is a big mess.. Worst case, some ot will experience outage and / or damage. But maybe I am just overestimating the severity of this.

walrus01 3 hours ago | parent | prev | next [-]

It looks like a failed key replacement during a scheduled maintenance event. Normally this sort of thing is thoroughly tested and has multiple eyes on for detailed review and planning before changes get committed, but obviously something got missed.

the8472 2 hours ago | parent | prev [-]

fail-closed protocols have introduced some brittleness. A HTTP 1.0 server from 1999 probably still can service visitors today. A HTTPS/TLS 1.0 server from the same year wouldn't.

dlopes7 3 hours ago | parent | prev [-]

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

icedchai 2 hours ago | parent | next [-]

I've been in IT 30+ years, been running DNS, web servers, etc. since at least 1994. I haven't bothered with DNSSEC due to perceived operational complexity. The penalty for a screw up, a total outage, just doesn't seem worth the security it provides.

walrus01 3 hours ago | parent | prev | next [-]

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.

hannob 2 hours ago | parent | next [-]

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.

silisili 2 hours ago | parent [-]

As is the overlap between DNSSEC and DNS itself, to be honest.

I once worked at the level of administering DNSSEC for 300+ TLDs. It's its own world. When that company was winding down, I tried to continue in the field but the most common response (outside of no response, of course), was 'we already have a DNS team/vendor/guy.' And well, then things like this happen. I won't throw stones though, it's a lot to learn and can be incredibly brittle.

hathawsh 2 hours ago | parent | prev | next [-]

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.

walrus01 2 hours ago | parent [-]

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.

mschuster91 2 hours ago | parent | prev [-]

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

Muromec an hour ago | parent | next [-]

The trick to asn.1 is to generate both parser and serializer from the spec. Elliptic curve math on the other hand is ... yeah, you need to know the math and also know the tricks to code that implements it. Both of those have steep learning curve, but it's hardly because it's a mess or it's old.

tptacek an hour ago | parent | next [-]

The trick to ASN.1 is to serialize/unserialize it backwards.

mschuster91 an hour ago | parent | prev [-]

> Both of those have steep learning curve, but it's hardly because it's a mess or it's old.

Bitpacking structures used to be important in the 60s. That time has passed, unless you're dealing with LoRa, NFC or other cases of highly constrained bandwidth there are way better options to serialize and deserialize information. It's time to move on, and the complexity of all the legacy garbage in crypto has been the case of many a security vulnerability in the past.

As for the code, it might be personal preference but I'd love to have at least some comments referring back to a specification or original research paper in the code.

Muromec an hour ago | parent | next [-]

I think you misunderstand the problem asn.1 solves and constrains it works within (both 30 years ago and now). We sure can have a better one now once we learned all the lessons and know what good parts to keep, but this critique of bitpacking is misplaced.

Avamander an hour ago | parent | prev [-]

ASN.1 is not used because of just bitpacking. There are other benefits to ASN.1 and it's probably one of the least problematic parts there.

People who have thought they can do better have made things like PGP. It's one of the worst cryptographic solutions out there. You're free to try as well though.

Muromec 43 minutes ago | parent [-]

People who though they can do better did JWT, that is not complicated at all and has no bugs as well. Also solves 20% of what asn.1 is used for.

tptacek an hour ago | parent | prev | next [-]

The typical vector for entering cryptography as a professional is called "grad school".

cyberax an hour ago | parent | prev [-]

X.509 is a deep legacy, but at least at this point it's well tested.

> because that's the only thing Java speaks

No, it most definitely is not. You can just construct a private key directly in BouncyCastle: https://downloads.bouncycastle.org/java/docs/bcprov-jdk18on-...

I'm 100% certain that you also can do that with raw java.security. I did that about 15 years ago with raw RSA/EC keys. You can just directly specify the private exponent for RSA (as a bigint!) or the curve point for EC.

Ditto for ed25519, you can just take the canonical implementation from DJB. And you really really shouldn't do that anyway, please just use OpenSSL or another similar major crypto library.

Muromec an hour ago | parent | next [-]

I wouldn't recommend touching openssl (the library, command line tools are okay-ish) with anything that breaths life.

mschuster91 an hour ago | parent | prev [-]

> I'm 100% certain that you also can do that with raw java.security.

I tried that, the problem is Meshcore specific - they do their own weird shit with private and public keys [1]. Haven't figured out how to do the private key import either, because in the C source code (or in python re-implementations) Meshcore just calls directly into the raw ed25519 library to do their custom math... it's a mess.

[1] https://jacksbrain.com/2026/01/a-hitchhiker-s-guide-to-meshc...

bflesch 2 hours ago | parent | prev [-]

Don't worry, that's by design ;)

Aldipower 2 hours ago | parent | prev | next [-]

Apparently the DENIC team was on a party this evening! Party hard, but not too hard. https://bsky.app/profile/denic.de/post/3ml4r2lvcjg2h

FinnKuhn 2 hours ago | parent | next [-]

A real party killer if I have ever seen one.

SOLAR_FIELDS 2 hours ago | parent [-]

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

SpaceNoodled 2 hours ago | parent [-]

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

bflesch 2 hours ago | parent [-]

nation state actor picking right time to sabotage a tiny part of the key rotation process. on monday someone cut major fiber lines, on tuesday DENIC is failing.

maybe someone is showing off?

walrus01 2 hours ago | parent | prev [-]

Interesting "bus problem" to have in a scenario where everyone who is qualified, experienced and trusted enough to commit lives changes (or perform a revert, undo results of a botched maintenance, etc) in an emergency situation is not completely sober.

femto an hour ago | parent | next [-]

Sobriety is just factor to be weighed in an emergency situation. 30 years ago I was at a ski resort with about 50 friends having a drinking competition in the resort's main bar. Late that night two ski lodges collapsed, trapping people inside. Around midnight, soon after the winner was announced, the police entered and asked "who's able to drive a crane truck?" The winner of the competition put his hand up and informed them of how much he had had to drink. Don't care they said, so he drove a crane big enough to lift a building up a single lane 35km mountain road in nighttime ice conditions. (The crane made it, but sadly most of the people in the ski lodges didn't. https://en.wikipedia.org/wiki/1997_Thredbo_landslide )

jamesfinlayson 25 minutes ago | parent [-]

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.

Muromec an hour ago | parent | prev [-]

Sounds like Europe, yes.

tom1337 3 hours ago | parent | prev | next [-]

I have never used DNSSEC and never really bothered implementing it, but do I understand it correctly that we took the decentralized platform DNS was and added a single-point-of-failure certificate layer on top of it which now breaks because the central organisation managing this certificate has an outage taking basically all domains with them?

gucci-on-fleek 2 hours ago | parent | next [-]

> which now breaks because the central organisation managing this certificate has an outage

The ".de" TLD is inherently managed by a single organization, and things wouldn't be much better if its nameservers went down. Some of the records would be cached by downstream resolvers, but not all of them, and not for very long.

> we took the decentralized platform DNS was and added a single-point-of-failure certificate layer on top of it

DNSSEC actually makes DNS more decentralized: without DNSSEC, the only way to guarantee a trustworthy response is to directly ask the authoritative nameservers. But with DNSSEC, you can query third-party caching resolvers and still be able to trust the response because only a legitimate answer will have a valid signature.

Similarly, without DNSSEC, a domain owner needs to absolutely trust its authoritative nameservers, since they can trivially forge trusted results. But with DNSSEC, you don't need to trust your authoritative nameservers nearly as much [0], meaning that you can safely host some of them with third-parties.

[0]: https://news.ycombinator.com/item?id=47409728

tom1337 2 hours ago | parent [-]

> DNSSEC actually makes DNS more decentralized: without DNSSEC, the only way to guarantee a trustworthy response is to directly ask the authoritative nameservers. But with DNSSEC, you can query third-party caching resolvers and still be able to trust the response because only a legitimate answer will have a valid signature.

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? As far as I understood the TTL for those keys is different and for DENIC it seems to be 1h [0]. 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?

[0] dig RRSIG de. @8.8.8.8

de. 3600 IN RRSIG DNSKEY 8 1 3600 20260519214514 20260505201514 26755 de. [...]

gucci-on-fleek 2 hours ago | parent [-]

> 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==
tom1337 2 hours ago | parent [-]

Thanks for explaining. I thought that once any key in the chain-of-trust of any domains DNSSEC expired the whole record went stale but turns out that was a wrong assumption. If the DNSKEY and the other records have the same TTL and the DNSSEC verification is also "cached" then that makes a lot more sense.

gucci-on-fleek an hour ago | parent [-]

> I thought that once any key in the chain-of-trust of any domains DNSSEC expired the whole record went stale but turns out that was a wrong assumption.

No, that actually is true, but I think (?) that the part that you were missing is that DNSSEC records are mostly the same as any other record, so they can be cached the same way. And since most resolvers are DNSSEC-enabled these days, they'll tend to request (and therefore cache) the DNSSEC records at the same time as the regular records.

There are tons of edge cases here, but it should hopefully be pretty rare for a cache to have a current A/AAAA record and stale/missing DNSSEC records.

> the DNSSEC verification is also "cached"

Technically the verification itself isn't cached, but since verification only depends on the chain of DNSSEC records, and those records are cached, it has the same effect.

wahern 2 hours ago | parent | prev | next [-]

DNSSEC doesn't change the degree to which DNS is decentralized. It's always been hierarchical. In the absence of caching, every DNS query starts with a request to the root DNS servers. For foo.com or foo.de, you first need to query the root servers to determine the nameservers responsible for .com and .de. Then you contact the .com or .de servers to ask for the foo.com and foo.de nameservers. All DNSSEC does is add signatures to these responses, and adds public keys so you can authenticate responses the next level down.

A list of root nameserver IP addresses is included with every local recursive DNS resolver. The list changes, albeit slowly, over the years. With DNSSEC, this list also includes public keys of those root servers, which also rotate, slowly.

Medowar 3 hours ago | parent | prev [-]

What you see here is decentralisation working. The issue is with the operator of the de TLD, and as such only that TLD is affected. DNS is not decentralised in such a way, that multiple organisations run the infrastructure of a TLD, those are always run by a single entity.(.com and .net are operated by Verisign)

So what the issue is, that the operator has, does not change the impact.

AndroTux 2 hours ago | parent [-]

What if the root (.) certificate breaks?

pocksuppet 2 hours ago | parent [-]

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.

tom1337 2 hours ago | parent | prev | next [-]

Cloudflare has now disabled DNSSEC validation on their 1.1.1.1 resolver: https://www.cloudflarestatus.com/incidents/vjrk8c8w37lz

tptacek an hour ago | parent | next [-]

Welp. I think can call it on DNSSEC now.

amluto an hour ago | parent [-]

Hahaha. You wish :-p

tptacek an hour ago | parent [-]

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.

cluckindan an hour ago | parent | prev [-]

If it turns out the DNSSEC issue was caused by threat actors, this downstream effect could very well have been the reason to do it.

amluto an hour ago | parent [-]

It is indeed a bit sad that Cloudflare had to turn off DNSSEC completely. But I completely understand that they don't have a production-ready, tested path to override DNSSEC validation for only some domains.

vendemiat 39 minutes ago | parent [-]

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

tptacek 29 minutes ago | parent [-]

That's not much better!

SEJeff an hour ago | parent | prev | next [-]

Just gonna leave this absolute gem from Thomas Ptacek on DNSSEC here:

https://sockpuppet.org/blog/2015/01/15/against-dnssec/

betaby an hour ago | parent [-]

Aged like a milk.

tptacek an hour ago | parent [-]

Oh, yeah, I'm sure feeling chastened right now. You got me.

SAI_Peregrinus 5 minutes ago | parent [-]

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

siva7 3 hours ago | parent | prev | next [-]

Crazy. I can't remember an incident like this ever happened before and it's still not fixed? .de is probably the most important unrestricted domain after .com from an economical perspective. Millions of businesses are "down".

rwmj 3 hours ago | parent | next [-]

I remember when .com went down, in July 1997.

https://archive.nytimes.com/www.nytimes.com/library/cyber/we...

ctippett 3 hours ago | parent [-]

> For instance, the name "www.nytimes.com" corresponds to nine different computers that answer requests for The New York Times on the Web, one of which is 199.181.172.242

  $ dig -x 199.181.172.242 +short
  www2.nytimes.com.
Neat.
AndroTux 3 hours ago | parent | prev | next [-]

DENIC apparently resolved all .de domains to NXDOMAIN in 2010: https://www.theregister.com/2010/05/12/germany_top_level_dom...

8organicbits 23 minutes ago | parent | prev | next [-]

There's a good index of major DNSSEC outages here, https://ianix.com/pub/dnssec-outages.html

lschueller 3 hours ago | parent | prev | next [-]

It's Germany, pessimistic time estimation + 1/3 and you are in a realistic time frame for the issue being resolved.

warpspin 3 hours ago | parent | next [-]

It's night. Somebody has to fill a form to approve night work first.

daneel_w an hour ago | parent | next [-]

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

carstenhag 2 hours ago | parent | prev | next [-]

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

greyhound 3 hours ago | parent | prev | next [-]

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

dgellow 2 hours ago | parent | next [-]

Fax, actually! Will still take 5–30 business days for approval, for some reasons

9dev 3 hours ago | parent | prev | next [-]

Oh come on, that’s not true. You could also fax it. That might come with an additional processing fee though.

rasz 3 hours ago | parent | prev [-]

Dont be ridiculous, thats what FAX is for.

snapetom 3 hours ago | parent | prev [-]

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

lschueller 3 hours ago | parent | next [-]

Or reading the latest prints about tax filings and how to conduct a compliance audit with pen and paper.

thih9 2 hours ago | parent [-]

Or sweeping.

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

layer8 2 hours ago | parent [-]

That's a sweeping generalization.

pimeys 2 hours ago | parent | prev [-]

Or in Berghain

Cockbrand 3 hours ago | parent | prev [-]

In addition: it's Germany, pessimistic cost estimation + 2000%, and you are in a realistic budget for the issue being resolved.

lschueller 3 hours ago | parent [-]

:D... before tax!

carstenhag 2 hours ago | parent | prev | next [-]

Well it was already very late in the day (21-22?) so the impact was not big I would say

HDBaseT 2 hours ago | parent | prev [-]

Germany isn't as big as you think.

trollbridge 2 hours ago | parent [-]

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

TacticalCoder 6 minutes ago | parent | next [-]

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

Muromec an hour ago | parent | prev [-]

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.

sundiver 4 hours ago | parent | prev | next [-]

Yes, all .de domains down because of DNSSEC failure at Denic https://dnsviz.net/d/de/dnssec/

taegee 4 hours ago | parent | next [-]

https://i.imgur.com/eAwdKEC.png

Edit: Alternative link: https://www.cyberciti.biz/media/new/cms/2017/04/dns.jpg

_ache_ 3 hours ago | parent | next [-]

https://dns.kitchen/dns.mp4

Or: https://dns.kitchen/jingle

notpushkin 4 hours ago | parent | prev [-]

  {"data":{"error":"Imgur is temporarily over capacity. Please try again later."},"success":false,"status":403}
There is some strange irony to this, I suppose.
yjftsjthsd-h 4 hours ago | parent | next [-]

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)

itvision 3 hours ago | parent | prev | next [-]

A protection against bad networks, including VPN.

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

ricardo81 3 hours ago | parent | prev [-]

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

londons_explore 2 hours ago | parent | next [-]

Other countries are available. With a UK passport you can move to Ireland, Thailand, or Australia fairly easily, amongst others.

9dev 3 hours ago | parent | prev [-]

Rather, not an ideal legislation nowadays…

bflesch 2 hours ago | parent | prev [-]

We should frame it as "all .de domains are ready to be impersonated because everyone will disable DNSSEC".

pocksuppet 3 hours ago | parent | prev | next [-]

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

tptacek an hour ago | parent | next [-]

What would I need to rant about? Sometimes the world does my ranting for me.

apaprocki 2 hours ago | parent | prev | next [-]

Maybe he drank a little too much Malört with the DENIC team last night?

aberoham 3 hours ago | parent | prev | next [-]

He’s busy with MathAcademy earning XP-SEC

0123456789ABCDE 3 hours ago | parent | prev | next [-]

doesn't this event speak for itself though?

Avamander 2 hours ago | parent [-]

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.

daneel_w an hour ago | parent [-]

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

Avamander an hour ago | parent [-]

It is not fine. Keeping key material safe is not a boolean between "permanently safe" and "leaks immediately".

Keeping key material secure for more than a decade while it's in active use is vastly more complex than keeping it secure for a month, until it rotates.

For all we know, some ex-employee might be walking around with that KSK, theoretically being able to use it for god knows what for an another decade.

mike-cardwell 3 hours ago | parent | prev [-]

Perhaps he's moribund

chromehearts 4 hours ago | parent | prev | next [-]

I was STRESSING tf out because I wasn't able to connect to my services & apps through my domains like at all .. they only work when using my phone data ? .. thank god it's not my fault this time

Locke80 3 hours ago | parent [-]

But we're Germans, and we need someone to blame.

lschueller 3 hours ago | parent | next [-]

Thank god for the german chain of blame: 1. The system 2. The neighbor 3. China

warpspin 3 hours ago | parent [-]

You definitely forgot Merkel and Habeck.

Cockbrand 3 hours ago | parent [-]

Danke Merkel!!1!11!!

AndroTux 3 hours ago | parent | prev [-]

I'm blaming chromehearts anyways

sunaookami 4 hours ago | parent | prev | next [-]

https://status.denic.de/ says "Partial Service Disruption" for DNS Nameservice now.

EDIT: it says "Service Disruption" now

port3000 2 hours ago | parent | next [-]

Even when every site in the world’s 3rd biggest economy goes down it’s still just a ‘Partial’ service disruption :D

gruselhaus 2 hours ago | parent | prev | next [-]

Whole Germany is offline. DENIC: "Partial Service Disruption". That's one way to phrase it.

MASNeo 3 hours ago | parent | prev | next [-]

At least they have some humor left.

Edit: Now even the humor is gone.

sunaookami 3 hours ago | parent [-]

Can only be topped when the status page is not reachable anymore :D

EDIT: called it...

lschueller 3 hours ago | parent [-]

Or only accessible through a german dns server

niklasrde 3 hours ago | parent | prev | next [-]

It says "Server Not Found" now

cubefox 41 minutes ago | parent | prev [-]

"All Systems Operational"

Zopieux 38 minutes ago | parent [-]

Yes, it's fixed.

kuerbel 4 hours ago | parent | prev | next [-]

I just spent the better half of an hour to debug unbound and the pihole because I thought it's a me problem...

Good news though, if you add domain-insecure: "de" to your unbound config everything works fine

Bender 3 hours ago | parent | next [-]

I don't even enable DNSSEC in Unbound. There just isn't enough adoption yet for me to feel like I am missing out on something, yet.

"Cloudflare Radar data shows 8.11% of domains are signed with DNSSEC, but only 0.47% of queries are validated end-to-end." [1]

Zones I may care about:

- Amazon.com: unsigned

- My banks: unsigned

- Hacker News: unsigned

- Email that I do not host: unsigned

- My power companies billing: unsigned

- I found some! id.me and irs.gov are signed.

[1] - https://technologychecker.io/blog/dnssec-adoption

V__ 2 hours ago | parent | prev | next [-]

Just before the outage happened I updated multiple client servers. That was a very stressfull hour trying to figure out why nothing works.

victorbjorklund 4 hours ago | parent | prev | next [-]

Same haha

chromehearts 4 hours ago | parent | prev [-]

SAMEEEEE !!!

__michaelg 4 hours ago | parent | prev | next [-]

Finally establishing the concept of Feiertag on the internet. Come back tomorrow.

throw1234567891 3 hours ago | parent | next [-]

Internetfreie Dienstage, 21st century variant of Autofreie Sonntage.

9753268996433 3 hours ago | parent | prev [-]

Using this newfangled thingamabob on a silent holiday will result in the police kicking in your door the next morning.

aboardRat4 31 minutes ago | parent | prev | next [-]

https://ianix.com/pub/dnssec-outages.html

1vuio0pswjnm7 4 hours ago | parent | prev | next [-]

.de TLD is online. DNS working fine

DNSSEC not working

If using an open resolver, i.e., a shared DNS cache, e.g., third party DNS service such as Google, Cloudflare, etc., then it might fail, or it might not. It depends on the third party DNS provider

https://datatracker.ietf.org/meeting/118/materials/slides-11...

kaltsturm 2 hours ago | parent | prev | next [-]

Denic will be added to the "Major DNSSEC Outages and Validation Failures" list: https://ianix.com/pub/dnssec-outages.html

iknowstuff 4 hours ago | parent | prev | next [-]

Kurzgesagt predicted this, Germany is OVER

irundebian 4 hours ago | parent [-]

Danke Merkel

mschuster91 2 hours ago | parent [-]

Not sure if serious or /s

nfreising 3 hours ago | parent | prev | next [-]

They can join the (rather long) list of TLD DNSSEC outages https://ianix.com/pub/dnssec-outages.html

edb_123 2 hours ago | parent | prev | next [-]

Things seem to be on their way up now, and https://status.denic.de/ is working again, at least from here.

DENIC's status page currently says "Frankfurt am Main, 5 May 2026 – DENIC eG is currently experiencing a disruption in its DNS service for .de domains. As a result, all DNSSEC-signed .de domains are currently affected in their reachability. The root cause of the disruption has not yet been fully identified. DENIC’s technical teams are working intensively on analysis and on restoring stable operations as quickly as possible.

Zopieux an hour ago | parent | prev | next [-]

That postmortem should be a fun read, can't wait.

Culonavirus 20 minutes ago | parent | next [-]

Ok children, sit down and listen, uncle Culonavirus will tell you a story:

"It all began with the decommissioning of the last nuclear power plant, ..."

retired an hour ago | parent | prev [-]

We shall transmit the postmortem to you via fax within 25 business days, ja.

basilikum 43 minutes ago | parent | prev | next [-]

This is the kind of system failure that we need really good and well tested disaster recovery plans for. While not necessary this time, DENIC and any critical infrastructure provider should be able to rebuild their entire infrastructure from scratch in a tolerable amount of time (Rather days than hours in the case of a full rebuild). Importantly the disaster recovery plan has to work without reliance on either the system that is failing, but also on adjacent systems that might have hidden dependencies on the failing system.

I'm really not too close to Denic and know nothing about their internals, but just close enough to have experienced the stress of someone working for DENIC second hand during the outage. From the very limited information I happened to gather DENIC had some trouble in addressing the issue because, surprise, infrastructure that they need to do so runs on de domains. [1]

I'm convinced there are all kinds of extended cyclic decencies between different centralization points in the net.

If some important backbone of the internet is down for an extended time, this will absolutely cause cascading failures. And thesw central points of failure are only getting worse. I love Let's Encrypt, but if something causes them to hard fail things will go really bad once certificates start to expire.

We need concrete plans to cold start extended parts of the internet. If things go really bad once and communication lines start to fail, we're in for a bad time.

Maybe governments have redundant, ultra resistant, low tech communication lines, war rooms and a list of important people in the industry who they can find and put in these war rooms so they can coordinate the rebuild of infrastructure. But I doubt it.

[^1] I don't know if there is some kind of disaster plan in the drawer at DENIC that would address this. I don't mean to allege anything against DENIC specifically, but broadly speaking about companies and infrastructure providers, I would not be surprised if there was absolutely no plan on what to do if things really go down and how to cold start cyclic dependencies or where they even are.

elevation 3 hours ago | parent | prev | next [-]

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.

whalesalad 3 hours ago | parent [-]

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.

cedilla 2 hours ago | parent [-]

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

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

akerl_ 20 minutes ago | parent [-]

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

yassiniz 2 hours ago | parent | prev | next [-]

Shops open normally from 8am to 8pm in Germany. Today we decided to pilot opening hours for .de domains as well

kangalioo 4 hours ago | parent | prev | next [-]

So glad I found someone mention this. Amazon.de, SPIEGEL.de is down. Highly prominent sites unreachable. I wonder how long this will last and how big of a thing this ends up being once people talk about it :o Feels big to me

moltar 4 hours ago | parent | next [-]

Both examples open for me

irundebian 4 hours ago | parent [-]

Some domains work, some not. I assume that working domains are cached.

balou23 4 hours ago | parent | prev | next [-]

amazon.de, spiegel.de are down for me, too. heise.de works, but that might've been cached somewhere on my side.

yk 4 hours ago | parent [-]

dig manages to dig out ips for heise.de and tagesschau.de but not spiegel.de amazon.de and google.de However, dig @8.8.8.8 has still amazon.de cached, unlike 1.1.1.1 so perhaps Google to the rescue?

[Edit] After playing around with it, google seems to have at least some pages cached. After setting dns to 8.8.8.8 amazon.de and spiegel.de work again, my blog does not.

theanonymousone 3 hours ago | parent | prev [-]

idealo.de, ebay.de, and spiegel.de are down, but amazon.de opens for me.

kaltsturm 3 hours ago | parent | prev | next [-]

https://dnsviz.net/d/spiegel.de/dnssec/

yes indeed

dwedge 3 hours ago | parent | prev | next [-]

On a slightly unrelated note, I was setting nameservers for two .de domains a few weeks ago and thought my provider was being crazily strict because they kept getting rejected. Turns out you can't point to a nameserver until that nameserver has a zone for the domain, and you can't use nameservers from two providers unless those two providers are both in the NS records at both ends

whalesalad 3 hours ago | parent [-]

Common paint point with DNSSEC. It’s brutal in the domain industry because when you buy a name with DNSSEC enabled it oftentimes can’t be setup to resolve due to these sorts of issues. Typically seller needs to deactivate first.

merb 4 hours ago | parent | prev | next [-]

Well at least it’s night time which means it’s hopefully resolved in the morning.

Looks like it failed after a maintenance: https://www.namecheap.com/status-updates/planned-denic-de-re...

https://status.denic.de/

gpvos 3 hours ago | parent [-]

If so, it still worked for several hours after the maintenance was completed.

yowmamasita 2 hours ago | parent | prev | next [-]

The same day Kurzgesagt posted their video “Germany is over”. Huh. https://youtu.be/n-gYFcVx-8Y

taf2 2 hours ago | parent | prev | next [-]

ok i picked a bad day to move from one register to another... i just spent the last hour frantically trying to figure out why the new register screwed us or the old register was screwing us...

kaltsturm 3 hours ago | parent | prev | next [-]

Denic should work out a desaster recovery test - like: https://blog.apnic.net/2022/02/14/disaster-recovery-with-dns...

0x80h 3 hours ago | parent | prev | next [-]

Am I reading this correctly? All .de domains are down? Looking forward to reading the postmortem.

4 hours ago | parent | prev | next [-]
[deleted]
hmilch99 4 hours ago | parent | prev | next [-]

https://pastebin.com/2mQUB8xX seems like someone's going to have a lot of fun tonight

nuil 4 hours ago | parent | prev | next [-]

Looks Like a DNSSEC error:

https://dnssec-analyzer.verisignlabs.com/nic.de

edo888 3 hours ago | parent | prev | next [-]

https://community.letsencrypt.org/t/issues-getting-certifica...

g4cg54g54 3 hours ago | parent | prev | next [-]

funfact: enabling DNS sec NOW will fix your domain instantly if dnssec was disabled before

-> no idea if that also "heals" anyone who had dnssec on before.

-> no idea if maybe they need to roll back something and then rebreak the new dnssec i made a minute later lol...

NooneAtAll3 35 minutes ago | parent | prev | next [-]

quad9 seems to be having problems with DNSSEC as well

yosamino 3 hours ago | parent | prev | next [-]

The last time .de I remember .de had a major outage like this was 2010. I would cite some sources but... you know. That was a fun afternoon, though.

I am very happy that it doesn't happen more often.

warpspin 4 hours ago | parent | prev | next [-]

Whole .de TLD seems to go offline right now due to dnssec or missing nic.de nameservers?

fweimer 4 hours ago | parent | next [-]

This works:

    $ unbound-host -t A www.denic.de
    www.denic.de has address 81.91.170.12
This does not:

    $ unbound-host -D -t A www.denic.de
    www.denic.de has address 81.91.170.12
    validation failure <www.denic.de. A IN>: signature crypto failed from 194.246.96.1 for DS denic.de. while building chain of trust
So it does seem DNSSEC-related.

EDIT My explanation was wrong, this is not how keytags work. The published keytag data is consistent:

    de. 3600 IN DNSKEY 256 3 8 AwEAAfRLmzuIXVf7x5A0+U7hke0dS+GEJG0EdPhnOthCCLhy0t0WqLyoXJOhnfsTJ8vQX5fd9qOJc9gyr3SWJZkXAhPm3yPSC7FWWHF70WZTKKM9CekmKdqwMwq6ZCjMSUcecCuSF4Sbt1MRszV7rFmfGVklA1l5UzNbqwD+Dr5vfcLn ;{id = 33834 (zsk), size = 1024b}
    de. 3600 IN DNSKEY 257 3 8 AwEAAbWUSd/QN9Ae543xzdiacY6qbjwtZ21QfmdgxRdm4Z7bjjHWy249uqxCyjjjoS4LDoRDKmj7ElffMKvTWKE1qFKu0p8TUy4wyhX0M+m5FUjvQ3CiZMi+qY7GSHA5B+Zd73cidmnTeb3e8lso6jEsXg05/VZ2AyAqWF6FexEIFxIqiwwLk4UP0BwZ17Ur3q1qx9VSbPMyHgQ9d6nHUN1EEJsTDA2v0vKumsUyp74ZanRZ/bB/6IzpaaZyr5BLF5pSCNdbRNjVmkwYD0993vm79LueyOeibsoHRc16jhALrIJou1PFjdq7YQsYN0KtqRiJtaAfPprDBREpeamPuW/MnW0= ;{id = 26755 (ksk), size = 2048b}
    de. 3600 IN DNSKEY 256 3 8 AwEAAbTe1PJi8EgIudNGb+KRTxBL2aCu5rXkZ+aIe/TC88pwRdrXYeXODp1ihZWFop5CrbWRBLrk/YUPBE8aBc6oJP+58dSkdMLYkjSkmvdvYx+zXnRLWlF2bapxvZxshATJDfGjGbCiWxKEOoyRx3UhICtHC+cUSddsEvzfacUcBb6n ;{id = 32911 (zsk), size = 1024b}
    de. 3600 IN RRSIG DNSKEY 8 1 3600 20260519030655 20260505013655 26755 de. ke56T5GZt/X6zMBAF+ouyCTnAd7RY7MsnDcfa9jyyOwSouRXhvzim/V13JDTMBAnpAHxWQXoruXrAZ6A6re5N+8Pp2utVkAEKTWs0r4UOLNKoZ2+zMwNplKjNNnY5PJIbHfa5myyziLiIsi//qDIgQEACFk+pZcHXrRdqRoXPCL3UtfaXjk3+duDQdlPnYsJys5UshjVpkALSMChW7J0anzr0sG+f9ytstBneymMwFYOUC3NqbejbLPZsXGPZBQKPAoVJuV5q3znopbcqrDFfjI7bmX3QPYNvOaiT1ElBfi2piJVpDzMaMAmm2jCmvrf5VeTOBccMroh8sBtDPsaEg== ;{id = 26755}
The signature on the SOA record still does not verify:

    de. 86400 IN SOA f.nic.de. dns-operations.denic.de. 1778014672 7200 7200 3600000 7200
    de. 86400 IN RRSIG SOA 8 1 86400 20260519205754 20260505192754 33834 de. aZoiAJ+PaHUDVSHNXfV/R26ZK3GpFB7ek2Z46VnZdmPEDaTww+a7PkiQ98W83xohUunXYSvQCMeGYfUre5UT76eBKThdxW2a6ImX9/x/oEzQ9x/69Y/NSeTckOv9m3HCLBOug01op1koiHOIAVEvonOmXEHHqo1P4sR/fNbcVg4= ;{id = 33834}
4 hours ago | parent [-]
[deleted]
kaltsturm 3 hours ago | parent | prev [-]

not all: https://www.heise.de/ works

edb_123 3 hours ago | parent | next [-]

Doesn't work here, at least not anymore. Every single .de domain I have tried doesn't resolve.

warpspin 3 hours ago | parent | prev [-]

Probably just a high TTL.

0123456789ABCDE 3 hours ago | parent [-]

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

kaltsturm 2 hours ago | parent | prev | next [-]

from my analysis DENIC resigned the .de zone today (May 5, 2026, ~17:49 UTC). The DNSSEC signature (RRSIG) for the NSEC3 record covering the hash range of nearly all .de TLD is cryptographically broken (malformed).

jamietanna 4 hours ago | parent | prev | next [-]

Was wondering why a few of my sites aren't CSSing, as they use https://classless.de

kaltsturm 3 hours ago | parent [-]

cache

victorbjorklund 4 hours ago | parent | prev | next [-]

I was just wondering what was up with our .de site.

kaltsturm 3 hours ago | parent | prev | next [-]

even their own status page is not reachable: https://status.denic.de/

As fallback they should use their X account: https://x.com/denic_de

dgellow 3 hours ago | parent | next [-]

Seems to be up now?

May 5, 2026 23:28 CEST

May 5, 2026 21:28 UTC

INVESTIGATING

Frankfurt am Main, 5 May 2026 – DENIC eG is currently experiencing a disruption in its DNS service for .de domains. As a result, all DNSSEC-signed .de domains are currently affected in their reachability. The root cause of the disruption has not yet been fully identified. DENIC’s technical teams are working intensively on analysis and on restoring stable operations as quickly as possible. Based on current information, users and operators of .de domains may experience impairments in domain resolution. Further updates will be provided as soon as reliable findings on the cause and recovery are available. DENIC asks all affected parties for their understanding. For further enquiries, DENIC can be contacted via the usual channels.

elch 3 hours ago | parent | next [-]

All .de domains are down for me.

kaltsturm 3 hours ago | parent | prev [-]

with firefox: KO with chrome: OK

sunaookami 3 hours ago | parent | prev [-]

They did now! https://x.com/denic_de/status/2051779175908774148

niklasrde 3 hours ago | parent [-]

And in English: https://x.com/denic_de/status/2051779740080521646

Oarch 2 hours ago | parent | prev | next [-]

Germany has fallen.

lxgr 4 hours ago | parent | prev | next [-]

Wow, I thought I was somehow unaffected but my resolver must just have cached the sites I'd tried.

tarruda 3 hours ago | parent | prev | next [-]

Mailbox.org (also from Germany) seems to be experiencing issues too.

binghatch 4 hours ago | parent | prev | next [-]

Wow… it’s definitely not all .de TLDs, but a lot of prominent ones definitely.

phit_ 4 hours ago | parent | next [-]

its gonna be all .de domains once caches dry out, anything that still works right now is bound to eventually fail until the underlying issue is resolved

fossdd 4 hours ago | parent [-]

Any .de domain with DNSSEC

mrngm 3 hours ago | parent | next [-]

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.

meineerde 4 hours ago | parent | prev [-]

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

eliaskg 3 hours ago | parent | prev [-]

Amazon is completely down in Germany. Not only on amazon.de, even in the app.

jiveturkey 2 hours ago | parent | prev | next [-]

It’s not DNS

There’s no way it’s DNS

It was DNSSEC

kaltsturm 2 hours ago | parent | prev | next [-]

With chrome it works again

Animux 2 hours ago | parent | prev | next [-]

Seems to be fixed now.

whalesalad 3 hours ago | parent | prev | next [-]

You can visually see this anomaly in many of CF Radar's charts: https://radar.cloudflare.com/dns/de?dateRange=1d

bflesch 2 hours ago | parent | prev | next [-]

On Monday there was a huge outage affecting several cities quite close to Frankfurt because someone cut major fiber line; today DENIC is having a party and right when everyone is drunk this happens because some post-rotation task cannot be completed.

There are too many coincidences happening.

dark-star 3 hours ago | parent | prev | next [-]

How come I have zero problems with any .de domain I tried accessing in the last half hour?

AndroTux 3 hours ago | parent | next [-]

maybe your upstream doesn't validate DNSSEC?

dark-star 3 hours ago | parent [-]

maybe? I'm using PiHole and 8.8.8.8/1.1.1.1 as upstream, and both options show "DNSSEC" next to their options in settings, so I assumed DNSSEC was enabled (unless I have to enable this somewhere else as well?)

warpspin 3 hours ago | parent [-]

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.

pw6hv 3 hours ago | parent | prev [-]

cache

jiggawatts 4 hours ago | parent | prev | next [-]

I work with a few people specialised in IT security, and some of them take their jobs too seriously and will "lock down" everything to the point that it becomes a very real risk that they lock out everyone including themselves.

Fundamentally, security is a solution to an availability problem: The desire of the users is for a system to remain available despite external attack.

Systems that become unavailable to everyone fail this requirement.

A door with its keyhole welded shut is not "secure", it's broken.

QuantumNomad_ 3 hours ago | parent | next [-]

Security is not just a solution to availability. It is also to keep sensitive data (PII, or business secrets, or passwords, or cryptographic private keys, and so on) away from the hands of bad actors.

If I’m unable to use Amazon for 24 hours it doesn’t really matter. If a photo copy of my passport is leaked that’s worries and potential troubles for years.

senkora 3 hours ago | parent | prev [-]

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.

jiggawatts 3 hours ago | parent [-]

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 benefit to you if your data is so confidential that you can't read it either? This is a real problem with some health information systems, where I can't access my own health records! Ditto with many government bureaucracies that keep my records safe and secure from me.

dnnddidiej 2 hours ago | parent [-]

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.

sanbaideng 3 hours ago | parent | prev | next [-]

aiimageupscaler

siginator 3 hours ago | parent | prev | next [-]

how is that possible?

aweiher 3 hours ago | parent [-]

Solar Flares

dnnddidiej 2 hours ago | parent [-]

Took more than cloud flares?

pogii123 4 hours ago | parent | prev | next [-]

For me bmw.de works but www.bmw.de not

benny_s 4 hours ago | parent [-]

bmw.de is down for me too

MikeNotThePope 4 hours ago | parent | next [-]

Both domains page load for me from Amsterdam. I wonder if there's communication disruption. Undersea cable severed?

dark-star 3 hours ago | parent | next [-]

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

pogii123 4 hours ago | parent | prev [-]

$ 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

dark-star 3 hours ago | parent | prev [-]

both work for me from inside Germany

amelius 2 hours ago | parent | prev [-]

Maybe related to this? Crazy idea, but nothing surprises me anymore.

https://edition.cnn.com/2026/05/01/politics/us-troop-withdra...