- dns-wg - mailman.ripe.net

New on RIPE Labs: A Software-based Approach to Identify Heavy Hitters in DNS Traffic
by Mirjam Kuehne 25 Oct '17

25 Oct '17

Dear colleagues, Please find this new article on RIPE Labs, contributed by Santiago Ruano Rincon, one of the RACI fellows from RIPE 74: A Software-based Approach to Identify Heavy Hitters in DNS Traffic This article presents a software-based prototype able to estimate the most queried domain names in a stream of DNS traffic at 12Mpps (wire-rate 10GbE). The goal is to identify domains involved in random qname attacks. This prototype is a proof-of-concept of our research on software and commodity-hardware approaches to analyse high-speed network streams. https://labs.ripe.net/Members/santiago_r_r_/a-software-based-approach-to-id… Kind regards, Mirjam Kuhne RIPE NCC

1 0

New on RIPE Labs: The Future of DNSSEC at the RIPE NCC
by Mirjam Kuehne 24 Oct '17

24 Oct '17

Dear colleagues, DNSSEC signing solutions and products have evolved greatly since we first began signing our zones. We are now exploring ways of doing it better and smarter. Please read about our plans on RIPE Labs: https://labs.ripe.net/Members/anandb/the-future-of-dnssec-at-the-ripe-ncc Anand will present this during the DNS WG session at RIPE 75. Kind regards, Mirjam Kuhne RIPE NCC

1 0

Draft minutes from the DNS working group at RIPE 74
by Shane Kerr 23 Oct '17

23 Oct '17

DNS Colleagues, Draft minutes from the DNS working group at RIPE 74 are available here: https://www.ripe.net/participate/ripe/wg/dns/minutes/dns-working-group-minu… Please send any corrections to the DNS working group chairs at <dns-wg-chairs(a)ripe.net>. [ Apologies for the late e-mail notice. These were actually posted by the RIPE NCC on 2017-06-20, but I did not send this to the list. :( ] Cheers, -- Shane

1 0

f.root-servers.net problem - UA-IX exchange point
by Сергій Співак 22 Oct '17

22 Oct '17

Hello, There is a problem with a F root-server node connected to UA-IX traffic exchange point (ix.net.ua, AS15645) since October, 14. IP 192.5.5.241 is unreachable from our AS48438 since this date. Troubleshooting of this problem shows trace broken at: 5 2 ms 2 ms 1 ms kbp1b.f.root-servers.ix.net.ua [195.35.65.250] 6 2 ms 1 ms 1 ms iana.r1.kbp1.isc.org [192.228.86.1] 7 * * * Request timed out. 8 * * * Request timed out. IP 192.5.5.241 is also unreachable from UA-IX looking glass ( http://lg.ix.net.ua/ ): Command: ping ipv4 Parameter: 192.5.5.241 ________________________________ Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.5.5.241, timeout is 2 seconds: ...U. Success rate is 0 percent (0/5) The route for 192.5.5.0/24 is present in routing database ( http://lg.ix.net.ua/ ): Command: show ipv4 bgp Parameter: 192.5.5.0/24 ________________________________ BGP routing table entry for 192.5.5.0/24, version 47209171 BGP Bestpath: deterministic-med: cost-community-ignore Paths: (2 available, best #1, table default) Advertised to update-groups: 73 74 76 194 231 233 Refresh Epoch 1 30128 3557, (aggregated by 30128 192.228.86.16) 185.1.50.250 from 185.1.50.250 (192.228.86.17) Origin IGP, metric 2, localpref 100, valid, external, atomic-aggregate, best Community: 3557:10 15645:5 rx pathid: 0, tx pathid: 0x0 Refresh Epoch 1 30128 3557, (aggregated by 30128 192.228.86.16) 185.1.50.248 from 185.1.50.248 (192.228.86.16) Origin IGP, metric 12, localpref 100, valid, external, atomic-aggregate Community: 15645:5 rx pathid: 0, tx pathid: 0 Please fix it. Thanks. -- Best wishes, Sergii Spivak www.corbina.com.ua

3 2

Decommissioned anchors replaced in DNSMON
by Chris Amin 17 Oct '17

17 Oct '17

Dear colleagues, You may noticed that the number of anchors actively participating in DNSMON had recently decreased somewhat. This is because they were version 1 anchors that had been decommissioned. In most cases, these anchors have since been upgraded to version 3 anchors. We have now added those replacements anchors to the DNSMON set, so you will notice new lines in the DNSMON graph on the probe view, and aggregated values of the server view will be affected slightly. For more information on version 3 anchors, see: https://labs.ripe.net/Members/alun_davies/introducing-ripe-atlas-v3-anchors Kind regards, Chris Amin RIPE NCC

1 0

Fwd: ISC Operational Notification re: root-zone trust-anchors
by Ray Bellis 28 Sep '17

28 Sep '17

FYI, for those running BIND but not subscribed to bind-announce: -------- Forwarded Message -------- Subject: Operational Notification: KSK-2010 will be retired from the root zone, potentially affecting validating resolvers Date: Thu, 28 Sep 2017 13:10:18 -0800 From: Michael McNally <mcnally(a)isc.org> To: bind-announce(a)lists.isc.org To all BIND server operators -- Many of you may already be aware of yesterday's announcement from ICANN concerning the postponement of one of the steps in the currently-in-progress root zone KSK rollover. https://www.icann.org/news/announcement-2017-09-27-en Specifically, they have announced that the 11 October 2017 date that was planned for the retirement of KSK-2010 will be postponed for at least three months because root zone trust anchor telemetry data sent by servers running BIND and other DNS server software indicates that many operators are still unprepared for the change and using soon-to-be-retired trust anchors. To help our users be sure that they are prepared for the transition when it occurs we have prepared an Operational Notification concerning the KSK rollover: https://kb.isc.org/article/AA-01529/169/KSK-2010-Rollover.html If you are operating a server which performs DNSSEC validation we suggest that you take a few moments to read the notification and follow its suggestions to ensure that you are prepared when ICANN resume the root KSK rollover. Michael McNally ISC Security Officer

1 0

KSK Rollover Postponed
by Janos Zsako 28 Sep '17

28 Sep '17

Dear all, https://www.icann.org/news/announcement-2017-09-27-en Strange enough, I did not see any mail/announcement about this on this list. I suppose not everybody on this list was aware. I hope we can hear some background information at RIPE 75. Best regards, Janos

8 9

Root KSK roll delayed
by Matt Larson 28 Sep '17

28 Sep '17

Dear colleagues, I'm forwarding a message I just posted to dns-operations(a)dns-oarc.net announcing the postponement of the root KSK roll. Please excuse the posting from my personal email address: that's how I'm subscribed to this list and the only way to post in a timely fashion. As you can imagine, it's been a very busy past few days. We always intended to update all the relevant operational lists and are doing so now. Matt > Begin forwarded message: > > From: Matt Larson <matt.larson(a)icann.org> > Subject: Root KSK roll delayed > Date: September 28, 2017 at 9:47:14 AM PDT > To: dns-operations <dns-operations(a)dns-oarc.net> > > ICANN has decided to postpone the root KSK roll previously scheduled for 11 October 2017 for at least one quarter. This message gives some background and explanation for that decision. > > Historically there has been no way to determine which trust anchors DNSSEC validators have configured, making it difficult to assess the potential impact of the root KSK rollover. "Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)" (defined in RFC 8145) is a recent protocol extension that allows a validator to report which trust anchors it has configured for a zone to that zone's name servers. The protocol was only finalized in April, 2017, and only the most recent versions of BIND (9.10.5b1 and 9.11.0b3 and later) and Unbound (1.6.4 and later) support it. This protocol was not expected to have sufficient deployment to provide useful information for the first root KSK rollover. > > However, initial research by Verisign and then by ICANN has found a growing number of validators reporting trust anchor configuration to the root servers. Based on data from six root server addresses, approximately 12,000 unique source IP addresses have sent trust anchor configuration reports so far in September 2017. The number reporting is growing and now approaches 1400 unique addresses per day. Significantly, approximately 5% of the total validators and about 6%-8% on any given day report only KSK-2010, the root zone KSK currently signing the root's DNSKEY RRset. These validators would not resolve correctly after the planned root KSK roll. > > There are various reasons a validator might report only KSK-2010. One reason is an old configuration with a statically configured trust anchor (e.g., BIND's "trusted-key" statement). ICANN has always known that a small percentage of validators would not be ready for the rollover because they had manually configured their trust anchor, and that operators of those validators would need to take action when the root KSK rollover happened. > > Another reason is a failure to automatically update the trust anchor using the RFC 5011 automated update protocol because of a software defect, operator error or other reason. Based on our research and preliminary investigation, we also believe it is possible that some operators believe that they are ready for the rollover because they configured their validator to use RFC 5011 automated updates, but will not trust KSK-2017 when the rollover happens due to configuration issues or software defects. > > Given the relatively high percentage of validators with just KSK-2010, ICANN believes it is important to better understand the reasons before proceeding with the root KSK roll. We will soon be publishing the list of resolvers reporting only KSK-2010 and will ask for the operational community's help in identifying, diagnosing and correcting these systems. > > Throughout the project we have emphasized that the root KSK is being rolled under normal operational conditions and have proceeded cautiously and without haste. The decision to postpone was taken in that spirit of caution because there is no operational pressure to proceed given our continued confidence in the security of KSK-2010. > > We appreciate the community's understanding and we look forward to your assistance in gathering the information necessary to move forward with the root KSK roll. > > Matt > -- > Matt Larson, VP of Research > ICANN Office of the CTO >

1 0

RIPE 75 DNS WG Agenda
by Dave Knight 11 Sep '17

11 Sep '17

Colleagues, Here’s the agenda for the DNS Working Group session at the RIPE 75 meeting in Dubai. Kind regards, dave On behalf of the DNS Working Group chairs RIPE 75 DNS Working Group Agenda Wednesday 25th October 2017, 14:00-15:30 A. Administrivia - Agenda bashing - Review of action items - Approval of previous minutes - Selection of new co-chair B. RIPE NCC Report Anand Bhuddhev C. CDNSKEY implementation with automated KSK rollover in Knot DNS and the FRED registry Jaromir Talir D. Living on the Edge: (Re)focus DNS Efforts on the End-points Benno Overeinder E. Why DNS should be the naming service for the Internet of things Sandoche Balakrichenan F. Any other business

1 0

Changes to RIPE NCC's zonelet repository
by Anand Buddhdev 05 Sep '17

05 Sep '17

Dear colleagues, The RIPE NCC publishes DNS zonelets at the following URL: ftp://ftp.ripe.net/pub/zones The other RIRs fetch these zonelets to merge their content into the zones they operate. All zonelet files are published with canonical filenames, eg. 1.in-addr.arpa-RIPE. Additionally, for the IPv4 reverse DNS zones, we have been publishing symbolic links with legacy names (eg. 001-RIPE) that point to the canonical names, because old provisioning software at all the RIRs relied on the legacy names. However, this is no longer necessary. Therefore, on August 22 2017, we will stop publishing these legacy files, and all the zonelets will be published only with their canonical names. Regards, Anand Buddhdev RIPE NCC

1 2