- dns-wg - mailman.ripe.net

New on RIPE Labs: A Tale of using Public DNS Servers in Iran - Part 1
by Mirjam Kuehne 16 Feb '16

16 Feb '16

Dear colleagues, Please find a new article on RIPE Labs, contributed by Babak Farrokhi: A Tale of using Public DNS Servers in Iran. This is part 1 of a short series of articles that will be continued next week: https://labs.ripe.net/Members/babak_farrokhi/tale-of-using-public-dns-serve… Kind regards, Mirjam Kuehne RIPE NCC

1 2

Follow up article on K-root events of 30 November and 1 December 2015
by Romeo Zwart 04 Feb '16

04 Feb '16

Dear colleagues, On 30 November and 1 December 2015, we observed unusually large amounts of traffic on the K-root DNS servers, which we announced here: https://www.ripe.net/ripe/mail/archives/dns-wg/2015-November/003173.html Some other root server operators observed similar traffic during the same period, as described here: http://root-servers.org/news/events-of-20151130.txt We have since written a follow-up report that provides some more details about these incidents. The report also covers some of the “lessons learned” for the DNS team. The report is now online here: https://labs.ripe.net/Members/romeo_zwart/report-on-the-traffic-load-event-… Kind regards, Romeo

2 1

New on RIPE Labs: DNS at FOSDEM 2016
by Mirjam Kuehne 03 Feb '16

03 Feb '16

Dear colleagues, Shane Kerr attended FOSDEM, the Free and Open-Source Developers European Meeting last weekend, and wrote up a few observations around DNS. Please see on RIPE Labs: https://labs.ripe.net/Members/shane/dns-at-fosdem-2016 Kind regards, Mirjam Kuehne RIPE NCC

1 0

Call for presentations RIPE 72
by Benno Overeinder 25 Jan '16

25 Jan '16

Dear colleagues, Please find the CFP for RIPE 72 below or at https://ripe72.ripe.net/submit-topic/cfp/. The deadline for submissions is 13 March 2016. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. Kind regards, Benno Overeinder RIPE PC Chair https://www.ripe.net/participate/meetings/ripe-meetings/pc -------------------->>><<<-------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 72 will take place from 23-27 May 2016 in Copenhagen, Denmark. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 72. See the full descriptions of the different presentation formats, https://ripe72.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 13 March 2016. Proposals submitted after this date will be considered depending on the remaining available space in the programme. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity in operations - Commercial transactions of IPv4 addresses - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour - Lightning talks: 10 minutes The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe72.ripe.net/submit-topic/submission-form/. - Lightning talks should also be submitted using the meeting submission system (https://ripe72.ripe.net/submit-topic/submission-form/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice---in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. - Due to potential technical issues, presenters/panellists should be physically present at the RIPE Meeting. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/

1 0

Another attack against RIPE Authoritative DNS services
by Romeo Zwart 16 Jan '16

16 Jan '16

Dear colleagues, This evening, 16 January, between 20:45 UTC and 21:05 UTC, we again received an unusually large amount of incoming traffic on the servers for the RIPE Authoritative DNS services. The volume of traffic was overflowing our inbound connections. It will be clear that this has severely impacted our Authoritive DNS services while the attack was ongoing. This attack was quite similar to the incident we had earlier this week. However, an important difference was that this time the attack traffic was directed at the RIPE NCC DNS services directly. As mentioned in an earlier announcement, we are investigating potential improvements to our infrastructure to increase our mitigation capabilities in case of future incidents. Kind regards, Romeo Zwart

1 0

RIPE Authoritative DNS services degraded
by Romeo Zwart 15 Jan '16

15 Jan '16

Dear colleagues, As of approximately 11:20 UTC this morning, Thursday 14 January, we are seeing an unusually large amount of incoming traffic on the servers for the RIPE Authoritative DNS services. The traffic is specifically aimed at the ccTLD secondary service that we host for .ps and is of such a high volume that it is impacting other DNS services. We are contacting the domain owners and are investigating mitigation capabilities at the moment. We will inform you further when we have more information. Kind regards, Romeo Zwart

2 2

RIPE NCC Authoritative and Secondary DNS services on Monday 14 December
by Romeo Zwart 11 Jan '16

11 Jan '16

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

6 10

PTR-Queries asking for type A or AAAA
by Max Grobecker 10 Jan '16

10 Jan '16

Hello, today I noticed, that my DNS servers are getting a noticable amount of DNS queries for my IPv4 reverse zone, asking for type A or AAAA. Example with tcpdump: 22:22:06.019962 IP 160.45.8.8.45341 > 172.29.56.218.53: 34558 [1au] A? y.x.144.217.in-addr.arpa. (57) 22:22:06.129485 IP 160.45.41.8.55855 > 172.29.56.218.53: 12449% [1au] A? y.x.144.217.in-addr.arpa. (57) 22:22:12.571720 IP 160.45.113.3.11019 > 172.29.56.218.53: 15364 [1au] AAAA? y.x.144.217.in-addr.arpa. (57) 22:22:13.571228 IP 160.45.41.4.57403 > 172.29.56.218.53: 11276 [1au] AAAA? y.x.144.217.in-addr.arpa. (57) 22:22:14.561769 IP 160.45.113.3.1159 > 172.29.56.218.53: 16591% [1au] AAAA? y.x.144.217.in-addr.arpa. (57) 22:22:17.172626 IP 160.45.8.8.34605 > 172.29.56.218.53: 10352 [1au] AAAA? y.x.144.217.in-addr.arpa. (57) 22:22:17.281042 IP 160.45.41.8.56158 > 172.29.56.218.53: 32812% [1au] AAAA? y.x.144.217.in-addr.arpa. (57) 22:30:09.386217 IP 134.169.34.26.52144 > 172.29.56.218.53: 29463% [1au] AAAA? y.x.144.217.in-addr.arpa. (57) 22:30:09.539619 IP 134.169.34.56.59778 > 172.29.56.218.53: 63208% [1au] AAAA? y.x.144.217.in-addr.arpa. (57) 22:30:09.699493 IP 134.169.34.26.63325 > 172.29.56.218.53: 25399% [1au] A? y.x.144.217.in-addr.arpa. (57) 22:30:09.859583 IP 134.169.34.56.41423 > 172.29.56.218.53: 23848% [1au] A? y.x.144.217.in-addr.arpa. (57) 22:30:19.200884 IP 139.17.128.10.65059 > 172.29.56.218.53: 37206 [1au] AAAA? y.x.144.217.in-addr.arpa. (57) 22:30:20.694596 IP 213.136.95.10.42215 > 172.29.56.218.53: 13396% [1au] A? y.x.144.217.in-addr.arpa. (57) The top queries are for the IP address of my NTP pool server, the other one is for the IP of my primary DNS server. These are originating from several IP addresses, sometimes also Google DNS and DNS resolvers of universities. I've never suffered any problems with my PTR zone and there are enough legitimate queries to prove me that the zone is working as it should... Is this "normal background noise" or could that be caused by a malformed DNS zone? Or is anyone else seeing those weird queries? Thanks! Greetings from Wuppertal Max

4 3

Meanwhile, at ICANN...
by Shane Kerr 06 Jan '16

06 Jan '16

All, Not necessarily RIPE Database related, but I thought I'd point out that ICANN is considering replacing WHOIS for gTLD: https://www.icann.org/news/announcement-2016-01-04-en Cheers, -- Shane

3 2

Algorithm Upgrade for RIPE NCC DNS Zones
by Anand Buddhdev 21 Dec '15

21 Dec '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear colleagues, All the zones maintained by the RIPE NCC are signed with the RSA/SHA1 algorithm. At the RIPE 70 meeting we committed to upgrade the algorithm of all our zones. We required an updated version of our signer software that could sign a zone with two different algorithms at the same time. We then needed to test it, to ensure that we could switch algorithms without causing major validation errors. We published a RIPE Labs article about our experiences here: https://labs.ripe.net/Members/anandb/dnssec-algorithm-roll-over We are happy to announce that we are now ready to roll the keys of all our zones and sign them with the RSA/SHA256 algorithm. We will follow the process described in the RIPE Labs article. We plan to begin the roll-over on Monday, 30 November 2015. We would still like to exercise caution, so we will not roll the keys of all zones at the same time. We will do this in batches, starting with a small number of reverse DNS zones of the RIPE Meeting address space. If you have any questions, please send an email to <dns(a)ripe.net>. Regards, Anand Buddhdev RIPE NCC -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWVuZ8AAoJEBXgoyUMySoFoHYP+weE0kP6hkbeRJLDO610v612 ZyE81BkNQs6LE/lufAyMLkA36b3J9mVvDcmc2ciuRWdFLef3Z4XD2X+BG0mAAJgM cy4nD7Hx+6m9h3nGGT62CJTneXXNMyqzozcQIDdEyau8qUVM91/SgDFgBJWmnMML JC34hXWb5au5S+Bus/Vaq4iMtROQAq3F6xXR4xiEQoU+XwbOLkWU6WjqwCaJfYZ5 UBaQtpdcqNOjKXyVlDoF6LJnxgxW3kXMi98FEQ8Ye0oYri/h98gdt6BWYfhf5kTY aU7RTAJ2V0ksOVmipSQIT5KkrmV3mwOiuAWjVJYaVJWxmYoHdyMlhtHpUJT4LV1P KvN/XXSZdjBawCNib8zjFFXb79cFRBZ8PMm55W5pcwYNipAK71mlmhEIop8PX3ee oYwU1MzxNoREP3zYWWgolJhhzJsGpZP1ceRJwI4pKQpz4xFju0tJHBQAHICI8Z1R yinf2H0rYPKKyaBNt9aYB/LsTGdh+ccIl4o4/Ep4sc102cemT11mf4QYCeYUIjZW wULcgf4L7d8m3NCa33i5zX44TlQ7xTjdW4m60auSdaRjlUsLTewYkAkrhC5G+aZP oA4RYJVwi0dSbw62S03+MN2senWgSfZe85jqgMX24u/W7XNp59va9wA8nPVJVPl/ XbAQ69qXXKbldMdI4CI2 =/Pwl -----END PGP SIGNATURE-----

2 3