- dns-wg - mailman.ripe.net

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

2nd call for presentations RIPE 75
by Benno Overeinder 14 Aug '17

14 Aug '17

Dear colleagues, Please note the approaching deadline of *20 August 2017* for RIPE 75 plenary programme submissions. You can find the CFP for RIPE 75 below or at https://ripe75.ripe.net/submit-topic/cfp/, for your proposals for plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. Note: Due to UAE law, confirmed speakers will need to submit a copy of their passport and contact information in advance of the meeting. More details are available here: https://ripe75.ripe.net/attend/dctm-requirements Kind regards, Benno Overeinder RIPE PC Chair https://ripe75.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 75 will take place from 22-26 October in Dubai, UAE. 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 75. See the full descriptions of the different presentation formats, https://ripe75.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than *20 August 2017*. 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 Due to UAE law, confirmed speakers will need to submit a copy of their passport and contact information in advance of the meeting. More details are available here: https://ripe75.ripe.net/attend/dctm-requirements Please also note that speakers do not receive any discount or funding towards the meeting fee at RIPE Meetings. Submissions 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 - 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://ripe75.ripe.net/submit-topic/ - Lightning talks should also be submitted using the meeting submission system (https://ripe75.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 [at] ripe [dot] net. -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/

1 0

Second call for contributions to the DNS wg at RIPE75
by Dave Knight 03 Aug '17

03 Aug '17

Dear colleagues, The RIPE 75 meeting in Dubai is 12 weeks away and we’d like to form a draft agenda soon. The deadline for submissions us August 20th. Note that in accordance with Dubai Department of Tourism and Commerce Marketing (DTCM) legislation, confirmed speakers are required to submit a colour passport copy, along with a personal profile. More detail is available here: https://ripe75.ripe.net/attend/dctm-requirements <https://ripe75.ripe.net/attend/dctm-requirements> Please submit your presentation ideas, or suggestions for discussions to <dns-wg-chairs(a)ripe.net <mailto:dns-wg-chairs@ripe.net>>. Please don’t submit anything using the meeting submission web form, it’s not intended for submission of content to working groups. Thanks! dave, on behalf of the working group chairs

1 0

NSID option on the RIPE Atlas SOA measurements of the root servers
by Chris Amin 24 Jul '17

24 Jul '17

Dear colleagues, RIPE Atlas is currently running a series of DNS SOA built-in measurements* towards all of the root servers from all probes. During the recent DNS measurements hackathon** it became apparent that for some use cases it would be useful to have SOA queries from all probes with the NSID EDNS option set, in order to be able to match up responses with the particular responding instances in an anycasted (or load balanced) setup. We would like to ask for feedback on two alternative options for implementing this change. They are: 1) Enable the NSID option for the existing built-in measurements towards the nine root servers which support it. 2) Start a new set of built-in measurements towards the nine root servers which support NSID. The advantages of option (1) are that it will be possible to compare and contrast the two sets of results, and that historical data for the existing built-ins will remain consistent with the current results. A very simple analysis shows that there is no overall increase in query error rates through enabling NSID, but there are bound to be individual marginal cases where queries fail or produce different results with NSID set but succeed without it. The advantages of option (2) are that there will be no increase in result storage usage -- the current IPv4+IPv6 UDP SOA built-ins towards the nine supporting root servers adds up to about 80 results per second (~1.5% of the total results in the system). This could potentially be mitigated by reducing the frequency for these new measurements, but perhaps more important than the slightly increased load is the potential user confusion caused by generating and providing two very similar sets of measurements. Please let us know if you have any preference for which way we go on this, particularly if you have a (current or future) use case for this kind of data. Kind regards, Chris Amin RIPE NCC * https://atlas.ripe.net/docs/built-in/ ** https://labs.ripe.net/Members/becha/results-dns-measurements-hackathon

4 4

Fw: [ripe-list] RIPE Mailing List / RIPE Forum Code of Conduct
by Shane Kerr 12 Jul '17

12 Jul '17

Fellow RIPE DNS working group participants, We have adopted a Code of Conduct for RIPE mailing lists, including this one. Please refer to Hans Petter Holen's e-mail for the background and actual code. I have attached it to this e-mail. You can of course discuss the code and its adoption on this list. Please also feel free to contact Dave, Jaap, or myself (the DNS working group co-chairs) if you have any questions. Cheers, -- Shane On behalf of the DNS working group co-chairs

1 0

new KSK for the root
by Jim Reid 11 Jul '17

11 Jul '17

In case anyone missed this event, the new KSK for the root got added today. Though it’s not signing anything yet. Thanks to everone who made this happen.

1 0