Re: ru tld down?
> 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
Re: ru tld down?
> On 09-Feb-2024, at 02:03, ma...@isc.org wrote: > > > >> On 9 Feb 2024, at 03:10, darkde...@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: ma...@isc.org >
Re: ru tld down?
> On 9 Feb 2024, at 03:10, darkde...@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: ma...@isc.org
Re: ru tld down?
> On 8 Feb 2024, at 17:17, Töma Gavrichenkov wrote: > > Peace, > > On Thu, 8 Feb 2024, 6:39 am Mark Andrews, 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: ma...@isc.org
Re: ru tld down?
darkde...@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
Re: ru tld down?
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
Re: ru tld down?
Peace, On Thu, 8 Feb 2024, 6:39 am Mark Andrews, 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." -- Töma >
Re: ru tld down?
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 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, wrote: > >>> On Tue, Jan 30, 2024 at 8:11 AM Bill Woodcock 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 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 > > Subject: Re: [dns-operations] .RU zone failed ZSK rotation > > Date: January 31, 2024 at 03:34:40 GMT+1 > > To: Sergey Myasoedov > > Cc: dns-operati...@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: ma...@isc.org
Re: ru tld down?
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, wrote: > >>> On Tue, Jan 30, 2024 at 8:11 AM Bill Woodcock 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 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 > > Subject: Re: [dns-operations] .RU zone failed ZSK rotation > > Date: January 31, 2024 at 03:34:40 GMT+1 > > To: Sergey Myasoedov > > Cc: dns-operati...@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 > >
Re: ru tld down?
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
Re: ru tld down?
>>> On Tue, Jan 30, 2024 at 8:11 AM Bill Woodcock 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 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 > Subject: Re: [dns-operations] .RU zone failed ZSK rotation > Date: January 31, 2024 at 03:34:40 GMT+1 > To: Sergey Myasoedov > Cc: dns-operati...@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 signature.asc Description: Message signed with OpenPGP
Re: ru tld down?
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?=russia+internet+disconnection+test On Tue, Jan 30, 2024 at 8:11 AM Bill Woodcock wrote: > > > > On Jan 30, 2024, at 17:00, Dmitry Sherman wrote: > > > > ru tld down? > > Not exactly down… they just busted their DNSSEC, or their domain got > hijacked or something. Bad DNSKEY records. > > -Bill > >
Re: ru tld down?
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 wrote: > > > >> On Jan 30, 2024, at 17:00, Dmitry Sherman wrote: >> >> ru tld down? > > Not exactly down… they just busted their DNSSEC, or their domain got > hijacked or something. Bad DNSKEY records. > >-Bill >
Re: ru tld down?
>> On Jan 30, 2024, at 17:00, Dmitry Sherman 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 signature.asc Description: Message signed with OpenPGP
Re: ru tld down?
does this impact microsoft copilot in EU from being accessed? Sent via BT Email App From: Bill Woodcock Sent: 30 January 2024 16:10:49 GMT To: Dmitry Sherman Cc: nanog@nanog.org Subject: Re: ru tld down? On Jan 30, 2024, at 17:00, Dmitry Sherman wrote: ru tld down? Not exactly down… they just busted their DNSSEC, or their domain got hijacked or something. Bad DNSKEY records. -Bill
Re: ru tld down?
> On Jan 30, 2024, at 17:00, Dmitry Sherman wrote: > > ru tld down? Not exactly down… they just busted their DNSSEC, or their domain got hijacked or something. Bad DNSKEY records. -Bill signature.asc Description: Message signed with OpenPGP
ru tld down?
ru tld down?
