Mailing List Archive

> 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

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

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

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

--
Töma

>

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

> 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