- dns-wg - mailman.ripe.net

updates to RIPE-429 about DNSMON services
by Romeo Zwart 17 Nov '15

17 Nov '15

Dear colleagues, We have updated RIPE Document ripe-429, which describes RIPE NCC's DNSMON service. You’ll find the document in PDF format attached to this email. We invite you to share your feedback regarding this document before it is frozen as the updated RIPE document. Thank you for your support. Kind regards, Romeo Zwart

1 0

New on RIPE Labs: Impact of K-root Expansion as Seen by RIPE Atlas
by Mirjam Kuehne 16 Nov '15

16 Nov '15

Dear colleagues, Following-up from the high-level update on the K-root expansion published on RIPE Labs last week, we now look at RIPE Atlas to see what impact this expansion had on performance on both global and regional scales: https://labs.ripe.net/Members/wilhelm/impact-of-new-k-root-anycast-nodes-as… Kind regards, Mirjam Kuehne RIPE NCC

1 0

RIPE NCC secondary name services for ccTLDs
by Romeo Zwart 16 Nov '15

16 Nov '15

Dear colleagues, The RIPE NCC offers a best-effort secondary name service for ccTLDs in the start-up phase of their organisational life. At RIPE 68 you, the working group, provided us with some guidelines regarding the eligibility of new zones to be added to this service. We intend to document these guidelines in the form of a new RIPE Document*, of which a draft version is attached to this email. We welcome any comments you may have on this document. Kind regards, Romeo Zwart * Actually, an earlier version of this document has already been published as a RIPE Document, but this was a procedural error on our part, which will be corrected.

3 2

Advance notice - H-root address change on December 1, 2015
by Kash, Howard M CIV USARMY RDECOM ARL (US) 16 Nov '15

16 Nov '15

This is advance notice that there is a scheduled change to the IP addresses for one of the authorities listed for the DNS root zone and the .ARPA TLD. The change is to H.ROOT-SERVERS.NET, which is administered by the U.S. Army Research Laboratory. The new IPv4 address for this authority is 198.97.190.53. The new IPv6 address for the authority is 2001:500:1::53. This change is anticipated to be implemented in the root zone on 1 December 2015, however the new addresses are operational now. They will replace the previous IP addresses of 128.63.2.53 and 2001:500:1::803f:235 (also previously known as AOS.BRL.MIL and AOS.ARL.ARMY.MIL). We encourage operators of DNS infrastructure to update any references to the old IP addresses and replace them with the new addresses. In particular, many DNS resolvers have a DNS root "hints" file. This should be updated with the new IP addresses. New hints files will be available at the following URLs once the change has been formally executed on December 1: http://www.internic.net/domain/named.root http://www.internic.net/domain/named.cache The old IPv4 address will continue to work for six months after the transition (until 1 June 2016), at which point it will be retired from service. The address will remain under the control of the Army Research Laboratory, never to be used again for DNS service. The old IPv6 address will continue to work indefinitely, but may ultimately be retired from service. Simultaneous to the retirement of the old address on June 1, 2016, the ASN for H-root will change from 13 to 1508. You can monitor the transition of queries to the new addresses at the following URL: http://h.root-servers.org/old_vs_new.html -- Howard Kash U.S. Army Research Laboratory

1 1

Update on K-root expansion
by Romeo Zwart 13 Nov '15

13 Nov '15

Dear colleagues, As you know, we have been expanding coverage of K-root over the course of this year. Since the last announcement in April, we have added 17 new K-root locations, supported by 16 new sponsoring organisations. An update covering the progress of the expansion project so far is now published on RIPE Labs: https://labs.ripe.net/Members/romeo_zwart/update-on-k-root-expansion Kind regards, Romeo Zwart

2 1

Reminder about the WG Chair appointment process
by Jim Reid 13 Nov '15

13 Nov '15

Colleagues, there's still time left to nominate candidates and to express support for those who have been nominated. The response so far from the WG has been disappointing and that's making it awkward to decide if consensus has been reached. Please speak up! Even if it's just to say "meh". :-)

6 6

revised agenda for RIPE71
by Jim Reid 11 Nov '15

11 Nov '15

The agenda for next week's meeting has been updated. Here's the latest version. Please note that things are not finalised and there might be further tweaks to the agenda or running order. # # $Id: agenda,v 1.7 2015/11/11 14:08:51 jim Exp $ # FIRST SESSION A. Usual Administrivia 5 mins Agenda bashing Minutes of previous meeting Review of Action Items B. NCC Report 15 mins Anand Buddhdev C. Measuring the impact of IPv6 resolver preference 20 mins Chris Baker, Dyn D. Impact of DNS over TCP - a resolver point of view 15 mins Joao Damas, Bondis The impact two very different aspects of the life of a recursive server were examined for this project: queries to authoritative servers as well as the queries from stub resolvers. Traffic from two different ISP's recursive resolvers was captured to analyse the potential impact on the servers of long lived TCP sessions, investigating the effect of timeout settings, the total number of simultaneous connections that would be kept open and the potential benefits of connection reuse as proposed in the current version of draft-ietf-dnsop-5966bis, with the intent of offering simulated operational advice, based on observed traffic. E. Integration testing of DNS Recursive servers 15 mins Ondřej Surý, CZ.NIC A generic testing framework was produced as a part of developing the Knot Resolver. This framework is written in python and can use UNIX domain sockets to bypass the underlying physical network. F .nl Open DNS datasets and Statistics 10 mins Marco Davids, SIDN SIDN makes available aggregated datasets from .NL authoritative servers to the Internet/Research/DNS communities. It includes visualizations of the DNS-traffic for .nl, as well as statistics on domain registrations, DNS queries, DNSSEC usage, plus layer-3 and layer-4 information. The datasets (starting from May 2014) are updated on a daily basis. They are provided in JSON-format and can be found on https://stats.sidnlabs.nl. G. Discussion of latest SSAC recommendations 10 mins SSAC Stuckee SECOND SESSION H. Discovery method for a validating stub resolver 20 mins Xavier Gorjón, NLnetLabs This research project aims to develop a discovery method to ensure DNSSEC information can be delivered to the end host. It used RIPE ATLAS to study the current state of DNSSEC aware and DNSSEC validating resolvers, and define a course of action from that information. The project explored a novel method to discover the capabilities of the ISP's recursive resolver and bypass incompetent Customer-premises equipment (CPE) middle-boxes to target the often more capable ISP's resolver directly. I. DNSSEC for Legacy Applications 15 mins Willem Toorop, NLnetLabs Validating stub resolvers are hampered by middle boxes (typically CPE) that corrupt the path from the stub to the recursive resolver. Using the getdns library and the Linux/Unix name resolution framework, libnss_getdns provides (stub-level) DNSSEC validation for legacy applications. This module can work around broken middle boxes by double checking bogus answers. It also offers in-path signalling of DNSSEC failure for http, informing the end-user why validation failed and giving them control of deciding how to deal with that. J. Implementation challenges of geographic split-horizon DNS 20 mins Jan Včelák, CZ.NIC There are multiple ways to find a network service according to a client's geographic location. One possibility is to perform a split-horizon at the DNS level. The presentation will briefly inform about existing approaches, problems introduced by this mechanism, possible solutions of these problems, and experience we gained when implementing this feature into Knot DNS. K. Root Zone KSK rollover 30 mins Roy Arends, IANA L. WG Co-chair appointment 5 mins M. AOB

1 0

New on RIPE Labs: DNSSEC Algorithm Roll-over
by Mirjam Kuehne 06 Nov '15

06 Nov '15

Dear colleagues, Rolling over the algorithm (usually to a stronger variant) used to sign a DNS zone isn't as easy as regular key roll-overs. This is because some DNSSEC validators are less forgiving than others, and fail validation unless the right combination of keys and signatures is present in a zone. This new article on RIPE Labs describes our experiences with DNSSEC algorithm roll-over: https://labs.ripe.net/Members/anandb/dnssec-algorithm-roll-over We hope that our experience will help others who may be considering doing this. Kind regards, Mirjam Kuehne RIPE NCC

1 0

Co-chair nomination
by Joe Abley 23 Oct '15

23 Oct '15

Hi all, I would like to nominate Dave Knight as co-chair of the DNS working group. Dave has had root on more root servers than anybody else in the world, was a driving force for the deployment of DNSSEC in the ORG registry, was part of the team that deployed DNSSEC in the root zone and sits on the board of DNS-OARC and is well-known and active in the RIPE community. In his copious spare time he leads the effort for global deployment of Dyn's DNS platform. Joe

7 6

draft agenda for Bucharest
by Jim Reid 22 Oct '15

22 Oct '15

Colleagues, here's the draft agenda for RIPE71. Please note that this is subject to change, most likely in the running order. A definitive agenda will be circulated in a couple of weeks. I'll remind you all that the WG co-chair appointment process is under way. There's still time for volunteers to come forward. It would be nice to see more statements of support for those who have volunteered too. Hope to see you all in sunny Bucharest next month. # # $Id: agenda,v 1.6 2015/10/21 22:01:47 jim Exp $ # FIRST SESSION A. Usual Administrivia 5 mins Agenda bashing Minutes of previous meeting Review of Action Items B. NCC Report 15 mins Anand Buddhdev C. Measuring the impact of IPv6 resolver preference 20 mins Chris Baker, Dyn D. Impact of DNS over TCP - a resolver point of view 20 mins Joao Damas, Bondis The impact two very different aspects of the life of a recursive server were examined for this project: queries to authoritative servers as well as the queries from stub resolvers. Traffic from two different ISP's recursive resolvers was captured to analyse the potential impact on the servers of long lived TCP sessions, investigating the effect of timeout settings, the total number of simultaneous connections that would be kept open and the potential benefits of connection reuse as proposed in the current version of draft-ietf-dnsop-5966bis, with the intent of offering simulated operational advice, based on observed traffic. E. Integration testing of DNS Recursive servers 15 mins Ondřej Surý, CZ.NIC A generic testing framework was produced as a part of developing the Knot Resolver. This framework is written in python and can use UNIX domain sockets to bypass the underlying physical network. F. Discussion of latest SSAC recommendations 15 mins SSAC Stuckee SECOND SESSION G. Discovery method for a validating stub resolver 20 mins Xavier Gorjón, NLnetLabs This research project aims to develop a discovery method to ensure DNSSEC information can be delivered to the end host. It used RIPE ATLAS to study the current state of DNSSEC aware and DNSSEC validating resolvers, and define a course of action from that information. The project explored a novel method to discover the capabilities of the ISP's recursive resolver and bypass incompetent Customer-premises equipment (CPE) middle-boxes to target the often more capable ISP's resolver directly. H. DNSSEC for Legacy Applications 15 mins Willem Toorop, NLnetLabs Validating stub resolvers are hampered by middle boxes (typically CPE) that corrupt the path from the stub to the recursive resolver. Using the getdns library and the Linux/Unix name resolution framework, libnss_getdns provides (stub-level) DNSSEC validation for legacy applications. This module can work around broken middle boxes by double checking bogus answers. It also offers in-path signalling of DNSSEC failure for http, informing the end-user why validation failed and giving them control of deciding how to deal with that. I. Implementation challenges of geographic split-horizon DNS 20 mins Jan Včelák, CZ.NIC There are multiple ways to find a network service according to a client's geographic location. One possibility is to perform a split-horizon at the DNS level. The presentation will briefly inform about existing approaches, problems introduced by this mechanism, possible solutions of these problems, and experience we gained when implementing this feature into Knot DNS. J. Root Zone KSK rollover 30 mins Roy Arends, IANA K. WG Co-chair appointment 5 mins L. AOB

1 0