- dns-wg - mailman.ripe.net

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

2017 dns-wg co-chair appointment
by Dave Knight 04 Sep '17

04 Sep '17

Colleagues, It’s that time again! In accordance with the chair selection process we announce that one of the current co-chairs (Jaap Akkerhuis) is standing down and we would like to invite volunteers, or nominations for someone to become a new co-chair of the DNS working group. The main responsibility of a co-chair is to prepare the agenda for the working group sessions, there are also some obligations in the policy development process, but the dns wg doesn’t often make policy. Anyone may volunteer, and anyone may be nominated by posting to the list. It would be helpful for candidates to give the working group some words as to why they think they ought to be a co-chair, what new ideas, or improvements they might bring, etc. Members of the working group are encouraged to show their support (or not) for those who volunteer, or are nominated. The working group will decide by consensus on the list who will be appointed. In the absence of consensus the tied candidates will draw lots. The aim is to be able to announce a new co-chair in the dns wg session at RIPE75 in Dubai. Thanks and kind regards, dave The WG Chair Selection Process <https://www.ripe.net/participate/ripe/wg/dns/dns-wg-chair-selection-process> Working Group Chair Job Description and Procedures <https://www.ripe.net/publications/docs/ripe-542>

13 12

New on RIPE Labs: Dealing with IPv6 Fragmentation in the DNS - Part 2 (by Geoff Huston)
by Mirjam Kuehne 30 Aug '17

30 Aug '17

Dear colleagues, Please find part 2 of Geoff Huston's IPv6 Fragmentation measurements on RIPE Labs: Dealing with IPv6 Fragmentation in the DNS - Part 2 https://labs.ripe.net/Members/gih/dealing-with-ipv6-fragmentation-in-the-dn… Kind regards, Mirjam Kuhne RIPE NCC

1 0

New on RIPE Labs: Dealing with IPv6 Fragmentation in the DNS by Geoff Huston
by Mirjam Kuehne 23 Aug '17

23 Aug '17

Dear colleagues, Please find this new article by Geoff Huston on RIPE Labs: Dealing with IPv6 Fragmentation in the DNS https://labs.ripe.net/Members/gih/dealing-with-ipv6-fragmentation-in-the-dns Kind regards, Mirjam Kuhne RIPE NCC

1 0

ICANN Name Collision framework
by Rubens Kuhl 19 Aug '17

19 Aug '17

(Sorry if you have received more than 1 copy of this e-mail, since this is being sent to technical mailing lists focusing on DNS) There is ongoing policy development effort within ICANN towards subsequent procedures of new gTLDs releases; during the last round in 2012, one of the last pieces of the program to be defined was the name collision framework, detailed at https://www.icann.org/resources/pages/name-collision-2013-12-06-en <https://www.icann.org/resources/pages/name-collision-2013-12-06-en> . The current thinking is to keep most of the framework as it was in that round, with minor changes for low risk strings and some more detail for other strings. The base principle is to use research-accessible trusted databases such as DITL and ORDINAL to make decisions. In chronological order, the process would be like this: 1) Pre-application procedure ICANN Org would provide a "do not apply" list containing strings like localhost and an "exercise care" list containing strings such as the ones hitting root servers with large number of invalid queries, where it's expected that a non-standard mitigation framework would be required. 2) Application time Applicants would need to file a mitigation framework for "exercise care" strings but could file one for other strings as well. 3) Evaluation time Each applied-for unique string would be evaluated and divided into 3 buckets of strings: high-risk strings would have their applications terminated, aggravated risk ones would require non-standard mitigation framework and low-risk strings would use the standard framework. Note that "exercise care" strings might turn out to be low-risk, or strings not listed in any list might turn out to be high or aggravated risk. 4) Controlled interruption As soon as a decision is made regarding risk assessment, ICANN Org itself would perform 90 days or more of wildcard 127.0.53.53 controlled interruption for all low-risk strings. This would be different from the 2012-round as this was done by registry operators after they got IANA delegation. IANA delegation of those will be actually a redelegation to registry operators. ICANN Org would have the option to decide answer NXDOMAIN instead of 127.0.53.53 for specific labels that caused disruption, with the understanding that those labels would still require 90 days of controlled interruption to be later used. 5) Aggravated risk strings Each framework will be evaluated using registry services technical evaluation procedures and carried out by registry operator, with ICANN monitoring its compliance. Some of the questions still to be answered by the WG include: - Guidelines, lists and/or procedures for creating "do no apply" and "exercise care" lists - Guidelines and/or procedures for applied strings risk assessment - Whether 2-year readiness for collisions with potential harm to human life should still exist since none was detected in the 2012-round, and only 37 collisions were reported to ICANN. - Whether 2012-round TLDs that already completed their 2-year readiness cycles should still have some kind of operational readiness thru the lifecycle of the TLD. So, the reasons for outreaching to this technical group include: - Whether someone has feedback for the current thinking of the process. Nothing is final until they are final. - Whether someone has feedback on the unanswered questions so progress can be made in those areas. Thanks! Rubens Kühl

1 0

Updating RIPE 203
by Carsten Strotmann 14 Aug '17

14 Aug '17

Dear colleagues, RIPE document 203 "Recommended for DNS SOA values" gives recommendations for the values of the SOA record used in simple and stable zones. The document has been aimed at beginner level DNS administrators, to give guidance when creating a zone file. <https://www.ripe.net/publications/docs/ripe-203> The document has been successful, and despite its age, it is still being used and referred to today. Over time the document has aged and the recommendations given in the text are not a good match for today's Internet DNS anymore. Some while ago Peter Koch and I volunteered in the RIPE DNS WG to update the document. In my work (DNS training, consulting and support), I get occasional requests for recommendations for SOA values to use. This shows that such a document is still useful today. Before starting the process of wordsmithing the entire text, we would like to discuss the new values here in the mailing list. The aim for the document is not to provide the one and only set of "correct" values (there are many), but a set of values that are "not wrong" in most DNS use cases. Also keep in mind that the document should be of help for novice DNS administrators with relative simple zones (less than 1000 RRs, no more than 1 change/week). Large zones, very agile zones with dynamic changes, specialty zones like Active Directory zones are out of scope of the document. Like the original document, we present one set of values, not ranges. The document should be a "as simple as possible" starting point for new DNS admins. Copy and pasting is encouraged. As Roland v. Rijswijk mentioned in his talk at SHA 2017 last weekend (recommendation --> "OpenINTEL: digging in the DNS with an industrial size digger" https://media.ccc.de/v/SHA2017-130-openintel_digging_in_the_dns_with_an_ind…) the Internet is build on the premise of de-centralization. To support DNS operators today that like to run their own DNS infrastructure (instead going central in "the cloud"), the entry barrier for setting up a simple but working DNS zone should be as low as possible. The original SOA values for RIPE 203: example.com. 3600 SOA dns.example.com. hostmaster.example.com. ( 1999022301 ; serial YYYYMMDDnn 86400 ; refresh ( 24 hours) 7200 ; retry ( 2 hours) 3600000 ; expire (1000 hours) 172800 ) ; minimum ( 2 days) the new proposed and updated values $TTL 3600 example.com. 3600 SOA dns.example.com. hostmaster.example.com. ( 2017080101 ; serial YYYYMMDDnn 7200 ; refresh ( 2 hours) 1800 ; retry ( 30 minutes) 3600000 ; expire (1000 hours) 3600 ) ; minimum/negative TTL ( 1 hour) One observation from the past years is that in situations where the time required for an DNS change is longer that the average working day (8 hours), the change is more likely to fail. Operators get distracted and abandon the change or pick up the change at a later day having lost the context of the original intend for the change. The new values are chosen in a way that most changes to the DNS zone and infrastructure can be done in one work day. Lower values will cause more DNS queries and more load on the DNS infrastructure (resolver and authoritative server), but recent experiments ("How the TTL reducing impacted the .cz zone" https://en.blog.nic.cz/2017/05/18/how-the-ttl-reducing-impacted-the-cz-zone/) has shown that the effects are manageable. Some changes to the DNS infrastructure (like change of delegation information) depends on the TTL values used in the parent domain, but we also see a trend to use lower TTL values in the parent zones as well ("Keeping DNS Parents and Children in Sync at Internet Speed!, Olafur Gudmundsson, Cloudflare" https://ripe70.ripe.net/presentations/51-RIPE-20150309-cf-DNS.pdf) Given these constraints, we would like to get feedback from the mailing list on the new values: * do you see potential issues with the proposed values for zones that are in scope of the document? Best regards Carsten Strotmann

5 9