ru tld down?
Not exactly down… they just busted their DNSSEC, or their domain got hijacked or something. Bad DNSKEY records.
-Bill
does this impact microsoft copilot in EU from being accessed?
Flash | Users across Russia report widespread access issues to [.] ru domains, including of Yandex, Megafon, and Sberbank: Local News Outlet via Forbes Russia.
https://dnsviz.net/d/ru/ZbjruA/dnssec/
https://dnsviz.net/d/ru/ZbkVXw/dnssec/
Obviously ZSK rotation failed.
Not necessarily saying these are related, but given the current geopolitical situation, not beyond the realm of possibility that this is the result of ‘something else’ gone wrong.
https://www.google.com/search?&q=russia+internet+disconnection+test
Not exactly down… they just busted their DNSSEC, or their domain got hijacked or something. Bad DNSKEY records.
Not necessarily saying these are related, but given the current geopolitical situation, not beyond the realm of possibility that this is the result of 'something else' gone wrong.
Phil Kulin posted a more specific timeline on dns-ops:
Unrelated question, but this error made me notice: Why do they put
their DNS servers in an unsigned zone? I can't figure out a good reason
to do that when you have all the signing infrastructure in place. But I
guess there must be a reason?
Bjørn
Peace,
TWIMC: the .ru TLD has issued a post mortem. A tl;dr version:
After a new key was crafted during an ordinary key update process, its key tag hash-collided with some other key, and due to a violation of the MUST NOT clause in the RFC 4034, Appendix B, the wrong key was deployed to the system.
Given “MUST NOT” is not in RFC 4034, Appendix B, I’d take this with a grain
of salt. Appendix B has a “NOT RECOMMENDED” but that applies to using RSA/MD5
keys.
Key id collisions are part and parcel of DNSSEC. In BIND we reject collisions
when generating new keys so we don’t have to deal with multiple keys with the
same key id and algorithm when signing. The validator handles them however.
They do make re-signing more complicated (you have to verify the old signature
against each key with a matching ID if you want to just deal with the signatures
from a particular key or just re-sign with all keys with the same key id). Your
key store also needs to be able to handle collisions.
Mark
Peace,
To try to make a more in-depth example:
At the moment, .COM/.NET is relying on GTLD-SERVERS.NET for the authoritative DNS.
GTLD-SERVERS.NET is currently relying on NSTLD.COM for the authoritative DNS.
With this example, you are asking why neither GTLD-SERVERS.NET nor NSTLD.COM has been DNSSEC signed?
In that case, I would probably be extending that a bit, considering a lot of critical resources out there (even if announced as IPv6 /48 and IPv4 /24) still do not have any RPKI ROA, at all.
(But maybe that's just me...)
darkdevil@darkdevil.dk writes:
With this example, you are asking why neither GTLD-SERVERS.NET nor
NSTLD.COM has been DNSSEC signed?
That's a good point. Yes, I guess I do.
I'm sure there is a good reason for all these examples. I just need to
have it fed with a tiny spoon 
Bjørn
Peace,
Given “MUST NOT” is not in RFC 4034, Appendix B, I’d take this with a grain
of salt."Implementations MUST NOT assume that the key tag uniquely identifies a DNSKEY RR."
Missed that in my re-reading.
Why do they put their DNS servers in an unsigned zone?
To try to make a more in-depth example:
At the moment, .COM/.NET is relying on GTLD-SERVERS.NET for the authoritative DNS.
GTLD-SERVERS.NET is currently relying on NSTLD.COM for the authoritative DNS.
With this example, you are asking why neither GTLD-SERVERS.NET nor NSTLD.COM has been DNSSEC signed?
In that case, I would probably be extending that a bit, considering a lot of critical resources out there (even if announced as IPv6 /48 and IPv4 /24) still do not have any RPKI ROA, at all.
(But maybe that's just me...)
The NS records in a delegation are NOT SIGNED. The glue addresses in a referral are NOT SIGNED.
Resolvers use those. They should get back signed answers from signed zones which are verifiable.
If they get back unsigned answers for signed zones they will be rejected. It they get back unsigned
answers from an unsigned zone then all bets are off. DNSSEC sign your zones if you are worried
about that. There is potential for information leakage with this strategy, but not wrong answers
being returned from signed zones. Signing the zones would help a little with the information
leakage when the servers are not learnt by glue. It is impossible to prevent all information
leakage even if all zones, delgations and glue was signed.
Why do they put their DNS servers in an unsigned zone?
To try to make a more in-depth example:
At the moment, .COM/.NET is relying on GTLD-SERVERS.NET for the authoritative DNS.
GTLD-SERVERS.NET is currently relying on NSTLD.COM for the authoritative DNS.
With this example, you are asking why neither GTLD-SERVERS.NET nor NSTLD.COM has been DNSSEC signed?
In that case, I would probably be extending that a bit, considering a lot of critical resources out there (even if announced as IPv6 /48 and IPv4 /24) still do not have any RPKI ROA, at all.
(But maybe that’s just me…)
The NS records in a delegation are NOT SIGNED. The glue addresses in a referral are NOT SIGNED.
For taking care of referrals and delegations, ietf has started preliminary work. More info here -
https://mailarchive.ietf.org/arch/msg/dd/srNtevzS-jrPzMxYv1nATCY5JkM/
For taking care of referrals and delegations, ietf has started
preliminary work. More info here -
dns is not complex enough that folk have assured careers. need to make
it more complex.
randy