- dns-wg - mailman.ripe.net

New on RIPE Labs: The Peculiar Case of NSEC Processing Using Expanded Wildcard Records
by Mirjam Kuehne 31 Jan '18

31 Jan '18

Dear colleagues, Please read this new article by Ralph Dolmans from NLnet Labs. In this article Ralph describes a flaw that made it possible to downgrade secure connections and how it got fixed: https://labs.ripe.net/Members/ralph_dolmans/the-peculiar-case-of-nsec-proce… Kind regards, Mirjam Kühne RIPE NCC

1 0

New on RIPE Labs: Bringing DNS Security and Privacy to the End User
by Mirjam Kuehne 24 Jan '18

24 Jan '18

Dear colleagues, In this new article on RIPE Labs Benno Overeinder describes a number of initiatives that can help users to ensure proper authentication and encryption of DNS data: https://labs.ripe.net/Members/benno_overeinder/bringing-dns-security-and-pr… Kind regards, Mirjam Kühne RIPE NCC

1 0

Call for presentations RIPE 76
by Benno Overeinder 23 Jan '18

23 Jan '18

Dear colleagues, Please find the CFP for RIPE 76 below or at: https://ripe76.ripe.net/submit-topic/cfp/. The deadline for submissions is *11 March 2018*. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings, see the "Speakers" paragraph in CFP for more information. Kind regards, Benno Overeinder RIPE PC Chair https://ripe76.ripe.net/ripe-pc/ -------------------->>><<<-------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 76 will take place from 14-18 May in Marseille, France. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 76. See the full descriptions of the different presentation formats, https://ripe76.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than *11 March 2018*. Proposals submitted after this date will be considered depending on the remaining available space in the programme. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange - Connected Things (aka. Internet of Things - IoT) Speakers Presenters, RIPE Working Group Chairs and the RIPE Programme Committee are required to cover their own costs to attend a RIPE Meeting (meeting ticket, travel and accommodation). We have various ticket options available depending on your needs. In extraordinary circumstances, the RIPE Chair can waive the meeting fee for presenters. These requests are dealt with on a case-by-case basis via pc(a)ripe.net. Also note that, on an individual basis, participants can apply for a RIPE Fellowship to develop their professional or academic career. For more information, please visit: https://www.ripe.net/participate/ripe/ripe-fellowship Submissions Presenters should be clear on whether they wish to submit a presentation for a plenary or working group (WG) session. At present, most working groups will solicit policy proposals, discussion points or other content directly via their mailing lists. If you’re not sure what kind of session you should be presenting at, please visit: https://ripe76.ripe.net/plenary-or-wg/ RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour (during evening sessions) - Lightning talks: 10 minutes total for both presentation and any discussion The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe76.ripe.net/submit-topic/ - Lightning talks should also be submitted using the meeting submission system (https://ripe76.ripe.net/submit-topic/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice, in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. If you have any questions or requests concerning content submissions, please email pc(a)ripe.net. -- Benno J. Overeinder NLnet Labs https://www.nlnetlabs.nl/

1 0

DNS/ rDNS setup
by Oiver Mitchell 22 Jan '18

22 Jan '18

Hi, I’m after any documentation regarding DNS/ rDNS setup and what’s required, and how to set up a Name server/s. If this could be listed clearly it would be of most help. What network does the DNS server and name servers need to be on? DMZ est. We are new to this kind thing, Id like a response back as soon as possible. Thanks very much. Kind Regards Oliver Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

Extended Deadline for submissions for DNS-OARC Workshop 28
by Anand Buddhdev 20 Jan '18

20 Jan '18

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. The deadline for submissions to the workshop has been extended to February 2nd, with the other workshop milestones updated as follows: 19 Jan 2018 - Original Deadline for submission 23 Jan 2018 - Initial contribution list published 02 Feb 2018 - Extended Deadline for Submission 13 Feb 2018 - Updated contribution list published 23 Feb 2018 - Full agenda published 02 Mar 2018 - Deadline for slideset submission Presentation submission details are at: <https://indico.dns-oarc.net/event/28/call-for-abstracts/> Anand Buddhdev, for the DNS-OARC Programme Committee

1 0

New on RIPE Labs: Traceroute Haikus
by Mirjam Kuehne 16 Jan '18

16 Jan '18

Dear colleagues, Please find a new article by Ben Cartwright-Cox on RIPE Labs: Traceroute Haikus https://labs.ripe.net/Members/ben_cox/traceroute-haikus Kind regards, Mirjam Kühne RIPE NCC

1 0

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