Russian TLD .RU fails DNSSEC validation (opens in new tab)

(dnsviz.net)

71 pointsainar-g2y ago22 comments

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

assusdan2y ago

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.

dgrin912y ago

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?

assusdan2y ago

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.

tptacek2y ago

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.

TomK322y ago

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.

woodruffw2y ago

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

bewaretheirs2y ago

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.

tptacek2y ago

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.

woodruffw2y ago

Yep, I'm not a defender of DNSSEC, just not especially familiar with it. The RSA 1024 thing was surprising as an outsider!

1 more reply

zokier2y ago

inertia

https://datatracker.ietf.org/doc/html/rfc6605

https://datatracker.ietf.org/doc/html/rfc8080

Chalbroth2y ago

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.

arcza2y ago

Poor blog's getting the hug of death :)

bewaretheirs2y ago

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.

krunck2y ago

I saw this start at 10:14:29 CST.

tryauuum2y ago

DNSSEC is such a nightmare. All this "how do we make this old protocol secure and private without changing it much"

naniwaduni2y ago

DNSSEC does absolutely nothing for privacy. It seeks to achieve strictly authentication and incidentally integrity.

1 more reply

Fnoord2y ago

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.

j / k navigate · click thread line to collapse

22 comments

assusdan2y ago

That was scary. Fixed at about 16:55 UTC, total about 1hr of downtime.

patrakov2y ago

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.

assusdan2y ago

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.

dgrin912y ago

assusdan2y ago

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.

tptacek2y ago

TomK322y ago

woodruffw2y ago

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

bewaretheirs2y ago

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.

tptacek2y ago

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.

woodruffw2y ago

Yep, I'm not a defender of DNSSEC, just not especially familiar with it. The RSA 1024 thing was surprising as an outsider!

1 more reply

zokier2y ago

inertia

https://datatracker.ietf.org/doc/html/rfc6605

https://datatracker.ietf.org/doc/html/rfc8080

Chalbroth2y ago

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.

arcza2y ago

Poor blog's getting the hug of death :)

bewaretheirs2y ago

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.

krunck2y ago

I saw this start at 10:14:29 CST.

tryauuum2y ago

DNSSEC is such a nightmare. All this "how do we make this old protocol secure and private without changing it much"

naniwaduni2y ago

DNSSEC does absolutely nothing for privacy. It seeks to achieve strictly authentication and incidentally integrity.

1 more reply

Fnoord2y ago

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.

j / k navigate · click thread line to collapse