Russian TLD .RU fails DNSSEC validation(dnsviz.net)
dnsviz.net
Russian TLD .RU fails DNSSEC validation
https://dnsviz.net/d/cctld.ru/dnssec/
23 comments
That was scary. Fixed at about 16:55 UTC, total about 1hr of downtime.
The badly signed records are still there in various provider's DNS caches as of now. 8.8.8.8 and 9.9.9.9 in the Philippines are still affected - cannot resolve .ru domains.
Yeah, I think major Russian providers just flushed caches by hand, as rollout was by-region, which is not smooth nor simultaneous
EDIT: rollout in some very large telecom here is still in progress, by region.
EDIT: rollout in some very large telecom here is still in progress, by region.
I'm not familiar with DNSSEC. What sis the impact of this? Do web pages fail to load or is it just some security warning? Also was this just someone failing to update a cert in time or is this some sort of hack?
Basically, all ru. TLD became failing for all dns resolvers that use DNSSEC (which is the most of them)
As user, I am unable to visit any pages on .ru domains, as their IP would not resolve.
Reason is highly likely mistake (human side) in signing procedure, not something time- or hack- related.
Someone is most likely CC for TLD RU, aka АНО КЦНДСИ, official registry of .ru TLD.
As user, I am unable to visit any pages on .ru domains, as their IP would not resolve.
Reason is highly likely mistake (human side) in signing procedure, not something time- or hack- related.
Someone is most likely CC for TLD RU, aka АНО КЦНДСИ, official registry of .ru TLD.
If you're using DNSSEC-validating resolver servers (many of the popular ones are), then presumably all the signed names in .RU fell off the Internet completely, as if they never existed, for the duration of the outage.
Either someone failing to update the cert or the person who did it until has been sent to the meatgrinder. I really do wonder what effect war will have on the Russian IT industry. From what I read most IT professionals are protected from mobilisation, but on the other hand they might have a more open view of the world then Putin's regime.
As a side question: am I correct in reading this to imply that the two "leaf" keys here are both RSA 1024 keys? RSA 1024 has been considered within nation-state capabilities for well over a decade, and NIST has explicitly discouraged them for DNSSEC for close to a decade[1].
I can understand not using larger RSA key sizes for framing reasons, but what is stopping the DNSSEC ecosystem from using ECC?
[1]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...
I can understand not using larger RSA key sizes for framing reasons, but what is stopping the DNSSEC ecosystem from using ECC?
[1]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...
ECDSA is available in DNSSEC, and there is a slow migration to ECC in progress; see https://stats.dnssec-tools.org/#/?dnssec_param_tab=0
The .EDU, .NET, and .COM zones were recently migrated from RSA to ECDSA (DNSSEC algorithm 13); see, for instance: https://lists.dns-oarc.net/pipermail/dns-operations/2023-Dec...
Anyone newly enabling DNSSEC on their zone should probably use ECDSA.
The .EDU, .NET, and .COM zones were recently migrated from RSA to ECDSA (DNSSEC algorithm 13); see, for instance: https://lists.dns-oarc.net/pipermail/dns-operations/2023-Dec...
Anyone newly enabling DNSSEC on their zone should probably use ECDSA.
Until relatively recently, ECC DNS had (if I'm remembering Geoff Huston right) a 5% failure rate for resolvers. Towards the end, that may have mostly been a misconfiguration artifact (DNSSEC is extremely easy to misconfigure; see again Huston) but either way the perception has been that RSA is more compatible.
Also: why would you bother changing at this point? DNSSEC isn't getting traction (see, once again, Geoff Huston).
The 1024-bit key thing is unforgivable in 2024, but also endemic to DNSSEC.
Also: why would you bother changing at this point? DNSSEC isn't getting traction (see, once again, Geoff Huston).
The 1024-bit key thing is unforgivable in 2024, but also endemic to DNSSEC.
DNSSEC failure is just the result of many of the nameservers serving .ru and other tlds not responding. This is especially observable if you are IPv4 only.
Poor blog's getting the hug of death :)
it's not a blog - it's a DNSSEC validator tool that gives you a pretty diagram of which keys are signing what.
There are others around which I won't link to right now lest they get clobbered too.
There are others around which I won't link to right now lest they get clobbered too.
I saw this start at 10:14:29 CST.
DNSSEC is such a nightmare. All this "how do we make this old protocol secure and private without changing it much"
DNSSEC does absolutely nothing for privacy. It seeks to achieve strictly authentication and incidentally integrity.
when I said privacy I was had NSEC3 in mind. To be honest I have no idea how does it work / why is it a thing but it looks like it obfuscates (deleted?) subdomains to make it harder to enumerate them. This is why you see stuff like
15bg9l6359f5ch23e34ddua6n1rihl9h.example.org
Right. That doesn't really work: you can crack them like a 1990s password file, which is why there's whitelies (online-signer chaff records) to defeat that attack. Either way: it's not really what people think about when they think "privacy". It's generally the position of the architects of DNSSEC that domain names simply aren't private at all. Meanwhile: actual DNS privacy, of what domains you're visiting with your browser, is provided by DoH, not DNSSEC.
IIRC the protocol is also a nightmare for potential reflection DDoS attacks.
Also, the security chain is top-down, from owner of the TLD to the domain to the resolver to the client. With DNS over TLS and DNSCurve, you have it the other way around.
Also, the security chain is top-down, from owner of the TLD to the domain to the resolver to the client. With DNS over TLS and DNSCurve, you have it the other way around.
[deleted]