- dns-wg - mailman.ripe.net

draft minutes from RIPE64
by Jim Reid 15 Sep '12

15 Sep '12

Colleagues, here they are. Please speak up if there are any errors or omissions so that these can be approved by the WG at RIPE65. Thanks.

1 0

New on RIPE Labs: Root Server Instances in Member Networks
by Mirjam Kuehne 06 Sep '12

06 Sep '12

[apologies for duplicates] Dear colleagues, Please find a proposal on RIPE Labs how to create member instances of K-root and how to implement this during a pilot phase: https://labs.ripe.net/Members/dfk/root-servers-in-member-networks Kind regards, Mirjam Kuehne RIPE NCC

1 0

FWD from address-policy-wg: Cosmetic Surgery Project: Review Period on Version 2 of Draft Document, for Reverse Address Delegation of IPv4 and IPv6 Address Space]
by Peter Koch 06 Sep '12

06 Sep '12

Dear DNS WG, the following announcement and proposal may be relevant for this audience. Please follow the instructions for comments. Thanks, Peter (as WG co-chair) ----- Forwarded message from Emilio Madaio <emadaio(a)ripe.net> ----- From: Emilio Madaio <emadaio(a)ripe.net> To: address-policy-wg(a)ripe.net Subject: [address-policy-wg] Cosmetic Surgery Project: Review Period on Version 2 of Draft Document, for Reverse Address Delegation of IPv4 and IPv6 Address Space Date: Wed, 5 Sep 2012 14:52:18 +0200 Reply-To: address-policy-wg(a)ripe.net Dear colleagues, As part of the Cosmetic Surgery Project, the RIPE NCC is moving forward with a review of the policy document ripe-302, "Policy for Reverse Address Delegation of IPv4 and IPv6 address space in the RIPE NCC Service Region". After the feedback in the previous review phase, a new draft (2.0) of the policy document is online and ready for community review at: https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-doc… The highlights of the changes from the previous version include: -the removal of all unnecessary references to "reverse resolution" -the rewording and simplification of section 4.0 In response to the community's request: -section 3.0 focuses on who is able to ask for the delegation -the reference to the obsolete RFC 2874 has been replaced with the relevant active RFCs The Address Policy Working Group Co-Chairs decided to extend the review period until 3 October 2012 to allow the community more time to give their feedback. Please send your feedback on this draft document to the Address Policy Working Group at: <address-policy-wg at ripe.net>. Kind regards, Emilio Madaio Policy Development Officer RIPE NCC ----- End forwarded message -----

1 0

DRAFT DNS WG Agenda for upcoming meeting at RIPE65
by Peter Koch 02 Sep '12

02 Sep '12

Dear WG, please find below (and soon at <https://ripe65.ripe.net/programme/meeting-plan/dns-wg/>) the first draft agenda for our meeting at RIPE65 in Amsterdam: ============================================================================= D R A F T Agenda ============================================================================= RIPE DNS WG Meeting at RIPE65, Amsterdam ============================================================================= Session I Wed 26 Sep 1100-1230 // EIX Session II Wed 26 Sep 1400-1530 // IPv6 ============================================================================= 0 Administrivia Introduction, mailing list, minutes, mic discipline 1 Software reports OpenDNSSEC [Sara Dickinson] Knot DNS [Marek Vavrua] 2 Interop & New Protocols DNS Benchmarking effort [Ondrej Sury] IETF [DANE] [Ondrej Sury] 3 RIPE NCC report [Romeo Zwart] 4 DNSMON future [Daniel Karrenberg] 5 Operational considerations [Roland van Rijswijk] and recommendations for DNS response packet sizes 6 Panel (tentative) DNS amplification attacks: BCP38, mitigation, reputation or what? 7 Panel (tentative) Overcoming the "first mover loses" paradigm for IPv6^WDNSSEC deployment ============================================================================= The sequence of presentations/talks is subject to change to accomodate timing and presenter availability. Please note that the panel sessions are "in the making" and subject to up-to-dateness. Suggestions welcome at <dns-wg-chair(a)ripe.net>. Best regards, Peter

1 0

DNS measurements available as RIPE Atlas UDMs
by Vesna Manojlovic 28 Aug '12

28 Aug '12

Dear colleagues, I am happy to announce DNS measurements, a new addition to the RIPE Atlas User Defined Measurements (UDM), making it in total 4 types of customized measurements available to RIPE Atlas hosts & RIPE NCC members. Please find out the details in the RIPE Labs article: https://labs.ripe.net/Members/becha/dns-user-defined-measurements-in-ripe-a… Please let us know what you think, and enjoy the measurements :) Regards, Vesna

1 0

Syntax of the "nserver:" Attribute in Domain Objects
by Anand Buddhdev 23 Aug '12

23 Aug '12

[Apologies for duplicate emails] Dear colleagues, Following on from the removal of the forward DOMAIN objects from the RIPE Database, all DOMAIN objects are now used for either reverse DNS or ENUM delegations. For both these cases, the "nserver:" attribute is required. Currently this attribute is optional and there are many objects in the RIPE Database that do not have any "nserver:" attributes. These objects are ignored by the DNS provisioning service, because they have no operational value. The RIPE NCC proposes to make the "nserver:" attribute mandatory in DOMAIN objects and delete any objects from the RIPE Database that do not have this attribute. To simplify the parsing of DOMAIN objects, the RIPE NCC also proposes to deprecate the list option on the "nserver:" attribute (a list, when used in combination with end-of-line comments and continuation lines, is very complex to parse). This means adding multiple name servers to a single attribute will no longer be allowed. For example, an attribute currently formatted as: nserver: ns1.example.com ns2.example.net will have to be rewritten as: nserver: ns1.example.com nserver: ns2.example.net If glue records are required, they would be written like this: nserver: ns1.2.0.192.in-addr.arpa 192.0.2.1 nserver: ns1.2.0.192.in-addr.arpa 2001:db8::1 nserver: ns2.2.0.192.in-addr.arpa 192.0.2.2 nserver: ns2.2.0.192.in-addr.arpa 2001:db8::2 There are a number of domain objects in the RIPE Database which use the list feature, and list multiple name servers in a single "nserver:" attribute. As part of this syntax change, we would update these objects to use the new syntax. This would not affect DNS delegation in any way. This message has been sent to both the DNS and Database working groups, but we ask that discussion of this matter be kept on the DNS WG mailing list. Regards, Anand Buddhdev RIPE NCC

4 7

Deprecation of DOMAIN object attributes
by Denis Walker 21 Aug '12

21 Aug '12

[Apologies for duplicate emails] Dear Colleagues, At RIPE 62, the RIPE NCC was asked to look at the attributes in DOMAIN objects. A suggestion was put forward to deprecate the following attributes: mnt-lower: sub-dom: dom-net: refer: These were considered to be of no use after the removal of forward domain data and no longer allowing hierarchical, reverse delegation data. The RIPE NCC is now removing these attributes from the syntax. It will no longer be possible to create objects with these attributes. To modify objects already containing them, these attributes will need to be removed. As a follow up the RIPE NCC will "clean" the reverse delegation and ENUM DOMAIN object data to remove these attributes. The web forms for both updates and queries will also have these attributes removed. Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

Call for agenda items for the RIPE65 DNS WG meeting
by Peter Koch 20 Aug '12

20 Aug '12

Dear WG, the next RIPE meeting is eight weeks away and we have our usual two DNS WG slots on the Wednesday of the meeting week: <https://ripe65.ripe.net/programme/meeting-plan/> Your chairs would like to invite you to send in agenda item suggestions to either of us or to <dns-wg-chairs(a)ripe.net>. If you have anything to share or an idea that you'd like community feedback for, this is the time to speak up. Take this non-exhaustive list as a start: o operational practices o operational observations, traffic patterns o measurements o deployment experiences o tools (yes, that might be _your_ basket of scripts) o ... Since we have received positive feedback regarding the panel discussions (twice in a row makes it almost a tradition now), we would like to use this format once more, but again: we're dependent on your contributions. Please let us know of issues that you'd like to see addressed and/or volunteer for participation. Thanks in advance, Peter (for the three co-chairs)

1 1

New delegation checking software
by Anand Buddhdev 08 Aug '12

08 Aug '12

[Apologies for duplicates] Dear colleagues, Tomorrow, 8 August 2012, the RIPE NCC will deploy a change to the RIPE Database update software. As part of this deployment, we will switch to a new DNS delegation checker, developed by .SE, the Swedish domain name registry. This change should not have any impact on the process of registering a reverse DNS delegation in the RIPE Database. However, the informational and diagnostic messages this software returns will look different from the ones you have been seeing so far. There should be no noticeable outage in any of the services during this deployment. There will be no change to any other parts of the RIPE Database update or query software with this deployment. Along with these changes to the back-end software, the RIPE NCC will also update the web-based delegation checker at: http://www.ripe.net/data-tools/dns This new web-based delegation checker will use the same software as the back-end. We will send another announcement after we have deployed this new software. If you have any questions or comments, please send an email to <dns(a)ripe.net>. Regards, Anand Buddhdev RIPE NCC

1 1

rDNS Incident: The Facts
by Daniel Karrenberg 19 Jun '12

19 Jun '12

We have just published the time-line of events that led to the rDNS service issues last week: https://labs.ripe.net/Members/dfk/timeline-of-reverse-dns-events I realise that our operational performance was not up to the standard you expect from us and I apologise again for the considerable inconvenience we have caused some of you. Another report will follow once we have fully analysed what happened. Daniel

1 0