- dns-wg - mailman.ripe.net

Call for Presentations: 31st DNS-OARC Workshop, Austin, Texas, Oct 31 - Nov 01 2019
by Dave Knight 28 Jun '19

28 Jun '19

Colleagues, The 31st DNS-OARC Workshop will take place at the JW Marriott Austin in Austin, Texas, USA on October 31st and November 1st 2019. It is co-located with and will take place right after NANOG 77 (Oct 27th to Oct 30th 2019). The Workshop's Program Committee is now requesting proposals for presentations. All DNS-related subjects are welcome. A time slot will also be available for lightning talks (5-10 minutes each) on day two of the workshop, for which submissions will be accepted just before the start of the workshop and until the start of the morning break on day two. There will be an OARC Business and AGM session during the workshop, which will be for OARC Members only. If you are an OARC member and have a sensitive topic that you wish to present during that session those can be accommodated. Workshop Milestones: 25 Jun 2019 - Submissions open via Indico 16 Aug 2019 - Deadline for submission (midnight CDT) 28 Aug 2019 - Initial Contribution list published 28 Sep 2019 - Full agenda published 18 Oct 2019 - Deadline for slideset submission 31 Oct 2019 - Workshop Details for presentation submission are published here: <https://indico.dns-oarc.net/event/32/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> Dave Knight, for the DNS-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.)

1 0

NCC reverse delegation criteria
by Jonas Frey 13 Jun '19

13 Jun '19

Hello all, as for this topic, i have started the discussion on the members-discuss list. So far it seems there are various opinions about this topic. From the replys i have received it seems these are: - Dont run a open resolver, let RIPE block - Dont run a open resolver, let RIPE warn - Run a open resolver and secure it propely, RIPE pass - Dont check anything, RIPE pass - Let RIPE check for amplification level, decide on that The main question is if RIPE should prohibit technically valid configurations. IMO: if the open resolver+auth. resolver is considered a bad setup (for operational reasons/resilience or whatever) then that should be left up to the company running it (as possible impact is limited to that - besides amplification). (However there seem to be huge controversal thoughts about this, i.e. if dividing both functions is still neccessary in 2019) As previously noted most (if not all) ccTLD registrys do not block when a open recursor is found. (C/N/O: Verisign pass, EU EURID: pass, DE DE- NIC: pass with warn). Now that these ccTLDs deal with *alot* more nameservers than RIPE (probably), why would it make sense for RIPE to force a block of them? -- Mit freundlichen Grüßen / Best regards, Jonas Frey ---------------------------------------------------------------- Probe Networks Jonas Frey e-Mail: jf(a)probe-networks.de Auf Strützberg 26 D-66663 Merzig Tel: +(49) (0) 6861 90897-00 Fax: +(49) (0) 6861 90897-99 Internet: www.probe-networks.de Hotline: 0800 1656531 ---------------------------------------------------------------- Diese E-Mail enthaelt moeglicherweise vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist strengstens untersagt. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the contents of this e-mail is strictly prohibited. ------------------------------------------

11 25

RIPE NCC's reverse DNS delegation process and stats
by Anand Buddhdev 12 Jun '19

12 Jun '19

Dear colleagues, As requested, here is some information about the reverse DNS delegation process applied by the RIPE NCC. We perform pre-delegation checks with a local instance of Zonemaster, which is DNS delegation testing software that was developed by AFNIC and IIS. The software performs the following tests: https://github.com/zonemaster/zonemaster/tree/master/docs/specifications/te… Test results are classified into one of five levels of severity: INFO, NOTICE, WARNING, ERROR, or CRITICAL. This classification is governed by a policy, and ours follows the default Zonemaster profile here: https://github.com/zonemaster/zonemaster-engine/blob/master/share/profile.j… According to this policy, a name server offering recursion is classified as ERROR. When we perform pre-delegation tests, the request is rejected if any of the test results are classified at the ERROR or CRITICAL levels. We have the results of pre-delegation tests going back to 30 June 2017. Between then and now, we rejected 5,125 delegation requests for 1,833 zones because at least one of the name servers of a zone was an open recursor. It's worth noting that these requests may have been rejected for other reasons in addition to this one, and there were multiple requests for some zones, which accounts for the imbalance between the two numbers. Finally, before Zonemaster we used software called DNScheck, which was developed by IIS. This also checked for open recursive name servers and classified this condition as an error. Regards, Anand Buddhdev RIPE NCC

1 0

NCC reverse delegation criteria
by Måns Nilsson 11 Jun '19

11 Jun '19

Recently, a discussion regarding the checks performed by the NCC before reverse delegation is made came up on the members-discuss list. It was concluded that this should be discussed here rather than there. The members archive might not be available to all, so I'll try to summarize. Please add your take on summary if you find mine lacking. The questioned practice was that the NCC rejects the delegation request if the target server is found to be an open recursor. Some participants argued that this is not a technical problem, and some said yes it is. Some held that the NCC has no authority blocking a request, but it was argued that every delegation is subject to RFC 1591 responsibilites. For starters, are the delegation requirements described somewhere? Best regards, -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 In 1962, you could buy a pair of SHARKSKIN SLACKS, with a "Continental Belt," for $10.99!!

9 12

RIPE 78 DNS working group final agenda
by Shane Kerr 20 May '19

20 May '19

Colleagues, Here's a (hopefully) final agenda for the DNS working group session in RIPE 78. Peter Špaček's presentation on the DNS Flag Day 2019 will be given at the RIPE Plenary on Tuesday, and not at the DNS working group session. We also added a couple of short presentations from the RIPE NCC, one general update and another about the recent work on ENUM that they have been doing. We're meeting on Thursday 23 May from 16:00 to 17:30. 1. Administrivia 5 minutes 2. RIPE NCC DNS Update by Anand Buddhdev 5 minutes 3. ENUM Cleanup by Marco Hogewoning 5 minutes 4. Overview of the DNS Privacy Software landscape by Carsten Strotmann 30 minutes 5. unwind, a validating DNS recursive nameserver by Carsten Strotman 5 minutes 6. Tag You're It!: Revisiting the Reality of DNSSEC Keytags by Roland M. van Rijswijk-Deij 15 minutes 7. root KSK Rollover Wrap-up by the DNS working group chairs 15 minutes 8. DNS-OARC Summary by Dave Knight 10 minutes Skál, -- The RIPE DNS Working Group Chairs Dave, João, and Shane

2 1

Draft minutes from the DNS working group at RIPE 77
by Shane Kerr 13 May '19

13 May '19

DNS Colleagues, Draft minutes from the DNS working group at RIPE 77 are available here: https://www.ripe.net/participate/ripe/wg/dns/minutes/dns-working-group-minu… Please send any corrections to the DNS working group chairs at <dns-wg-chairs(a)ripe.net>. Cheers, -- Dave, João, and Shane RIPE DNS Working Group Chairs

1 0

Revised Operating Instructions for e164.arpa (ENUM)
by Marco Hogewoning 03 May '19

03 May '19

Dear colleagues, The RIPE NCC is the operator of the e164.arpa zone (ENUM) and maintains the associate registry in accordance with the instructions of the Internet Architecture Board (IAB). As delegations are based on E.164 country code allocations, any changes to the registry are coordinated with and approved by the respective holders of the E.164 country code via the ITU’s Telecommunications Standardisation Bureau (TSB). Recent checks have shown that over time, many of the current 57 delegations have deteriorated – they are no longer technically functional or the contacts details for the country code registry have not been updated. Seeking advice from the IAB on these matters, they agreed to revise the instructions to address these issues. Among the changes is new text regarding the deletion of delegations and instructions that allow the RIPE NCC to do periodic checks on registry data. This will allow us to initiate a process to review the existing delegations and coordinate with the registries, governments and the TSB to mitigate and correct any errors. In cases where we are unable to correct an error, we will advise the government involved to remove the delegation, until such time that a new registry can assume responsibility for the country code and restore its technical functionality. ITU Study Group 2, which is responsible for the E.164 number registry, shared our concerns and at its last meeting agreed to update its instructions to the TSB to reflect these changes. As we remain committed to coordinating any delegations with TSB, the Member States involved and Study Group 2, we welcome the study group’s renewed interest in the topic and its support in reviewing and updating these registrations. The new instructions have now been published on our website and, with the IAB’s approval, we will now operate the registry in accordance with these. The instructions are available here: https://www.ripe.net/manage-ips-and-asns/dns/enum/iab-instructions Kind Regards, Marco Hogewoning Senior External Relations Officer, RIPE NCC, Ted Hardie For the IAB

3 2

Re: [dns-wg] New on RIPE Labs: Making the DNS More Private with QNAME Minimisation
by Wouter de Vries 29 Apr '19

29 Apr '19

On Mon, Apr 29, 2019 at 08:43:52AM +0100, Piete Brooks wrote: > > In the case your resolver was doing qmin, the third line should have read something like: > > myip -> 185.49.141.12 TXT b.qnamemin-test.internet.nl (omitting the last label: a). > > And a second typo would allow me to understand it - was that a TXT or an NS lookup? I blame it on early monday. That should have been NS indeed :-). Also your other comment about the IP is correct, sorry about that. So the final request/response sequence should happen between myip and 185.49.141.13.

1 0

New on RIPE Labs: Making the DNS More Private with QNAME Minimisation
by Mirjam Kuehne 29 Apr '19

29 Apr '19

Dear colleagues, DNS queries can contain a lot of sensitive information about Internet users. Query name minimisation (qmin) limits the information revealed to what is actually necessary for a DNS name server to answer the query. Woute de Vries, Moritz Mueller and others did a study on qmin deployment and the associated challenges: https://labs.ripe.net/Members/wouter_de_vries/make-dns-a-bit-more-private-w… Kind regards, Mirjam Kühne RIPE NCC

5 5

RIPE 78 DNS working group draft agenda v2
by Shane Kerr 10 Apr '19

10 Apr '19

Colleagues, Here's an updated draft agenda for the DNS working group session in RIPE 78 (we overlooked an interesting submission from Roland van Rijswijk-Deij). We're meeting on Thursday 23 May from 16:00 to 17:30. 1. Administrivia 5 minutes 2. Overview of the DNS Privacy Software landscape by Carsten Strotmann 30 minutes 3. unwind, a validating DNS recursive nameserver by Carsten Strotmann 5 minutes 4. DNS flag day 2019 and beyond by Petr Špaček @ CZ.NIC 15 minutes 5. Tag You're It!: Revisiting the Reality of DNSSEC Keytags by Roland M. van Rijswijk-Deij 15 minutes 6. root KSK Rollover Wrap-up by the DNS working group chairs 15 minutes 7. DNS-OARC Summary by Dave Knight 10 minutes See you in Reykjavík! -- The RIPE DNS Working Group Chairs Dave, Joao, and Shane

1 0