Colleagues, here are the draft minutes from the last RIPE meeting. Please speak up if there are any errors or omissions. Thanks. DNS WG – Session 1, Grand Ballroom, Wednesday 4 May 11:00 A. Administrivia The session started on time with Peter Koch, one of the Working Group co-Chairs, introducing himself and presenting the items on the agenda. He asked attendees to approach him and the other co-Chairs with any feedback or to write them an e-mail. B. Report from the RIPE NCC – Wolfgang Nagele The first talk was by Wolfgang Nagele from the RIPE NCC, reporting about the status and projects of the DNS Services department. The presentation is available here: http://ripe62.ripe.net/presentations/85-RIPE62_WolfgangNagele_DNS_update_edi... Jim Reid asked a question not only to Wolfgang but the whole Working Group, wondering if there was a need for better mechanisms or processes for reporting validation failures back to the zone owners or signers. Wolfgang responded that they had considered the issue in relation to e164.arpa and outages that in the future could even prevent people from communicating about the problem. No good solution for that had been found yet, and he said he would welcome input both from the DNS Working Group and the community outside RIPE on what could be done about it. Peter Koch then had a question about the transition of the reverse space in-addr.arpa to the route servers to dedicated systems. He inquired whether any analysis of the query counts had been performed, and whether the reduction of the queries at the root name servers was consistent with the queries that showed up on the dedicated systems. Wolfgang replied that the queries were largely consistent, but he could not speak for every root server. However, since the RIRs were operating the system there were differences in the query loads for the new F reverse, the A reverse and so on. On the K and F instances though the drops were consistent, with no increase in traffic nor disappearing traffic being observed. The were no further questions. C. IETF Report – Peter Koch Peter Koch then stepped on the stage to present the IETF Report. The presentation is available here: http://ripe62.ripe.net/presentations/108-ietfupdate.pdf Jim Reid commented that he had heard about a DNS API BoF, and asked if it had actually taken place and if anything significant came out of it. Peter Koch replied that attempts to standardize APIs did have a history in the IETF and the IETF was kind of adverse to take out work on this because they usually point to different entities. But to his knowledge so far the group had not come up with an Internet draft or similar document. He also asked Jaap Akkerhuis for more details on the subject. Jaap responded that attendance was by invitation only and very formal, and since he had not been invited he did not know what happened. There were no further questions. D. OpenDNSSEC – Jakob Schlyter Jakob Schlyter was next with an update on the status of OpenDNSSEC. The presentation is available here: http://ripe62.ripe.net/presentations/82-ripe62-opendnssec.pdf There were no questions. E. BIND10 Live Demo – Shane Kerr Next on stage was Shane Kerr from ISC with a live demonstration of BIND 10, asking the audience to fasten their seat-belts. There are no slides for this presentation, but a recording of the demo can be seen in the webcast archives here: http://ripe62.ripe.net/archives/video/87 Peter Koch thanked Shane for giving the demonstration, then asked who would be brave enough to put the new software into production. Shane Kerr answered that it was already in production at ISC, but only for BIND 10 itself. Also a lot of developers were running it for their own vanity domains. Shane also planned to speak to the RIPE operations team and their managers to convince them to run the software on AS112, perhaps over the following weeks. He also wanted to set up for the recursive side an open revolver using BIND 10 as a revolver. There were no other questions. F. Update on .uk DNSSEC Deployment – Brett Carr Brett Carr presented an update on the .uk DNSSEC Deployment. The presentation is available here: http://ripe62.ripe.net/presentations/219-uk_DNSSEC_Status_Ripe_62.pdf John Dickinson from Sinodun Internet Technologies Ltd. asked for clarification about the rollover. He wanted to make sure he understood that they were not doing scheduled rollovers because they wanted people to use the root key and not because they were doing 5011. Brett replied that they definitely wanted people to use the root key, and they didn't want to do a rollover if there was no good reason for that, since it would just add complexities. John asked again if they were not doing 5011s, and Brett confirmed. John commented that it could be another reason for people not to need to notice, and Brett agreed. Jim Reid commented that by his understanding, sch.uk was a registry of UK schools, and Brett confirmed. Then Jim asked what would happen if the department of education decided they didn't want to use NSEC 3 but wanted to use DNSSEC Bis, what impact would that have on the presented architecture and processes. Brett said it was simple for them to do, as they could sign any of those zones with NSEC or NSEC 3. He also said they were not using a KSK or ZSK, but a single key for each zone. Then he asked any registrar or interested attendees to meet him for further talks after the presentation. There were no other questions. G. DNS Anomaly Detection – Ondřej Surý The final talk of the session was by Ondřej Surý, about DNS Anomaly Detection. The presentation is available here: http://ripe62.ripe.net/presentations/101-DNS-20110504-OS-RIPE62.pdf Richard Barnes from BBN Technologies asked for clarification about the method used: the graphs were presented for a few different query names were spikes had been observed, and as such were those query names chosen specifically, or did the algorithm automatically detect the spikes occurring? Ondřej replied that the algorithm did it automatically. There were no further questions. The session ended on time. Peter Koch thanked the presenters and reminded everyone to return for the second DNS Working Group session the next day. DNS WG – Session 2, St. John's II Room, Thursday 5 May 11:00 Jaap Akkerhuis started the session on time by introducing himself and the other two co-Chairs. He then reminding everyone the fact that the session was being recorded and stenographed and asked attendees to introduce themselves when speaking or asking a question. O. NSD4 Plans – Wouter Wijngaards The first talk was by Wouter Wijngaards, and it centered around the plans for the next version of the NSD authoritative DNS server – NSD4. The presentation is available here: http://ripe62.ripe.net/presentations/146-NSD4-RIPE62-03.pdf Peter Koch stated that one thing he liked about NSD was that it did not suffer from “featurism”. He then asked if there was a list of explicit “non-goals” for NSD4, i.e. things that would never make it into the release. He gave an example of it being dangerous to use the name server for signing, and asked for a guarantee that such a thing would never happen, or alternatively what compromises would have to be made to ensure that. Wouter Wijngaards confirmed that NSD4 was not a signer and it would not do that, therefore there was also no need for dynamic updates. While the implementation itself would not be difficult as most of the infrastructure was already there, it would just not make sense. He acknowledged the fact that many users want to have signers because they want to host zones that are signed, but that would probably have to be done by IXFR since it was already an established protocol for sending data and the right way to go. Olaf Kolkman, director of NLnet Labs commented that their goal with Unbound, NSD and also OpenDNSSEC in which they were participating was to target software to specific functions. Since signing and dynamic updates were not authoritative name server core functionality, but rather a provisioning function, the way he envisioned that going forward would be a system encompassing different pieces of software, like with OpenDNSSEC accepting the dynamic updates and NSD serving them. He also added that they were striving to find a balance between keeping NSD very simple and seeing the software used by as many people as possible; there were environments where using NSD was too hard, for example systems with 50000 zones, where restarting and recompiling the data set every time a new zone was added would not work very well. This was the kind of environment they were targeting with NSD4: making sure that adding zones was easy and that the dynamic nature of the market was well supported, while at the same time keeping the functionality bloat at a minimal level. While Jaap intervened to cut the discussion short, Olaf apologised for taking the discussion in a marketing direction. Shane Kerr from ISC asked if it was true that someone had submitted patches for NSD3 to support SQL. Wouter answered that he had no recollection of that, and Shane clarified that his question was about external contributions, he wanted to know if there was any plan on having plugins or hooks or anything like that implemented in NSD. Wouter replied that while there used to be some support for plugins in version 2.0 it was subsequently removed since nobody was using the feature and it was obviously not needed. Therefore they had no such plans for the future, however to be in the spirit of the week he mentioned they did plan to support IPv6 in NSD4. There were no further questions. P. IP6.ARPA and IN-ADDR.ARPA Changes – Dave Knight The next presentation was by Dave Knight, about the recent changes in the ip6.arpa and in-addr.arpa reverse delegation infrastructure. The presentation is available here: http://ripe62.ripe.net/presentations/161-ip6-in-addr-arpa-changes.pdf Jim Reid expressed his surprise that only the reverse IP zones were being moved. He asked why was not the whole .arpa domain moved off the route servers. Dave Knight said he had no opinion on the subject. Jaap asked if there was discussion about that, and Dave responded that he was not aware of any discussion, but it would be something for the IEB to talk about. There were no other questions. Q. Towards a Name Server Control Protocol – John Dickinson Next to speak was John Dickinson on the subject of a a Name Server Control Protocol. The presentation is available here: http://ripe62.ripe.net/presentations/166-NSCP_RIPE.pdf Jim Reid asked if there was any input from registrars about their requirements for a control protocol, since they probably had a specific set of requirements that would not fit into the conventional ISP model with hundreds of thousands of small zones instead of a single large one. John Dickinson explained that there had not been any comments about the draft at that point of any technical nature. While many people when asked directly expressed interest in such a system, getting actual comments was proving difficult, and that was one of the reasons John was giving the presentation. Erik Klein from Google admitted he had not read the actual specification, but inquired whether there was a provision for large farms of name servers in geographically diverse areas where staging was necessary when pushing complex zone updates to insure everything was transferred successfully and verified before going live. John answered that there was nothing about specific implementation in the draft, but they did have a plan about how to implement it and that the flexibility of NETCONF would make it possible to address the issue. Jaap said he remembered from the NETCONF description that there was a way for staging and final call. John added that if one were to use JuneOS, that kind of functionality was quite familiar, or alternatively the ability to not commit on rollback. There were no other questions. R. DNSSEC Client Behaviour – Sander Degen Sander Degen was next with a presentation about various timeouts caused by the behavior of name resolution clients on different Operating Systems, something that will become even more important with DNSSEC as there will be more SERVFail responses. The presentation is available here: http://ripe62.ripe.net/presentations/145-DNS_Client_analysis_presentation_RI... Kai Storbeck from XS4ALL asked if IPv6 was enabled on the presented results. Sander Degen replied that the test was performed with several combinations and IPv6 was enabled, so double the packets could be seen. Kai Storbeck commented that it would not only be double the packets, but for every search list entry there would be a try for both v6 and v4, and Sander agreed. Roy Arends from Nominet inquired about how the caching was performed in the case of BIND 9 and Unbound, if the client timed out because it did not get a response. Sander acknowledged it was a good question, and explained that while the recursor would retry the query six times, it would cache all the client requests until establishing that there would be no response so the request would not get sent back to the server any more. Roy commented that this meant the state was being kept in the cache, and Sander agreed. Shane Kerr from ISC inquired about the analysis of GLIBC that Sander mentioned and what the results were thereof. Sander answered that they could discuss that further at another time as it would take too long. Richard Barnes from BBN Technologies inquired whether they had considered how the clients reacted to invalid signatures in DNS, if all the records were returned and the protocol still worked just with an invalid signature. Sander agreed that it would be an interesting subject to study, however it did not fit into the scope of the presented research and they would like to see it in the next research. Jaap then asked whether they had looked at one particular implementation of GLIBC or whether they had compared it to others. Sander replied that they had focused on the GLIBC that was opened in the used browser (Firefox) and specifically analysed only that on a recent version of the Ubuntu OS. There were no further questions. S. Changes to JP DNS traffic by DNSSEC – Masato Minda The next presentation was by Masato Minda on the subject of DNSSEC in the .jp ccTLD. The presentation is available here: http://ripe62.ripe.net/presentations/150-dnssec-in-jp-10.pdf Jaap commented that more results will be forthcoming after they would change the sizes, and Masato replied that it would be about 1400 to 3000 maybe. There were no questions. T. HSM survey – Jakob Schlyter Jakob Schlyter was next with a talk about Hardware Security Modules (HSMs). The presentation is available here: http://ripe62.ripe.net/presentations/165-ripe62-hsm.pdf Joao Damas from ISC asked why one would invest more in protecting their key compared to protecting their zone file. Jakob Schlyter gave a short answer of “blame shift”, then expanded on it by explaining that it was all about moving risk away from operations, which could make sense in some cases and not others depending on their risk analysis. Joao then inquired if the HSM would be able to detect that a mistake had been made when signing a zone or just serve it with the wrong signature. Jakob replied that the HSM would not be able to detect such a scenario as the system is basically “garbage-in, garbage-out” so if the operator made a mistake or if there was a compromise it could serve false signatures for quite some time before the keys were rolled. However, there were some good scenarios for using HSMs in his opinion even though other people might disagree. John Dickinson from Sinodun Internet Technologies Ltd. commented that he had conducted a similar study while working for Nominet and a big difference between the various models was the quality of the documentation. In the ned he concluded that a company that was not able to write good documentation could not be trusted to write good security code. He then asked if the quality of the documentation was considered in the presented study. Jakob responded that there were two parts of the documentation – on one hand the documentation for certification which was usually pretty good, and on the other hand the end-user documentation which had varying levels of quality. While some parts of that analyses were included in the report, he would advise people to ask the vendors for documentation before buying. Jaap intervened and asked for a very short question since the time was running short. LG Forsberg from .NU Domain Ltd asked how a software signer on a decently sized server would compare in regards to performance. Jakob replied that it would depend on the number of cores and other parameters, but in general around 1000-2000 keys per second, which could as well be considered “good enough”. There were no further questions. U. The “Dancing F-Root” Story – Wilfried Woeber The final presentation was by Wilfried Woeber regarding an analysis performed on the DNS root-servers using the infrastructure provided by the RIPE NCC Atlas project. The presentation is available here: http://ripe62.ripe.net/presentations/116-Atlas-n-F-Root.pdf Joao Damas commented that the behaviour described was typical of root-servers – multi-homed layers, with multiple exit points being basically one way of looking at Anycast. He described his experience with asking GEANT to carry F-Root from more than one instance which turned out to be too complicated to do for various internal reasons, leaving the whole set of networks that depended on GEANT for accessing the Internet or parts of it at the whim of what GEANT would choose, which was not under their direct control. What they did implement was a system for rapid detection of such events that would allow network administrators to quickly pinpoint the leak by looking at AS paths, allowing them to fix it in time. Faidon Liambotis from GRNET inquired when the described problems took place. Wilfried responded that it had happened two-three weeks before the date. Faidon commented that they had seen a similar problem in 2009 with GEANT and F-Root, with v4 going to South America and v6 to Hong Kong; he notified both ISC and GEANT which resulted in them fixing the issue fairly quickly – in the end, it all boiled down to finding the right people which would now how to debug the issue. Wolfgang Nagele from the RIPE NCC added that in terms of K-Root, they used to have the same strategy with more or less specific prefixes depending on node capacities. Shortly before the date they actually decided to replace the system with one consistent prefix announcement size, because from their experience it produced more problems than it solved and it was difficult to troubleshoot. The same was true for Anycast too, since it became very hard to control when a lot of locations were involved and side-effects were impossible to estimate in advance. Jaap asked for one last quick question. Rober Kisteleki from the RIPE NCC said that he was the one responsible for the Atlas project, and it put him in a difficult situation because they had so many good ideas about the project and too little time to implement them all while also taking into account the community's desires. One of the things they were planning to do was a kind of tie-in between traceroute measurements and RTT measurements so that when a sudden change would be observed the modification in the path could be recorded and analysed; a warning system could also be implemented in relation to that. He explained that the described features would be implemented since they made a lot of sense and were the way forward. Jaap commented that looking at ICMP would be interesting, but it would only measure when the “light was on” and there was an actual response, otherwise yielding no information. Z. A.O.B. There was no other business. Jaap thanked the NCC staff for supporting the meeting and ended the session.