- dns-wg - mailman.ripe.net

Update to DNSSEC Policy and Practice Statement (DPS)
by Wolfgang Nagele 19 Oct '11

19 Oct '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear colleagues, Today we have updated our DNSSEC Policy and Practice Statement (DPS). The most notable change to the policy has been a change to the Key Usage Period section. We have extended the usage period of a Key Signing Key (KSK) to one year from previously 6 months. You can find the updated version here: http://www.ripe.net/data-tools/dns/dnssec/dnssec-policy-and-practice-statem… Regards, Wolfgang Nagele, RIPE NCC -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAk6fE5QACgkQjO7G63Byy8fI6ACfa+zLgmkbaP6gK98BQsX0G5HG qpEAnRI7714fx+ANIPmJkL6qBQplsft1 =auU8 -----END PGP SIGNATURE-----

1 0

Variant Issues Project -- Case Study Reports
by Leo Vegoda 17 Oct '11

17 Oct '11

Hi, ICANN is currently conducting a public comment period on six case studies of individual scripts to investigate any issues that need to be resolved to facilitate a good user experience for IDN variant TLDs. The public comments received will inform the formulation of the combined issues report. If you have an interest in the possibility of IDN variant TLDs, please provide comments by 14 November. The Latin, Greek & Cyrillic Case Study Teams' Issues Reports and public comment forums can be found at: http://www.icann.org/en/public-comment/idn-vip-latin-07oct11-en.htm http://www.icann.org/en/public-comment/idn-vip-greek-07oct11-en.htm http://www.icann.org/en/public-comment/idn-vip-cyrillic-06oct11-en.htm Regards, Leo

1 0

PROBLEM_NO_REVERSE_MAPPING for entity
by Antonio Ferrara 14 Oct '11

14 Oct '11

I apologize if I re-post this message. But I had problems with the mail server and I'm not sure that it was posted. Hi, I have this zone: uniplan.it $ORIGIN . $TTL 3600 ; 1 hour uniplan.it IN SOA uniserv.uniplan.it. admin.uniplan.it. ( 2011101402 3600 1800 1209600 86400 ) $TTL 86400 ; 1 day NS uniserv.uniplan.it. NS uniserv1.uniplan.it. NS webserver.uniplan.it. $TTL 3600 ; 1 hour A 217.20.0.2 MX 10 uniserv.uniplan.it. $ORIGIN uniplan.it. axis2100 A 217.20.0.15 board A 217.20.0.140 clessidra A 217.20.0.32 $ORIGIN clessidra.uniplan.it. www A 217.20.0.32 $ORIGIN uniplan.it. frattamaggiore A 85.44.177.45 $ORIGIN frattamaggiore.uniplan.it. www A 85.44.177.45 $ORIGIN uniplan.it. ftp CNAME uniserv gargano A 217.20.0.73 $ORIGIN gargano.uniplan.it. www A 217.20.0.73 $ORIGIN uniplan.it. gesema.uniplan.it. IN A 85.33.176.119 $ORIGIN gesema.uniplan.it. <http://www.gesema.uniplan.it> www.gesema.uniplan.it. IN A 85.33.176.119 $ORIGIN uniplan.it. <http://www.gesemaeco> www.gesemaeco A 85.18.249.93 gm A 172.16.1.246 gm1mex A 172.16.80.61 gm2mex A 172.16.1.222 gm3mex A 172.16.1.222 localhost A 127.0.0.1 mailserver A 217.20.0.31 $ORIGIN mailserver.uniplan.it. mailserver A 217.20.0.31 $TTL 86400 ; 1 day $ORIGIN uniplan.it. $TTL 3600 ; 1 hour nt01 A 217.20.0.179 nt02 A 217.20.3.20 nt03 A 217.20.1.150 $TTL 86400 ; 1 day ovi A 217.20.0.31 $TTL 3600 ; 1 hour pomilia A 151.58.32.85 $ORIGIN pomilia.uniplan.it. www A 151.58.32.85 $ORIGIN uniplan.it. posta A 217.20.1.150 $ORIGIN posta.uniplan.it. www A 217.20.1.150 $ORIGIN uniplan.it. postfix A 217.20.0.76 radio A 217.20.0.73 $ORIGIN radio.uniplan.it. www A 217.20.0.73 $ORIGIN uniplan.it. rcis-01 A 217.20.0.1 rcis-02 A 217.20.0.14 rliv01-02 A 217.20.0.10 rliv02-02 A 217.20.0.13 rliv03-02 A 217.20.0.12 rliv04-02 A 217.20.0.11 sanmarcocavoti A 172.16.40.206 $ORIGIN sanmarcocavoti.uniplan.it. www A 172.16.40.206 $ORIGIN uniplan.it. spin0 A 217.20.1.8 spin1 A 217.20.3.3 spin2 A 217.20.3.2 spin3 A 217.20.3.103 www.radio.tanagro A 85.44.172.158 $TTL 14400 ; 4 hours uniplan TXT "v=spf1 a mx -all" $TTL 3600 ; 1 hour uniserv.uniplan.it. IN A 217.20.0.2 uniserv1.uniplan.it. IN A 217.20.0.3 watch02 A 217.20.0.176 watch03 A 217.20.0.177 weblinux A 217.20.0.72 webserver.uniplan.it. IN A 217.20.0.30 www CNAME uniserv www4 A 217.20.0.73 gol.uniplan.it. IN A 217.20.1.150 mailserver-dns.uniplan.it. IN A 217.20.0.2 uniserv.uniplan.it. PTR 217.20.0.2 uniserv1.uniplan.it. PTR 217.20.0.3 webserver.uniplan.it. PTR 217.20.0.30 I have created this reverse zone: 217.20.0. $ttl 38400 @ IN SOA uniserv.uniplan.it. system.uniplan.it. ( 2011101403 10800 3600 604800 38400 ) 2 IN NS uniserv.uniplan.it. 3 IN NS uniserv.uniplan.it. 30 IN NS uniserv.uniplan.it. 2 IN PTR uniserv.uniplan.it. 3 IN PTR uniserv1.uniplan.it. 30 IN PTR webserver.uniplan.it. I have tested the zone with RIPE Zone Delegation Checker and I have this error: >Check uniserv.uniplan.it details PROBLEM_NO_REVERSE_MAPPING for entity uniserv.uniplan.it >Args: 217.20.0.2, uniserv.uniplan.it >Check uniserv1.uniplan.it details PROBLEM_NO_REVERSE_MAPPING for entity uniserv1.uniplan.it >Args: 217.20.0.3, uniserv1.uniplan.it >Check webserver.uniplan.it details PROBLEM_NO_REVERSE_MAPPING for entity webserver.uniplan.it >Args: 217.20.0.30, webserver.uniplan.it Can you help me to solve this error? Thanks.

2 1

Moneytizing error pages using DNS
by Kostas Zorbadelos 10 Oct '11

10 Oct '11

Greetings to all, as you might guess from the subject, this mail is about a bad DNS trick. Our commercial people have been approached by some people in a subsidiary company trying to sell a "moneytizing product" that takes advantage of user error pages when serfing the web. In the subsidiary company the solution is already deployed in their production and it also involves cooperation with a search engine. The important thing is that Google refused to cooperate with them and they expressed their position against moneytizing error pages. Of course, the solution involves NXDOMAIN remapping. We as technical people are against the idea. Apart from technical implications that are difficult to explain to non-technical people, we would like to have some arguments supporting our position. Since a lot of people in this list might already have come across the problem (and some might already have implemented such a thing) I would be interested to hear your oppinions. Apart from respected voices expressing their opposition to such techniques [1], I would be interested in other arguments such as legal implications, costs or any other arguments anyone has used in a similar situation. By the way, there is an expired Informational rfc about the subject [2]. Cheers, Kostas [1] http://queue.acm.org/detail.cfm?id=1647302 [2] http://tools.ietf.org/html/draft-livingood-dns-redirect-03 -- Kostas Zorbadelos twitter:@kzorbadelos http://gr.linkedin.com/in/kzorba ---------------------------------------------------------------------------- () www.asciiribbon.org - against HTML e-mail & proprietary attachments /\

9 13

[Jim Reid personal contact, rest please ignore] spam defences
by Kostas Zorbadelos 07 Oct '11

07 Oct '11

First of all apologies in advance for this. This is a message addressed to Jim Reid. I have no other means of personal communication, you seem to block my main OTENET address plus my gmail address (to both addresses I know for you, since the one redirects to the other). If you care, either whitelist the domain "eng.otenet.gr" or provide me another address with no "paranoid" SPAM defenses. Sorry for the noise on the list. Regards, Kostas -- Kostas Zorbadelos twitter:@kzorbadelos http://gr.linkedin.com/in/kzorba ---------------------------------------------------------------------------- () www.asciiribbon.org - against HTML e-mail & proprietary attachments /\

1 0

Read on RIPE Labs: F-root IPv6 Route Leak - the DNSMON View
by Mirjam Kuehne 03 Oct '11

03 Oct '11

Dear colleagues, Prompted by a discussion on the nanog mailing list about an F-root IPv6 route leak, we were curious what DNSMON shows about that event. Read an article Emile Aben just published on RIPE Labs: http://labs.ripe.net/Members/emileaben/f-root-route-leak-the-dnsmon-view If you have any comments or questions, please feel free to post them under the article. Kind Regards, Mirjam Kuehne RIPE NCC

1 0

RFC 2317-style Reverse DNS Delegation in the RIPE Database
by Anand Buddhdev 21 Sep '11

21 Sep '11

[Apologies for duplicates] Dear colleagues, In April 2011, Denis Walker sent a proposal to the DNS and Database Working Groups outlining some reverse DNS-related changes to the RIPE Database. You can see the full proposal here: http://www.ripe.net/ripe/maillists/archives/db-wg/2011/msg00080.html I'm happy to report that this proposal has been fully implemented. This means that: - Dashes in the third octet of a DOMAIN object are no longer allowed - Dashes in the fourth octet are now allowed A dash in the fourth octet allows for RFC 2317-style reverse DNS delegation for Provider Independent (PI) address allocations which don't fall on octet boundaries. For this second change, we converted all existing delegations into appropriate DOMAIN objects in the RIPE Database. We will update the reverse DNS "how-to" on the RIPE NCC website over the next few days. If you have any questions, please send an email to <dns(a)ripe.net>. Regards, Anand Buddhdev DNS Services, RIPE NCC

1 0

Read on RIPE Labs: Hacking Away at the Internet's Security
by Mirjam Kuehne 20 Sep '11

20 Sep '11

Dear colleagues, Prompted by a recent news story on hacking into the computer systems of a security firm, Geoff Huston published an article on RIPE Labs titled "Hacking Away at the Internet's Security": http://labs.ripe.net/Members/gih/hacking-away-at-the-internets-security If you have any comments or questions, please feel free to post them under the article. Kind Regards, Mirjam Kuehne RIPE NCC

1 0

Draft minutes from RIPE62
by Jim Reid 05 Sep '11

05 Sep '11

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_ed… 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_R… 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.

1 0

Wanted: Agenda items
by Jaap Akkerhuis 03 Sep '11

03 Sep '11

Dear all, How time flies. End of October the dns-wg will meet again, this time in Vienna. Therefore we are asking again for agenda items. Please send you suggestions to the dns-wg chairs or me directly. jaap

1 0