July 2016 - dns-wg - mailman.ripe.net

Plan documents for root KSK roll project now available
by Matt Larson 26 Jul '16

26 Jul '16

On Friday, July 22, in the interests of transparency and to notify the DNS operational community, ICANN posted plans <https://www.icann.org/resources/pages/ksk-rollover#operational-plans> to roll the root zone key signing key (KSK). These plans were developed by the Root Zone Management Partners: ICANN in its role as the IANA Functions Operator, Verisign acting as the Root Zone Maintainer, and the U.S. Department of Commerce's National Telecommunications and Information Administration (NTIA) as the Root Zone Administrator. The plans incorporate the March 2016 recommendations <https://www.iana.org/reports/2016/root-ksk-rollover-design-20160307.pdf> of the Root Zone KSK Rollover Design Team, after it sought and considered public comment <https://www.icann.org/news/announcement-2013-03-08-en> on a proposed rollover process. The process of creating a new key, using it to sign the root DNSKEY RRset and securely destroying the old key will start in Q4 2016 and last until Q3 2018, though the portions resulting in visible changes in DNS occur between Q3 2017 and Q1 2018. The important milestones in the project are: - October 26, 2016: The new KSK is generated in ICANN's U.S. East Coast key management facility (KMF). - February, 2017: The new KSK is copied to ICANN's U.S. West Coast KMF and is considered operationally ready, and ICANN publishes the new key at https://data.iana.org/root-anchors/root-anchors.xml <https://data.iana.org/root-anchors/root-anchors.xml>. (The exact date is dependent on the timing of the Q1 2017 key ceremony, which has not yet been scheduled.) - July 11, 2017: The new KSK appears in the root DNSKEY RRset for the first time. - October 11, 2017: The new KSK signs the root DNSKEY RRset (and the old KSK no longer signs). This date is the actual KSK rollover. - January 11, 2018: The old KSK is published as revoked (per RFC 5011, "Automated Updates of DNS Security"). What you need to do If you operate any software performing DNSSEC validation (such as a security-aware recursive name server) that implements the RFC 5011 automated trust anchor update protocol and this functionality is enabled, you have no action: your software will notice the new KSK (authenticated by the old KSK) and update its trust anchor store accordingly. If you operate any software performing DNSSEC validation that does not implement RFC 5011 or if you don't use the RFC 5011 protocol, you will need to update your software's trust anchor configuration manually to add the new KSK before October 11, 2017. You can obtain the new KSK in February, 2017, using one of the methods described in the "Trust Anchor Publication" section of 2017 KSK Rollover Operational Implementation Plan <https://www.icann.org/en/system/files/files/ksk-rollover-operational-implem…> (one of the aforementioned recently published plans). If you write, package or distribute software that performs DNSSEC validation and you hard code the root KSK (e.g., in code or configuration files), you should update your software with the new KSK when it becomes available in February, 2017. Staying informed ICANN will post occasional notices to various operational forums to keep the community informed of this project's progress, but we strongly suggest that anyone with an interest subscribe to the root KSK rollover mailing list <https://mm.icann.org/mailman/listinfo/ksk-rollover> operated by ICANN (ksk-rollover(a)icann.org <mailto:ksk-rollover@icann.org>). The list is extremely low volume. The ICANN staff supporting and implementing the root KSK rollover project welcome your questions and comments: please direct them to the ksk-rollover(a)icann.org <mailto:ksk-rollover@icann.org> list. Matt -- Matt Larson VP of Research Office of the CTO, ICANN

2 1

Request for trusted party to provide secondary DNS services for the RIPE NCC’s zones
by Romeo Zwart 26 Jul '16

26 Jul '16

Dear colleagues, The RIPE NCC requests proposals for service from a DNS service provider in order to improve the resiliency of the RIPE NCC's zones, especially ripe.net. The submission deadline is Sunday, 14 August 2016. For more details please see: https://www.ripe.net/publications/news/announcements/request-for-trusted-pa… Kind regards, Romeo Zwart RIPE NCC

2 4

New on RIPE Labs: DNS Privacy (by Geoff Huston)
by Mirjam Kuehne 18 Jul '16

18 Jul '16

Dear colleagues, Please find this new article on DNS privacy by Geoff Huston on RIPE Labs: https://labs.ripe.net/Members/gih/dns-privacy Kind regards, Mirjam Kuehne RIPE NCC

1 0

New on RIPE Labs: Operator Level DNS Hijacking
by Mirjam Kuehne 11 Jul '16

11 Jul '16

Dear colleagues, Please find a new article by Babak Farrokhi on RIPE Labs: Operator Level DNS Hijacking This is follow-up from Babak's recent research on DNS hijacking. In this new article he is wondering whether this is a common practice among the operators. With the help of RIPE Atlas, he started to think of a solution to figure out whether such practice is widespread in other areas of the world. https://labs.ripe.net/Members/babak_farrokhi/operator-level-dns-redirection… Kind regards, Mirjam Kuehne RIPE Labs

1 0

New on RIPE Labs: Is Your ISP Hijacking Your DNS Traffic?
by Mirjam Kuehne 06 Jul '16

06 Jul '16

Dear colleagues, Please find a new article by Babak Farrokhi on RIPE Labs: Is your ISP Hijacking your DNS Traffic? https://labs.ripe.net/Members/babak_farrokhi/is-your-isp-hijacking-your-dns… Kind regards, Mirjam Kuehne RIPE NCC

7 8

Root DNS incident on June 25
by Romeo Zwart 04 Jul '16

04 Jul '16

Dear colleagues, On June 25, 2016 all of the Internet Domain Name System's root name servers received an unusually high rate of TCP SYN and ICMP traffic. A report that explains the nature and impact of the incident has been published here: http://root-servers.org/news/events-of-20160625.txt Kind regards, Romeo Zwart

2 1