June 2019 - 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