- dns-wg - mailman.ripe.net

Tweaks to RIPE 663: Secondary DNS Service for ccTLD Operators
by Shane Kerr 26 May '16

26 May '16

Hello, Anand just mentioned at his presentation at RIPE 72 that the RIPE NCC is now implementing RIPE 663: https://www.ripe.net/publications/docs/ripe-663 There were a couple of suggestions for tweaks to that: 1. Gaurab and I think that there should be an exemption for ccTLD who do not currently have IPv6 service. (There are a few tens of ccTLD who do not yet have IPV6, and I would like the RIPE NCC to be able to help them get IPv6 service if they want it.) 2. Gaurab mentioned that there are some ccTLD who have 3 servers but they are all in the same network. The document should be flexible in order to insure network diversity. I know the document is less than 6 months old and just being implemented now, but maybe we can revise it to include these two changes? I'm happy to do a quick pass at text for this if that makes sense. Cheers, -- Shane

3 3

Re: [dns-wg] DNS Privacy
by Sara Dickinson 26 May '16

26 May '16

Hi All, As you will probably know RFC7858 "Specification for DNS over Transport Layer Security (TLS)” was recently published as a result of work in the IETF DPRIVE working group. Reference implementations of this Standard (and associated supporting features such as those specified in RFC7766) are in progress. However, since this is a significant evolution for DNS, the first stage in moving towards a deployable production solution would seem to be to run one (or preferrably a few) DNS Privacy servers as research experiments. This would allow practical experience of running the service at scale and serve as a research platform for other DNS Privacy activities. A number of organisations have expressed interest in running such a DNS Privacy enabled server and we would like to start a discussion in the RIPE community to see if there is similar interest from within this group. We would very much like to hear from interested parties who might consider becoming involved in this effort. Additionally, there have also been exploratory discussions around the possibility of RIPE NCC running such a service as a limited fixed term pilot, if there was sufficient support from the RIPE members. This seems to be something that would fit well with the mission of the RIPE NCC and we would like to hear views from the community about this proposal. There will be a short presentation in the RIPE DNS working group tomorrow on this topic, so please participate if you are interested. Regards Sara.

4 5

Yeti DNS and the RIPE NCC
by Shane Kerr 25 May '16

25 May '16

Dear DNS folks, As many of you are aware, a group of researchers and other interested people and groups has been building and operating a root server testbed over the past year. This is the Yeti DNS project: http://yeti-dns.org/ We have just finished our first experiment, and have started our second one. The network has 25 root servers from 14 different organizations, along with a number of recursive resolvers configured to use them. We have approached the RIPE NCC to encourage them to run a Yeti root server, and they feel that this is something that we should engage with the RIPE community about. We are still looking for more Yeti root operators, and we think that the RIPE NCC would be awesome in this capacity, given their unique role in the DNS world (they are the only RIR who is also a root operator, plus they do a lot of work supporting various ccTLD). Personally I think that the goals of the Yeti project fit in very well with the mission of the RIPE NCC. Please let us know what you think about this idea. I'm happy to answer any questions about the project or what it would mean for the RIPE NCC to run a Yeti root server. Cheers, -- Shane

10 13

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