[dns-wg] RIPE NCC Authoritative and Secondary DNS services on Monday 14 December

Same question as for the root incident - would you be willing to share
more information OTR with software implementors (such as well, me)?
Pinky swear that I'm not the perpetrator.

Best,
Marek

On 15 December 2015 at 18:48, Romeo Zwart <romeo.zwart at ripe.net> wrote:
> Hi Brett,
>
> On 15/12/15 18:25 , Brett Carr wrote:
>> Thanks for the information Romeo I wonder if perhaps you would consider doing a presentation at the next WG meeting on the issues you encountered and mitigation techniques you used.
>
> We will consider it. As you will understand, and will have noticed in
> our communication about this, we are trying to balance providing
> operationally relevant information about the event with a desire to not
> aid in designing any future events. So the information we give will
> likely be unsatisfactory for many people in the technical audience we
> have here.
>
> However, we might be able to present more information in a somewhat
> generalised way that is still useful to the community. As said, we will
> consider it.
>
> Regards,
> Romeo
>
>
>
>> Thanks
>>
>> Brett
>>
>> --
>> Brett Carr
>> Senior DNS Engineer
>> Nominet UK
>>
>>> On 15 Dec 2015, at 12:35, Romeo Zwart <romeo.zwart at ripe.net> wrote:
>>>
>>> Dear colleagues,
>>>
>>> Yesterday, Monday 14 December 2015, RIPE NCC Authoritative DNS services
>>> were functioning in a severely degraded state during parts of the day.
>>>
>>> This was due to an attack on one of the ccTLDs for which the NCC hosts a
>>> secondary DNS service. The attack traffic started around 08:00 UTC. RIPE
>>> NCC staff applied various countermeasures during the day. These
>>> mitigations were effective for some time. However, after implementing
>>> each of these mitigations, the traffic patterns were modified to evade
>>> them. Towards the end of the day, the volume of the attack traffic
>>> targeted at our servers had increased to such a level that it was
>>> overloading our incoming links and our mitigation measures were no
>>> longer sufficiently effective.
>>>
>>> At that time we were forced to contact our upstream peers to assist us
>>> with mitigation measures. Apart from the ccTLD service for the attacked
>>> domain, normal services were restored at around 18:30 UTC.
>>>
>>> The attack is ongoing, and we continue with mitigation measures in order
>>> to provide the best service possible under the circumstances.
>>>
>>> We note that attacks like this rely on spoofing source addresses in the
>>> attack packets. Therefore, Source Address Validation and BCP-38 should
>>> be used wherever possible to reduce the ability to abuse networks to
>>> transmit spoofed source packets.
>>>
>>> Kind regards,
>>> Romeo Zwart
>>>
>>
>>
>
>