- dns-wg - mailman.ripe.net

Incorrect RCODE values in DNSMON and DomainMon
by Romeo Zwart 25 May '16

25 May '16

Dear colleagues, It has been brought to our attention that the RCODE values resulting from DNS measurements in RIPE Atlas are sometimes presented incorrectly in DNSMON and DomainMon. We are currently examining this in more detail, but preliminary investigations suggest that this is due to a bug in the software parsing and storing DNS measurement results in our backend systems. Note that there is no impact on the DNS measurement data itself - only the RCODE values are affected. This issue has a potential impact on DNSMON and DomainMon visualisations if one filters on RCODE by checking the "Exclude errors" tick box. This filter is not enabled by default, so it will not normally have an impact on these visualisations. We are still investigating the full extent of this problem. Based on the information available, we expect to have fixed the issue and corrected the historic RCODE values by the end of June. We will update you via this list when we have more information and a more accurate ETA for the fix. Kind regards, Romeo Zwart

1 0

RIPE 72 DNS WG Agenda - Update
by Dave Knight 19 May '16

19 May '16

Colleagues, Here's the updated agenda for the RIPE 72 meeting of the DNS working group in Copenhagen. Updated: C. Root Zone ZSK Size Increase, adds a brief update from ICANN on the status of the change to the KSK which will follow the ZSK size change. H. Panel on DNSSEC Algorithm Flexibility, adds a list of panelists Dave On behalf of the chairs === Session one, Thursday 26 May, 14:00-15:30 === A. [05] Administrivia - Agenda bashing - Review of action items - Approval of previous minutes B. [25] RIPE NCC Report, Anand Buddhdev C. [30] Root Zone ZSK Size Increase, Duane Wessels Verisign, in its role as Root Zone Maintainer, plans to increase the size of the root zone Zone Signing Key (ZSK) in 2016. The ZSK has been a 1024-bit RSASHA256 key since the initial deployment of DNSSEC to the root zone in 2010. In the latter half of 2016, the ZSK size will be increased to 2048-bits. In this presentation we will outline the schedule for the change, describe various technical and non-technical details for implementing the change, describe how the change will affect root zone response sizes, and our plans for emergency fallback to a 1024-bit in the unlikely event it should be necessary. At the end of this discussion, there will be a very short presentation by ICANN about the status of the change to the KSK that will happen after the ZSK size change. D. [25] QNAME Minimization in Unbound, Ralph Dolmans This talk is about the QNAME minimisation implementation in Unbound. QNAME minimisation is a technique to improve DNS privacy by limiting the amount of privacy sensitive data exposed to authoritative nameservers. Although resolving using QNAME minimisation is not strictly forbidden in the original DNS RFCs, not all nameservers handle these queries the way they should. Unbound is shipped with an implementation that will resolve queries "as usual" when broken nameservers are detected. Also covered in this talk is the effect of QNAME minimisation on the number of queries, and some side benefits of QNAME minimisation. E. [05] Followup from Plenary topics - What’s so hard about DNSSEC?, Paul Ebersman === Session two, Thursday 26 May, 16:00-17:30 === F. [25] BIND 9.11 Release Update, Vicky Risk BIND 9.11, the first new major version in over 2 years, will be in alpha testing during RIPE, and is scheduled for release this summer. This version will include a new database api, contributed by RedHat, a new provisioning mechanism called Catalog zones, improvements to RNDC, an IPv6 bias, and the DNSSEC negative trust anchor, among other things. We will also give an update on BIND performance testing at ISC, and would like to discuss a possible change in the open source licensing for BIND. G. [05] DNS Privacy Public Resolver Proposal, Allison Mankin/Sara Dickinson Proposal that RIPE operate the first DNS over TLS privacy-enhanced public recursive to provide service to the community and to research additional privacy enhancing mechanisms. H. [55] Panel on DNSSEC Algorithm Flexibility Ondřej Surý, Moderator Lars-Johan Liman, Netnod, Panelist Marco d'Itri, Seeweb, Panelist Dave Knight, Dyn, Panelist Phil Regnauld, Network Resource Startup Center, Panelist A panel with representatives of DNS Operators and DNS Hosters, discussing the challenges of introducing new and deprecating old DNS features and DNS(SEC) algorithms. The panel will discuss the deployment of new DNS standards at the customer DNS servers. I. [05] AOB

1 0

RIPE Policy Proposal 2016-03 Affects Reverse Delegation for Allocations from IPv4 Pool
by Marco Schmidt 17 May '16

17 May '16

Dear colleagues, A new RIPE Policy proposal, 2016-03, "Locking Down the Final /8 Policy" is available for discussion on the Address Policy Working Group mailing list. The goal of this proposal is to limit IPv4 from the remaining address pool to one /22 per LIR (regardless of how it was received). These allocations will receive a separate status with several restrictions. As this proposal introduces restrictions for the reverse delegation of these IPv4 ranges, we would like to notify the DNS Working Group and invite you to discuss the proposal on the Address Policy Working Group mailing list. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-03 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 15 June 2016. Regards, Marco Schmidt Policy Development Officer RIPE NCC

1 0

RIPE70 minutes
by Jim Reid 12 May '16

12 May '16

Colleagues, here are the minutes from our meeting in Amsterdam last year. My apologies for the unacceptable delay in getting these circulated. Please let us know if there are any errors or omissions. DNS WG - Session 1 RIPE 70 13 May 2015 WG co-Chairs: Peter Koch, Jim Reid, Jaap Akkerhuis Scribe: Emile Aben A. Administrivia Peter Koch opened the session and the minutes of the previous meeting were approved. B. RIPE NCC Report - Anand Buddhdev and Romeo Zwart, RIPE NCC https://ripe70.ripe.net/presentations/75-RIPE70_AnandBuddhdev_DNS_Update.pdf Lars Liman, Netnod, noted that the old scripts won't go away even if visualisations were removed. Romeo answered he was aware of that. George Michaelson, APNIC, expressed interest in query rates for AS112, He was surprised by seeing 10% of queries over IPv6. Anand said he saw similar numbers for other authoritative servers. Jim Reid suggested putting a 'this is going away' sign on the old DNSMON visualisations. Romeo responded that was already done, and said the plan is to make landing page for old DNSMON a redirect to the new DNSMON. C. IETF Report Peter made the room aware of a virtual interim meeting of the IETF dns-ops group. Minutes of this meeting are available online: https://www.ietf.org/proceedings/interim/2015/05/12/dnsop/minutes/minutes-i… D. Knot DNS 2.0 - Status Update - A New Major Version Introducing Updated DNSSEC - Jan Vcelak, CZ.NIC https://ripe70.ripe.net/presentations/71-ripe70-vcelak-knot.pdf Olafur Gudmundsson, Cloudflare, asked if key management is time driven or predicate driven. Jan said they plan to provide hooks so external scripts can do various checks. Jan further explained that if a key server is down, steps in key management are postponed. Patrik Falstrom, Netnod, said he likes to have callback mechanism so it's possible to have external software react to key management events. E. Test Cases for Validating a DNS Delegation - A Step Towards Best Practice - Sandoche Balakrichenan, AFNIC https://ripe70.ripe.net/presentations/83-TRTF-RIPE2015.pdf Sebastian Castro, NZRS, said they have code ready for a discovery check, and wanted to clarify if only compliance checks were wanted, or also discovery checks. Sandoche responded that if there was code and consensus that this should be added, it would be added. Jelte Janssen, SIDN, commented that he liked the effort and said it's probably good if tool sets can have slightly different focus. F. DNSSEC ECDSA Algorithm Use and Acceptance - Olafur Gudmundsson, Cloudflare https://ripe70.ripe.net/presentations/85-Alg-13-support.pdf Anand responded to Olafur’s presentation with the promise that for next meeting all resolvers will have ECDSA support. Anand asked if Cloudflare could contribute in making validating with ECDSA faster. Olafur responded they have code for OpenSSL to speed things up. Geoff Huston, APNIC, said he kept on hearing there is no DNSSEC out there, but he sees 25% of users do validate. He also said that lack of ECDSA support went from one in three last September to one in five now, and thanked Olafur for the efforts in making that happen. G. DLV Sunset - Jim Martin, ISC https://ripe70.ripe.net/presentations/81-RIPE-DLV-timeline-20150513.pdf George Michaelson suggested a shorter time line for the DLV sunset. He also asked what the resolver side failure mode is when the server stops responding. Jim Martin said it was SERVFAIL if you are running BIND. Warren Kumari, Google, thought that because of Jim's presentation the number of DLV participants would drop and would be interested in seeing the number of participants on 14 May. Jim Reid said he found the time line for sunset quite reasonable with regards to software packaging, and thanked ISC for bringing about the long overdue death of DLV. He also brought up the issue of DLV code in BIND and suggested ISC remove it from the next appropriate BIND release. Jim Martin responded he would take that suggestion to the developers at ISC. ———— DNS Working Group - Session 2 RIPE 70 14 May 2015, 9:00 WG Co-Chairs: Jim Reid, Peter Koch, Jaap Akkerhuis Scribe: Florian Obser H. Knot Resolver – A More Thorough Introduction - Marek Vavruša, CZ.NIC https://ripe70.ripe.net/presentations/121-knot-resolver-ripe70.pdf Ed Lewis, ICANN, asked if the resolver can learn a new trust anchor for the root zone. Marek answered that he didn't talk about DNSSEC because it doesn't validate yet. Jim Reid asked when the software will be released for general use. Marek said that he wants to have it production ready by the end of the year, maybe earlier and that there is a release plan on the web site. I. Network-Tuning for DNS Zone Transfers in (lossy) Long Fat Networks - Marco Prause, DENIC https://ripe70.ripe.net/presentations/123-TuningZoneTranfers4LFNs.pdf Ed Lewis asked what kind of records are in the IXFR and if they are mostly to be removed RRSIGs. Marco confirmed that this is the case. Matthijs Mekking, Dyn, said that he looked into improving IXFRs by not transferring huge amounts of deleted signatures but he couldn't find real live scenarios that suffer from this. Lars Liman, Netnod, asked if other kernels besides Linux have implementations for different TCP congestion control algorithms. Marco said that the congestion control algorithm can be changed in FreeBSD but he wasn't sure if TCP-Hybla is available. Jim Reid asked if there was any other way to improve performance. Marco said that he was changing the TCP window size and other kernel parameters but real improvement were only achieved with changing the congestion control algorithm. J. Root Zone KSK Rollover - Ed Lewis, ICANN https://ripe70.ripe.net/presentations/86-DNSOARCRIPE70slides-submission2.pp… Marek Vavruša, CZ.NIC, asked if there are any plans to change the key parameters or do a algorithm roll over or just roll the old key. Ed responded that yes, algorithm roll over was considered and that he's not saying no to anything at this point and is open for all suggestions. Marek pointed out that he is concerned about increased response sizes. Geoff Huston, APNIC said that his presentation will address that. Sam Weiler, Parsons, wanted to make sure that people look at CDS (RFC 7344). Jim Reid asked how people can make further observations or comments known to ICANN. Ed said that the formal way is the public comment period. The design team is meeting and will produce a document. The formal way is to respond to that. Jim then asked what if someone wants to give comment to the design team while they are working. Ed responded that anyone can speak to the design team and they are on the relevant mailing lists. He continued that this is an informal way of taking part in the discussion and consulting the community. The formal approach will be via the public comment period. Matthijs Mekking said that the rollover had been discussed at DNS-OARC and that the discussion there has been archived. Peter Koch, DENIC, observed that people in the Working Group are aware of RFC5011 and if they are not running it they can either manually change their trust achchor configuration or migrate to RFC 5011 aware resolvers. He asked what the vision is for the long tail that might be affected by the root key rollover, Ed responded that RFC5011 is only one tool. There are other options, for example the IETF has published a trust inchor Internet Draft. He said that ICANN are trying to understand who is consuming root trust anchor information. Ultimately there is stuff out there that will break and he said that ICANN won't know how to reach the person that will responsible for that stuff. He continued that at one point it is hard to know how much responsibility we have to make sure that everybody is perfectly upgraded. He said that they don't even have tools to test. He said he can't find out if a person has the new trust anchor without breaking that person's setup and that person then complains. And he doesn't want that ability. He said that this is an open question. Peter Koch pointed out that this is as much a communication exercise as it is an engineering exercise. Ed agreed with this. Peter also pointed out that we need to be careful because if too much stuff breaks this could lead to further DNSSEC push back. Stephan Lagerholm, speaking for himself, asked if there is any work being done to mitigate against additional risks known since Snowden. He gave several examples of mistrust against DNSSEC in the community and asked if there is anything that can be done during this key roll over to help restore trust. Ed responded that the design team was looking at different algorithms but more from the size perspective. He thanked Stephan for bringing this up because the design team might not have looked at mitigations for this particular problem space. Warren Kumari, Google, responded to what Peter said by pointing out that there was supposed to be a public outreach since at least 2013. Ed remarked that a time machine was under construction. K. Tyre-kicking the DNS - Geoff Huston, APNIC https://ripe70.ripe.net/presentations/130-2015-05-14-dns-xpmts.pdf Alain Durand, ICANN, asked what the reason for IPv6 enabled resolvers querying over IPv4 is. Is it the same thing as with eye ball software that tries IPv4 and IPv6 and goes with the fastest answer or is it hard coded? Geoff said that he doesn't see exploratory round trip probing and that he thinks that it is hard coded. He went on to say that he couldn't find this in the DNS resolver code but the behaviour indicates a solid preference for A before AAAA. Alain pointed out that there are only a few resolvers people are running and if Geoff asked the resolver implementers what they are doing. Geoff said he hadn't done this yet and pointed out there are resolver implementers in the room. An unidentified attendee said they prefer IPv4 for resolution. Jared Mauch, NTT, said that in many networks there is no traffic engineering for IPv6 so if resolvers were doing RTT probing they would find that the IPv6 path is slightly shorter. He went on to say that resolvers probably have the IPv4 answer cached already and then go with that. Geoff said that during DNS-OARC it was mentioned that resolvers like to run red hot. So when IPv4 answers are already cached this becomes a self fulfilling prophecy. He continued that this seems to be a safe thing to do since everybody is scared about IPv6 path MTU problems. Marek asked what happens if one changes the order of glue. Geoff responded that he only tried IPv6 only. He said that he played with glue ordering in previous experiments and the experience was that IPv4 seems to be hard coded preferred. Marek said that some resolvers fetch the IPv4 address first. Geoff asked what the knot resolver is doing. Marek responded that knot fetches both and then decides on the round trip time. Z. Wrap Up - WG Co-Chair Appointment Process Jim Reid said that all Working Groups have been trying to come up with a process for appointing new working group chairs. The DNS working group has reached a point with some kind of silent consensus for a proposal that has been put out a week ago. He said that it would be helpful for people to voice their support rather than relying on the principle of silence implying consent. He continued to say that if the working group doesn't speak up it will be adopted in time for RIPE 71. People who are interested in standing for as co-chair should speak to the current group chairs. Jim thanked the NCC staff, the scribe, the person taking care of the chat room and the stenographer. With that he closed the session.

1 0

RIPE 72 DNS WG Agenda
by Dave Knight 29 Apr '16

29 Apr '16

Colleagues, Here’s the agenda for the RIPE 72 meeting of the DNS working group in Copenhagen. We expect to send an update regarding the participants in the panel discussion closer to the meeting, but otherwise the following should be just about definitive. Dave On behalf of the chairs === Session one, Thursday 26 May, 14:00-15:30 === A. [05] Administrivia - Agenda bashing - Review of action items - Approval of previous minutes B. [30] RIPE NCC Report, Anand Buddhdev C. [25] Root Zone ZSK Size Increase, Duane Wessels Verisign, in its role as Root Zone Maintainer, plans to increase the size of the root zone Zone Signing Key (ZSK) in 2016. The ZSK has been a 1024-bit RSASHA256 key since the initial deployment of DNSSEC to the root zone in 2010. In the latter half of 2016, the ZSK size will be increased to 2048-bits. In this presentation we will outline the schedule for the change, describe various technical and non-technical details for implementing the change, describe how the change will affect root zone response sizes, and our plans for emergency fallback to a 1024-bit in the unlikely event it should be necessary. D. [25] QNAME Minimization in Unbound, Ralph Dolmans This talk is about the QNAME minimisation implementation in Unbound. QNAME minimisation is a technique to improve DNS privacy by limiting the amount of privacy sensitive data exposed to authoritative nameservers. Although resolving using QNAME minimisation is not strictly forbidden in the original DNS RFCs, not all nameservers handle these queries the way they should. Unbound is shipped with an implementation that will resolve queries "as usual" when broken nameservers are detected. Also covered in this talk is the effect of QNAME minimisation on the number of queries, and some side benefits of QNAME minimisation. E. [05] Followup from Plenary topics - What’s so hard about DNSSEC?, Paul Ebersman === Session two, Thursday 26 May, 16:00-17:30 === F. [25] BIND 9.11 Release Update, Vicky Risk BIND 9.11, the first new major version in over 2 years, will be in alpha testing during RIPE, and is scheduled for release this summer. This version will include a new database api, contributed by RedHat, a new provisioning mechanism called Catalog zones, improvements to RNDC, an IPv6 bias, and the DNSSEC negative trust anchor, among other things. We will also give an update on BIND performance testing at ISC, and would like to discuss a possible change in the open source licensing for BIND. G. [05] DNS Privacy Public Resolver Proposal, Allison Mankin/Sara Dickinson Proposal that RIPE operate the first DNS over TLS privacy-enhanced public recursive to provide service to the community and to research additional privacy enhancing mechanisms. H. [55] Panel on DNSSEC Algorithm Flexibility, Ondřej Surý et al A panel with representatives of DNS Operators and DNS Hosters, discussing the challenges of introducing new and deprecating old DNS features and DNS(SEC) algorithms. The panel will discuss the deployment of new DNS standards at the customer DNS servers. The proposed moderator is Ondřej Surý, the members of the panel are yet to be determined and will be announced in a separate update closer to the meeting. I. [05] AOB

1 0

Additional DNS service capacity for ripe.net zone
by Romeo Zwart 26 Apr '16

26 Apr '16

Dear all, Over the last year we have seen an increase in the frequency of excessive traffic towards the RIPE NCC DNS infrastructure. Our servers generally absorb peak loads without an impact on our DNS services. However, to be better prepared for extreme traffic floods, we will work with an external party to provide additional DNS service capacity for serving the ripe.net zone. More detail can be found here: https://labs.ripe.net/Members/romeo_zwart/update-on-ripe-ncc-authoritative-… We always welcome your feedback. Please send any comments that you have to: <romeo.zwart(a)ripe.net> or alternatively post to the list. Kind regards, Romeo Zwart

2 2

IDN registration question
by Shane Kerr 22 Apr '16

22 Apr '16

All, This isn't strictly about DNS in the RIPE region, and is perhaps 4000 years out of date, but I don't really know where to ask. I noticed that VeriSign supports IDN registration using Egyption hieroglyphs: https://www.verisign.com/assets/idn/idn-egyptian-hieroglyphs.html However, their own web site doesn't seem to allow me to register a name using that character set, calling it "temporarily unavailable". I tried a few registrars but I get things like "𓎟𓀀 contains invalid characters" or the like, some say things like "ӎ߰Ӏ.com is not available" (clearly their character handling needs some tweaking, since they're munging my requested domain name). Neither DuckDuckGo nor Google seemed to help me find a list of which registrars support which languages or character sets. Does anyone have any tips, or do I need to start my own registrar? I'm also happy to use another TLD, but the Egyptian ccTLD seems more concerned with Arabic than hieroglyphs. Cheers, -- Shane

8 10

Last call for presentations and Draft programme for RIPE 72
by Benno Overeinder 02 Apr '16

02 Apr '16

Colleagues, A list of currently accepted RIPE 72 presentations is now published at: https://ripe72.ripe.net/programme/meeting-plan/draft-programme/ There are still few slots remaining for a final RIPE 72 programme and RIPE Programme Committee will accept new proposals until 15 April 2016. This is our last call for you to submit your proposals. You can find the CFP for RIPE 72 below, or at https://ripe72.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. Kind regards, Benno Overeinder RIPE PC Chair https://www.ripe.net/participate/meetings/ripe-meetings/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 72 will take place from 23-27 May 2016 in Copenhagen, Denmark. 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 72. See the full descriptions of the different presentation formats, https://ripe72.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 15 April 2016. 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 in operations - Commercial transactions of IPv4 addresses - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange 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 The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe72.ripe.net/submit-topic/submission-form/. - Lightning talks should also be submitted using the meeting submission system (https://ripe72.ripe.net/submit-topic/submission-form/) 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. - Due to potential technical issues, presenters/panellists should be physically present at the RIPE Meeting. 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

L-Root IPv6 address renumbering
by John Bond 21 Mar '16

21 Mar '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is advance notice that there is a scheduled change to the IPv6 addresses in the Root Zone for the L root-server, also known as L.ROOT-SERVERS.NET, which is administered by the ICANN. The current IP addresses for the L.ROOT-SERVERS.NET service are: * 199.7.83.42 * 2001:500:3::42 As of March 23, 2016, the new IP addresses for the L.ROOT-SERVERS.NET service will be: * 199.7.83.42 * 2001:500:9f::42 The change will be implemented on the root zone on March 23, 2016 however the new address is already operational. We encourage DNS infrastructure operators to update their DNS resolvers root "hints” file. New hints files will be available at the following URLs once the change has been formally executed on March 23, 2016: * http://www.internic.net/domain/named.root * http://www.internic.net/domain/named.cache John Bond Lead DNS Engineer ICANN -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJW4rVbAAoJEItBgrEZay0nyMcP/1OVBoUzhkxptHrJFDH+beb1 wovDcvuN5/bygT4jLPE77OIn15jh/ynVqSdXKR/NOWuiNstlz+4OKnIABsWCKIP0 jo3FGzgt5i2cVE0ZW4QF83O+wykU9NdR4sHuKEz7bE1yHLEg5MbOgw4D3BK3T8E+ 7ATathGGK8kPZpykYQkPAayKh6RNipRIh3NdKqgkjXi2eiRbkmkR2+4zeZbw7kL4 Unu6v2h1Awy6qlMA6RWzxVt66/GgNWPJTGBBXeHw9n8zKZFWl+1hZLHsVH5iv1dn nIsKQGoww11Sa+kzirT5yDmaDBzJlTEvAOhaN0VSeoXKvh49Lhoo94g7NmB+4/9B 8va0l6adTAWFh16U1qdQomJygM8N1QfamXGmIP8Nq+cx+sJrVnpPv7k/DL9lGIfP 6YjO5TZfGfQbUlMZkvV0y91QfB1SuW6NMt+A683WKAGZcyrbD0e4nDbuSWON99+m GDG2TLsAaEkzhaNSGd5Rh32+giMsLCQ0DJWfvmqylbrBEFjZPF/t3Q7rR1Z6iFii EhRc3VQzQYoieMJs045w7l9VHMwIXUjj1yff4CZhMNQ7zzFIfRTikD4LSwOkGOSk ebqeh1SQ7+gO/kokv/mxu/SRqC3VKiE5gZujwJOTsmXU3gan2SGlbIMTAKi89ESk 0f+2rkyECg3sLM8B7O5t =QwRU -----END PGP SIGNATURE-----

2 2

Call for contributions to the RIPE 72 meeting of the DNS WG
by Dave Knight 01 Mar '16

01 Mar '16

Dear colleagues, The RIPE 72 meeting in Copenhagen is a mere 12 weeks and we’d like to form a draft agenda soon. Please submit your presentation ideas, or suggestions for discussions to <dns-wg-chairs(a)ripe.net <mailto:dns-eg-chairs@ripe.net>>. Thanks! dave, on behalf of the working group chairs

1 0