December 2017 - dns-wg - mailman.ripe.net

Update on root KSK roll project for December 2017
by Matt Larson 18 Dec '17

18 Dec '17

(Posted from my personal email because that's how I'm subscribed here.) Dear colleagues, I just posted an update on the root KSK roll project at https://www.icann.org/news/blog/update-on-the-root-ksk-rollover-project. The text is reproduced below for your convenience and please let me offer the customary apology if you receive duplicate postings of this message on multiple mailing lists. Matt -- Matt Larson <matt.larson(a)icann.org> VP of Research, Office of the CTO, ICANN The ICANN org is today announcing that it will not roll the root zone KSK in the first quarter of 2018. We have decided that we do not yet have enough information to set a specific date for the rollover. We want to make clear, however, that the ICANN org is committed to rolling the root zone KSK and we will continue to discuss this important process with the community, gather their feedback and give all interested parties advance notice of at least one calendar quarter when we set the date for the rollover. Furthermore, we are soliciting input from the community to help determine, if possible, appropriate objective criteria to measure the possible negative impact of the root KSK rollover on Internet users, and acceptable values for those criteria before a rollover. This is in accordance with the bottom-up, multi-stakeholder model that has been so successful for ICANN policy development. On 27 September 2017, the ICANN org announced it was postponing the root zone KSK rollover for at least one quarter, leaving open the possibility the root KSK rollover might occur in the first quarter of 2018. We have since realized that our analysis and preparation will require additional time. In a previous post, we described our analysis of recursive resolver trust anchor configuration information reported using the protocol defined in RFC 8145, Signaling Trust Anchor Knowledge in DNS SecurityExtensions (DNSSEC). Our analysis revealed that about 4% of the approximately 12,000 DNSSEC-validating resolvers reporting during the month of September 2017 were configured with only KSK-2010 (the shorthand for the current root KSK) and would have been unable to resolve DNS queries after the rollover occurred. The ICANN org's decision to postpone the rollover was based on the concern that we did not understand why those resolvers were not properly configured, and we needed time to investigate. Since then, we have attempted to contact the operators of 500 addresses that had reported a resolver configuration with only KSK-2010 instead of the correct configuration of both KSK-2010 and the new KSK, KSK-2017. Ideally, that investigation would have revealed a set of clear causes for the improper configuration, allowing further communication and actions to be targeted at addressing those specific issues. But in the end, the analysis was not as conclusive as we would have hoped. In our initial attempt, we received a response from operators of approximately 20% of the 500 addresses. Of those addresses whose operators we could contact, 60% came from address ranges known to host devices with dynamic addresses, such as routers of home broadband users and ephemeral virtual machines, making these resolvers extremely difficult (if not impossible) to track down. About 25% of the addresses corresponded to a resolver forwarding on behalf of another resolver that was reporting only KSK-2010. Since the address of the device reporting the incorrect configuration was not the actual source resolver, it is extremely difficult (if not impossible) to identify the true source address of the resolver that was reporting only KSK-2010. To proceed with the root KSK rollover, the ICANN org must have confidence that the rollover will not have an unacceptable negative impact on Internet users. The challenge we have encountered since we began to analyze the RFC 8145 trust anchor configuration reports from resolvers is assessing the impact on users. We can make a number of assumptions: for example, it is unlikely that a recursive resolver running at a dynamic address could support a large number of users since it does not offer a stable address for any devices to send queries to for resolution. But ultimately, determining potential user impact based on the data available to us is difficult and we are therefore soliciting the community's input. Input and discussion on acceptable criteria for proceeding with the KSK roll will take place on an existing email list that is already being used for discussion of the root KSK rollover. We encourage anyone interested in contributing to join the mailing list by visiting https://mm.icann.org/mailman/listinfo/ksk-rollover. The ICANN org will monitor this mailing list and beginning on 15 January 2018, we will develop a draft plan for proceeding with the root KSK roll based on the input received and discussion on the mailing list. The plan will be published by 31 January 2018 and undergo a formal ICANN public comment process to gather further input. We will hold a session at ICANN61 in San Juan, Puerto Rico, to discuss the plan and hear from the community in person. Our intent is to have a revised plan available for community review and public comment prior to ICANN62 in Panama City, Panama, with a final plan published soon thereafter. Throughout the process we'll continue to keep the community updated on the root KSK rollover project's progress.

1 0

Call For Presentations - DNS-OARC Workshop 28, San Juan, Puerto Rico, 8th/9th March 2018
by Anand Buddhdev 18 Dec '17

18 Dec '17

Call For Presentations The 28th DNS-OARC Workshop will be hosted by ICANN in San Juan, Puerto Rico, and will take place on March 8th and 9th immediately before ICANN61 (March 10th - 15th) [*] The Workshop's Program Committee is now requesting proposals for presentations. All DNS-related subjects are welcome. The first day of the workshop will start with a Members-only session which will include reports on DNS-OARC's activities. If you are an OARC member and have a sensitive topic that you wish to present during that session those can be accommodated. A timeslot will also be available for lightning talks (5-10 minutes) on day two of the workshop for which submissions will be accepted on the first day of the workshop, until 4pm. Workshop Milestones: 19 Jan 2018 - Deadline for submission 23 Jan 2018 - Initial contribution list published 16 Feb 2018 - Full agenda published 02 Mar 2018 - Deadline for slideset submission Details for presentation submission will be published here: https://indico.dns-oarc.net/event/28/call-for-abstracts/ The workshop presentations will be organized by common themes, depending on the topics and the timing of each presentation. There are 30-minute and 15-minute slots, let us know your preference in your submission. To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via <submissions(a)dns-oarc.net> Anand Buddhdev, for the OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact <sponsor(a)dns-oarc.net> if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) [*] <https://www.icann.org/news/blog/icann61-still-slated-for-puerto-rico> <https://www.icann.org/news/blog/a-look-ahead-to-icann61-in-puerto-rico>

1 0

DMARC Solution Applied to this Mailing List
by Adam Castle 18 Dec '17

18 Dec '17

Dear Working Group, As more email providers enable Domain Message Authentication Reporting & Conformance (DMARC), some people find they can no longer receive emails from the mailing lists they are subscribed to. We have deployed a Mailman setting change to address this problem. After consultation with the RIPE Working Group Chairs, we have enabled the DMARC "Munge From" setting on all RIPE mailing lists. This means that if your email service provider has DMARC enabled, you will continue to receive all emails sent to this mailing list, but the "From" part of the header will change. If you don't have DMARC enabled, you won't see any change to the emails you receive from this mailing list. You can find more information about how we have been handling DMARC in the following RIPE Labs articles: https://labs.ripe.net/Members/adam_castle/dmarc-and-the-ripe-ncc https://labs.ripe.net/Members/adam_castle/ripe-mailing-lists-and-dmarc To ensure all working group participants are aware of the changes, I am sending this mail to all working groups. If you have any questions or encounter any issues on this mailing list, please let me know. Many thanks. Adam Castle Web Services Manager RIPE NCC

1 0

Missing servers in DNSMON
by Chris Amin 13 Dec '17

13 Dec '17

Dear colleagues, It was recently brought to our attention that a small number of name servers were not being included in the visualisations on DNSMON. This issue has now been fixed, but you may notice a gap between mid-September and mid-December when visualising large time ranges for the affected servers. Apologies for any confusion or inconvenience caused. The affected zones and nameservers are: hk. - 203.119.87.218 xn--j6w193g. - 203.119.87.218 il. - 128.139.35.5 il. - 194.146.106.122 il. - 2001:67c:1010:31::53 mx. - 2001:13c7:7000::1 pl. - 2001:1a68:0:17::238 pl. - 2001:a10:121:1::156 pl. - 2a00:4120:8000:2::186 Kind regards, Chris Amin RIPE NCC

1 0

New on RIPE Labs: DNS TTL Violations in the Wild - Measured with RIPE Atlas
by Mirjam Kuehne 01 Dec '17

01 Dec '17

Dear colleagues, Please find this new article by Giovane Moura on RIPE Labs: DNS TTL Violations in the Wild - Measured with RIPE Atlas https://labs.ripe.net/Members/giovane_moura/dns-ttl-violations-in-the-wild-… Kind regards, Mirjam Kuhne RIPE NCC

1 0