https://dnsviz.net/d/ru/ZbjruA/dnssec/ https://dnsviz.net/d/ru/ZbkVXw/dnssec/ Obviously ZSK rotation failed.
On 30. 1. 2024, at 10:10, Bill Woodcock <woody@pch.net> wrote:
On Jan 30, 2024, at 17:00, Dmitry Sherman <dmitry@interhost.net> wrote:
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? Sent via BT Email App From: Bill Woodcock <woody@pch.net> Sent: 30 January 2024 16:10:49 GMT To: Dmitry Sherman <dmitry@interhost.net> Cc: nanog@nanog.org <nanog@nanog.org> Subject: Re: ru tld down? On Jan 30, 2024, at 17:00, Dmitry Sherman <dmitry@interhost.net> wrote: ru tld down? Not exactly down… they just busted their DNSSEC, or their domain got hijacked or something. Bad DNSKEY records. -Bill
On Jan 30, 2024, at 17:00, Dmitry Sherman <dmitry@interhost.net> wrote:
ru tld down?
Not exactly down… they just busted their DNSSEC, or their domain got hijacked or something. Bad DNSKEY records.
-Bill
Flash | Users across Russia report widespread access issues to [.] ru domains, including of Yandex, Megafon, and Sberbank: Local News Outlet via Forbes Russia. — Rabbi Rob Thomas Team Cymru "It is easy to believe in freedom of speech for those with whom we agree.” - Leo McKern
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 On Tue, Jan 30, 2024 at 8:11 AM Bill Woodcock <woody@pch.net> wrote:
On Jan 30, 2024, at 17:00, Dmitry Sherman <dmitry@interhost.net> wrote:
ru tld down?
Not exactly down… they just busted their DNSSEC, or their domain got hijacked or something. Bad DNSKEY records.
-Bill
On Tue, Jan 30, 2024 at 8:11 AM Bill Woodcock <woody@pch.net> wrote: Not exactly down… they just busted their DNSSEC, or their domain got hijacked or something. Bad DNSKEY records.
On Jan 31, 2024, at 06:34, Eric Kuhnke <eric.kuhnke@gmail.com> wrote: 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:
Begin forwarded message:
From: Phil Kulin <schors@gmail.com> Subject: Re: [dns-operations] .RU zone failed ZSK rotation Date: January 31, 2024 at 03:34:40 GMT+1 To: Sergey Myasoedov <s@netartgroup.com> Cc: dns-operations@lists.dns-oarc.net
Timeline: 2024-01-30 12:29:44 UTC: Last correct answer before outage (SOA SN: 4058855): https://dnsviz.net/d/ru/ZbjruA/dnssec/ 2024-01-30 15:27:27 UTC: First bad answer (SOA SN: 4058857): https://dnsviz.net/d/ru/ZbkVXw/dnssec/ 2024-01-30 17:27:35 UTC: Resigning attempt (SOA SN: 4058857 and 4058858): https://dnsviz.net/d/ru/Zbkxhw/dnssec/ 2024-01-30 17:59:46 UTC: Recovering process started (SOA SN: 4058857 and 4058857 and 4058858): https://dnsviz.net/d/ru/Zbk5Eg/dnssec/ 2024-01-30 19:07:29 UTC: First completely good answer (SOA SN: 4058856): https://dnsviz.net/d/ru/ZblI8Q/dnssec/
There’s no reason to think that any external parties influenced this. Ockham’s razor. So many euphemisms suggest themselves in a situation like this… Own-goal, one-car-accident, etc. Except that we all know that one small thing overlooked and we’ll be in their shoes tomorrow. All geopolitics aside, my empathy to the .RU operator. -Bill
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
Den 31-01-2024 kl. 20:47 skrev Bjørn Mork:
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...) -- Med venlig hilsen / Kind regards, Arne Jensen
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
On 9 Feb 2024, at 03:10, darkdevil@darkdevil.dk wrote:
Den 31-01-2024 kl. 20:47 skrev Bjørn Mork:
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.
-- Med venlig hilsen / Kind regards, Arne Jensen
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 09-Feb-2024, at 02:03, marka@isc.org wrote:
On 9 Feb 2024, at 03:10, darkdevil@darkdevil.dk wrote:
Den 31-01-2024 kl. 20:47 skrev Bjørn Mork: 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/
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.
-- Med venlig hilsen / Kind regards, Arne Jensen
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
For taking care of referrals and delegations, ietf has started preliminary work. More info here -
https://mailarchive.ietf.org/arch/msg/dd/srNtevzS-jrPzMxYv1nATCY5JkM/
dns is not complex enough that folk have assured careers. need to make it more complex. randy
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. -- Töma On Wed, 31 Jan 2024, 9:59 am Bill Woodcock, <woody@pch.net> wrote:
On Tue, Jan 30, 2024 at 8:11 AM Bill Woodcock <woody@pch.net> wrote: Not exactly down… they just busted their DNSSEC, or their domain got hijacked or something. Bad DNSKEY records.
On Jan 31, 2024, at 06:34, Eric Kuhnke <eric.kuhnke@gmail.com> wrote: 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:
Begin forwarded message:
From: Phil Kulin <schors@gmail.com> Subject: Re: [dns-operations] .RU zone failed ZSK rotation Date: January 31, 2024 at 03:34:40 GMT+1 To: Sergey Myasoedov <s@netartgroup.com> Cc: dns-operations@lists.dns-oarc.net
Timeline: 2024-01-30 12:29:44 UTC: Last correct answer before outage (SOA SN: 4058855): https://dnsviz.net/d/ru/ZbjruA/dnssec/ 2024-01-30 15:27:27 UTC: First bad answer (SOA SN: 4058857): https://dnsviz.net/d/ru/ZbkVXw/dnssec/ 2024-01-30 17:27:35 UTC: Resigning attempt (SOA SN: 4058857 and 4058858): https://dnsviz.net/d/ru/Zbkxhw/dnssec/ 2024-01-30 17:59:46 UTC: Recovering process started (SOA SN: 4058857 and 4058857 and 4058858): https://dnsviz.net/d/ru/Zbk5Eg/dnssec/ 2024-01-30 19:07:29 UTC: First completely good answer (SOA SN: 4058856): https://dnsviz.net/d/ru/ZblI8Q/dnssec/
There’s no reason to think that any external parties influenced this. Ockham’s razor.
So many euphemisms suggest themselves in a situation like this… Own-goal, one-car-accident, etc. Except that we all know that one small thing overlooked and we’ll be in their shoes tomorrow. All geopolitics aside, my empathy to the .RU operator.
-Bill
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
On 8 Feb 2024, at 05:58, Töma Gavrichenkov <ximaera@gmail.com> wrote:
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.
-- Töma
On Wed, 31 Jan 2024, 9:59 am Bill Woodcock, <woody@pch.net> wrote:
On Tue, Jan 30, 2024 at 8:11 AM Bill Woodcock <woody@pch.net> wrote: Not exactly down… they just busted their DNSSEC, or their domain got hijacked or something. Bad DNSKEY records.
On Jan 31, 2024, at 06:34, Eric Kuhnke <eric.kuhnke@gmail.com> wrote: 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:
Begin forwarded message:
From: Phil Kulin <schors@gmail.com> Subject: Re: [dns-operations] .RU zone failed ZSK rotation Date: January 31, 2024 at 03:34:40 GMT+1 To: Sergey Myasoedov <s@netartgroup.com> Cc: dns-operations@lists.dns-oarc.net
Timeline: 2024-01-30 12:29:44 UTC: Last correct answer before outage (SOA SN: 4058855): https://dnsviz.net/d/ru/ZbjruA/dnssec/ 2024-01-30 15:27:27 UTC: First bad answer (SOA SN: 4058857): https://dnsviz.net/d/ru/ZbkVXw/dnssec/ 2024-01-30 17:27:35 UTC: Resigning attempt (SOA SN: 4058857 and 4058858): https://dnsviz.net/d/ru/Zbkxhw/dnssec/ 2024-01-30 17:59:46 UTC: Recovering process started (SOA SN: 4058857 and 4058857 and 4058858): https://dnsviz.net/d/ru/Zbk5Eg/dnssec/ 2024-01-30 19:07:29 UTC: First completely good answer (SOA SN: 4058856): https://dnsviz.net/d/ru/ZblI8Q/dnssec/
There’s no reason to think that any external parties influenced this. Ockham’s razor.
So many euphemisms suggest themselves in a situation like this… Own-goal, one-car-accident, etc. Except that we all know that one small thing overlooked and we’ll be in their shoes tomorrow. All geopolitics aside, my empathy to the .RU operator.
-Bill
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 8 Feb 2024, at 17:17, Töma Gavrichenkov <ximaera@gmail.com> wrote:
Peace,
On Thu, 8 Feb 2024, 6:39 am Mark Andrews, <marka@isc.org> wrote: 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.
-- Töma
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
participants (12)
-
Bill Woodcock -
Bjørn Mork -
darkdevil＠darkdevil.dk -
Dmitry Sherman -
Eric Kuhnke -
Gaurav Kansal -
Mark Andrews -
Rabbi Rob Thomas -
Randy Bush -
Sergey Myasoedov -
touseef.rehman1＠btinternet.com -
Töma Gavrichenkov