These are unedited transcripts and may contain errors.
Notice: Use of undefined constant steno - assumed 'steno' in /var/www/html/ripe-60/steno-transcripts.php on line 24
The DNS session commenced on the 6th of May, 2010:
CHAIR: Good afternoon everybody. This is the second slot of the domain ?? my name is Peter Koch I have the pleasure to guide you through this second part of the Working Group meeting. Come in and sit down. Expect some interesting DNS and DNSSEC stuff.
So quick look at the afternoon agenda. We have an update from OARC followed bay report on the DNSSEC study for CP devices or home devices, Matthijs will give us an update on open DNSSEC. Joao still attends the Working Group chair's meetings will speak about ?? that should be BIND 9.7 I guess, DNSSEC for humans. Andrei, on the fire flocks plug in done by CZ.NIC. David night, subject to again from nick. C Z will talk about Anycast in their DNSSEC set?up and finally any other business will be the end of the earth yesterday night. We have a pretty packed agenda I would like to invite Wayne to the stage to start with the first talk. And for the rest ?? whenever we have questions, the usual magic applies: Please go to microphone and identify yourself and if you wish, say your affiliation and this is all recorded and videotaped and you know that. Thank you.
WAYNE MacLAURIN: Good afternoon. I am the new executive director of OARC and want to go over a little bit of what we are, we have had a couple of changes and it's a chance for those of you who don't know to learn a little bit more.
DNS OARC was conceived as a membership organisation for people who work in the DNS industry, both developers, implementers, network designers or share data, deal with common problems and generally work in a secure environment.
We were established in 2004 by ISC, and funded bay grant from the NS F. We became a separate corporation a couple of years ago in 2008 and we are a nonprofit organisation. We are funded by the members and by the occasional grant. There are six members of our board and to provide oversight. We have got a little over 60 members and it's primarily the operators, we have a fair number of people come for the research and implementation communities as well.
That is a sort of a snapshot of everybody. We have both Google and the dot RUC CT L T folks have recently joined.
We have the four member elected directors, Peter, Steffann and Roy and we have two that are appointed. Suzanne wolf was appointed by ISC and mart Larson served as our chairman.
We are most well?known for our data sets, we have six years of continuous DS C summary statistics it, gathered from the root and other TLD servers. We have five years of annual 24?hour snapshots of the day in the life project, which has traffic to those key servers. Over 4 terabits and the last D IT L was over six terabits compress so it's starting to become a pretty big chunk of data to manage.
We have got do other stuff. We main a list of IP addresses that shouldn't be probed, it's our do not probe list. We have a list of open recursive resolvers, TLD zone file repository and ten plus years of root zone archives. A number of tools we have developed over the years: We have the calm ins ski, DNSSEC a for capturing and decoding, quality and performance tools as well as DNS fingerprinting tool. All available on our website S our communications resources are probably our ?? at least one of our better services; we have a list and Jabber in the DNS operations business, it's open. The secure ops list is both list server and Jabber room which is a trusted and vetted environment for the actual realtime operational matters and open primarily to the actual operators, the route servers.
DNSSEC, is something we have been doing for the last little while with ICANN to measure the DNS root signing. That is snapshot from a little while ago. We have some continuous data going up and I would assume be publishing some stuff shortly on last night's events. DNS cert, we have a position paper on that, available on our website and was submitted to ICANN along with a number of others.
Our resourcing: At the moment it's basically me as executive director. ISC handles our secretariat functions, administration and financing and it hosts our infrastructure. We have a contract engineer who does most of our system administration work and we are doing this all on about 250,000 dollars a year.
In the future we have most ?? next up is our analysis of the root zone signing study, which should be out in the next little while. We are in the middle of working on plans to update our data storage and archive infrastructure. And of course looking to expand our membership. A number of things which we need to do more of includes system administration, analytics and research and generally doing a better job of talking to our members and at the same time, out reaching to other organisations who are not currently members, registrars, TLD operator and particularly the large resolver operators as we think that is an interesting snapshot that we don't currently connect, collect a whole lot of data from. I would like to say thanks to our oat going president Keith Mitchell who spent years running this organisation and Duane Wessels who recently moved onto Verisign has provide add wealth of analytical data on various things in DNS. You can reach us at the website or if anybody is interested I will be hanging around for the rest of the day and into the evening. Thank you very much, guys.
(Applause)
CHAIR: Do we have any questions? Obviously not. OK. So then we have gained some time and I would would like to invite Thorsten Dietrich and give us an overview psi, German federal institute for security but I am sure he can expand on that.
THORSTEN DIETRICH: Thanks for the introduction. I work for the federal office for information security in Germany, psi in short. And in the next couple of minutes I would like to show you some slides of our study about the DNSSEC support of German home routers or CPE devices. And yes, just some words, why we did this study. We see DNS as a crucial part of the Internet infrastructure and, therefore, from our point of view, the adoption of the DNSSEC is strongly required as it helps to close some vulnerabilities in the DNS protocol which are there by design and, therefore, we launched an initiative in the middle of last year, together with DNS SEC and E correlated to evaluate the introduction of DNSSEC for dot D E, part of DE?NIC in this initiative is the provision of test environment, we had about this in the morning session of this Working Group.
We tried to raise awareness in discussions with public and private sector and universities to, yes, address this topic. And we signed our German government domain, ".bund.de" a few weeks ago and Trust Anchor is available in the German test bed since last Friday. We didn't experience any problems with this, by the way, so it's just works as before.
Yes, and we did this home router study which I am now going to talk about.
History goes back with this in 2007 when some DNS SEC signed zones were suddenly unreachable for some users in Sweden, where the main reason for this was there was actually a buck in the software bind which was, the case was that in the answers section of the query, the A D flec was set even if there was no ?? so but this gives us the hint that there are some problems maybe around with home routers and their capabilities of DNSSEC. So, the ?? the Swedish Internet registry did a couple of tests in February 2008 to discover this and NomiNet in September 2008 did the same in UK and both studies finds out only a few devices could proxy DNSSEC requests or queries so without any limitations but at least most devices could route these requests. So, the tested devices were mostly for Swedish and British markets, a year passed since that, more than a year, and there was certification called 5625 implementation guidelines which gives some guidelines to manufacturers how to implement such proxies. So we thought let's examine this situation in Germany, if there is any progress.
Yes, our objectives: The same as the other study which have been, did before ?? done before. We want to know if the routers are able to proxy these requests or at least if they could be used to award these requests if they are integrated proxy is bypassed. That means they have to handle signalling flex, large packets, have to support E DNS and if not supported then they should accept queries over TCP. We are also looked at some other security issues, for example the factory security settings for wireless LAN but I would like to focus if you are interested in the rest please take a look at the study which is published under the URL here and at the moment it's available in German language only, sorry for that, but we will publish English version in the next weeks.
Our test methodology, we used several various DNS queries of various resource records to examine the capabilities. So that means UDP and PCP based queries, E DNS queries with various buffer sizes we queried records of various length so we ride to find out where the limits are.
Our test bed, we connected the home routers behind D SLAM to simulate Internet connection and behind this D SLAM was caching resolver and behind that and other named server, the caching resolver was DNS SEC?aware of course and we choose this kind of set?up because if you connect this home router to typical Internet connection, you may get wrong results. I know from one big German provider, which has got a set?up that the authentic ?? caching the servers which you then are going to ask, DNSSEC disabled so that means even if you set the O FLEC, you won't get any signatures back and so you might have in such environment the wrong results that you think your home router is not DNSSEC capable but it's an issue of the up stream resolver.
We tested about 36 devices, and 23 of them had integrated DSL modem and the study considers about 90 percent of the routers which are actually supplied by the German broadband providers. Still it's not a representative study. The study was supported by different ISPs and manufacturers. We choose it that way because we, as I mentioned, wanted to raise awareness of this issues and so we talked to the ISPs and manufacturers and asked them for support and we got good feedback and many supplied our study ?? supplied devices and supported our study. We also brought some devices on the German free market but I think that was only three devices, so most of them were actually supplied by manufacturers and ISPs. And we choose to test each router in supplied condition because we think the average user is not going to change any settings, so we didn't configure it and didn't update it.
So, we choose to have a look at three different scenarios, the first one was a normal query with a, yes, user operating system which is not DNSSEC aware and that means there are no flags present at the query, and, therefore, there shouldn't be any issues and, yes, it was as expected. We didn't experience any problems and all routers worked as they should. There was, however, an issue with some implemented proxies. Some of the integrated proxies couldn't handle all types of resource record queries, especially they couldn't answer or they couldn't pass queries for text resource records and as we used this kind of records for our E DNS tests, we excluded these devices from our further proxy tests. Then we wanted to know if the routers are able to pass the E DNS buffer size advertisements if they are able to pass the flags in both directions and if they could surpass the large answer packets. So, first, the E DNS results: Yes, that looks really bad. Over 4 devices of the remaining 32, 33 were able to handle E DNS packets of any size, whether the biggest size we test it had was about 4 K, so all the others failed in that, somehow, where we had another 12, this one here, which could handle E DNS queries up to size below, typical MTU sizes, but only half of them saw this 6 one sets the T C flag in the correct way, if buffer size was advertised which was upper these limits. The other six just discarded the answer packets and couldn't pass T C bits, which was set by servers. Not really good result.
Then we looked at the TCP support, and yes, only 8 devices could ?? were accepting DNS queries over TCP; all the others, yes, just listened on the UDP port for DNS queries.
Interestingly, there was no device which was able to handle both E D DNS and TCP, either one or nothing. So we had 12 candidates which probably could the could not be compatible but let's see.
Next test was the DNSSEC flag compatibility and most of these devices here were able to handle DNSSEC queries. We only had three devices which modify DNSSEC flags and one device which returns the connection time out when there was an A D flag from the up stream server. Unfortunately these three devices would ?? can be connected over TCP though they are in these eight mentioned devices here, so that makes the end five plus four so nine devices which have full DNSSEC support in the integrated proxy. We had another 7 devices which have limited support up to the MTU size and all the rest are incompatible.
There is one other issue which has to do with the integrated cache. We found out that all integrated caches had no idea what DNSSEC is so the first query was done without ADO flag set then the answer was cached without the signatures because they wouldn't be in the answer section then and second query was then answered out of the cache without the signature, even if in the second query the O flag was present.
Then we wanted to know if the router could be bypassed at the DNS proxy and if that is working, and yes, that is ?? this looks very good. All devices fully DNSSEC when the implemented proxy is bypassed. There was ?? there were 6 devices which had problems with fragmented large UDP packets, so they only support a TCP query to the up stream server. But all the others hadn't any issues here. To get the overall results, it's not enough to look at the proxy results, we also have to look which kind of DNS address the router supplies over DHCP to the connected clients, and while most of the devices supply themselves, we had five devices which supplied the ISP upstream server addresses to the connected clients and, therefore, we have to consider these five devices as DNSSEC compatible as well. And unfortunately, we had 6 devices here which couldn't be manually reconfigured to supply another DHCP and these six devices belong to the ones which had no integrated DNSSEC compatible proxy. So, yes, but most of the devices could be reconfigured and they are here 1 and 1, some devices which supplies the up stream server address.
So at the end, we had 15 devices which could be considered as DNSSEC compatible with factory defaults either because they support DNSSEC in the proxy or they provide the ISP settings, and we had another 16 devices which could be reconfigured if the DHCP settings were changed, and we had five devices which lack reconfigureable DHCP DNS parameters. If we take a look at the device it's supplied by ISPs, it's even a bit worse, only four are compatible by factory default and another 11 could be reconfigured. So our conclusions: With non?DNSSEC aware client operating system, we had no come patability issues. With DNS SEC aware client operating system, 15 devices can be out of the box, 16 can be reconfigured and the other five lack these configuration options, therefore as a work around it's possible to set different DNSSEC ?? DNS options on the connected clients.
The come patability issues were mostly due missing E DNS and TCP support.
If you compare this to the results of the S E and UK studies, let's see if there is any progress. Well in the E DNS part, not really; we had in Sweden 3 of 10 in, UK, 4 of 22 and in Germany, we had, now, 4 of 33, it's not really good. It looks a bit better in the ?? in this topic here with DNSSEC cot patable factory settings, we had 25 percent in Sweden and UK and we had now 42 percent. We communicated these results to the manufacturers and ISPs and we already got some positive feedback. One manufacturer released beta firmware with improvements and others signalled us that they want to adopt the recommendations at least in future products. So we hope that our contribution will help to, yes, improve this situation in the next years or so. I don't know.
So that is the end of my talk. Thanks for attention. Any questions?
(Applause)
CHAIR: OK. Questions?
JIM REID: Thank you. Are you planning to do these surveys on a regular basis now? Is this just a one?off event?
THORSTEN DIETRICH: We think about it. At the moment we didn't have this on our ?? but perhaps we look at it in the next few years if, there is any progress yes.
JIM REID: Something again would be very, very nice to have, if we had some kind of DNS tick box on these products to say they were DNSSEC capable. I wonder if that is something you might want top consider.
THORSTEN DIETRICH: We have one legal issue, due to our German competition law it's not allowed for us to name individual manufacturers so, that is the reason because we only have statistics here and so, our aim was to reach the manufacturers of these devices and, yes, as they got the whole results, they have the chance to make it better, so...
JIM REID: Maybe if this is something that you can do as part of the federal government, because some other agency in Germany, say the standards people might want to consider adopting this and doing something with it. That was all.
AUDIENCE SPEAKER: Olaf: I thought about the name and shame issue, part of this is of course that the German federal government reaches out to manufacturers, probably has a little bit more of an impact than any individual in this room reaching out. So I actually quite happy this is happening. In general, it might be good to have one place where customers might find some certification about devices that allow DNSSEC or general protocol awareness, such as IPv6 as well, in one place, but I am not quite sure if that is a governmental responsibility, those are for trade organisations or what. One important metric in your graph is the amount of the ?? one important metric on the impact of your measurement is the amount of DNS aware resolvers behind the DSL modems. Do you have any idea?
THORSTEN DIETRICH: No. We just ?? we actually were a bit surprised that the ?? this test of the Czech registry which mentioned these devices which were tested with set up there and we were a bit surprised at some devices which had good results and were mentioned as bad so we looked into this issue and find out that, yes, the up stream service lead to wrong results sometimes, but we also tried to talk about this issue to the ISPs in Germany that at least they configure it a bit less conservative and allow the O flags to pass.
AUDIENCE SPEAKER: Thank you, just one observation, oh, I haven't mentioned who I am, Olaf ?? one observation is that will take a long time for these devices that are now in people's homes to disappear and that will have impact on the speed with which DNSSEC can move to the operating systems. It's very clear the DNSSEC is now a targeted or ?? its deployment base is really within the ?? within the ISPs, the recub sieve name servers of the ISPs but this makes it clear it will take a while but it actually moves back to end user land, and it will be good to keep pressing on producers of DSL boxes and modems and cable modems.
THORSTEN DIETRICH: Yes, but you can reconfigure to ??
Olaf: Partially, part of them.
AUDIENCE SPEAKER: Unsisree from Siesenic: Well if you ?? I know that you can show the names but if you can send out at least those results we have wrong so we can fix them in our databases, it would be great.
THORSTEN DIETRICH: Yes, OK.
CHAIR: I am going to pose one more question, that was probably kindly touched already: What has not yet been taken into course of course is the market share of these devices so it's not only the operating system behind the DSL routers but the share that they have themselves. I know this is a tricky issues even the ISPs don't know what is happening there. Can you say anything in that direction?
THORSTEN DIETRICH: Yes, on the last RIPE meeting, there was someone here from AVM which is German manufacturer of these so?called FRITZ!Boxes and they said that they had a market share, about 80% in Germany, and, yes, what I can say is that we looked at these devices as well and they mentioned at the last C bit in Germany ?? had available which solves the problems which was discovered from us, so yes. If this is true with the 80%, I don't know, then that would be a big step forward.
CHAIR: Yes, indeed, of course.
Carsten: This is not DNSSEC?related at all but v6 related. I just happened to read a press announcement of A B M the FRITZ box manufacturer today by now but by production of status they became v6 aware with the latest gear, so I have great confidence that sooner or later they might be fully DNSSEC capable as well. So just ??
CHAIR: Hope never ends. Thank you.
AUDIENCE SPEAKER: OK.
CHAIR: Thanks a lot.
(Applause)
Next on the agenda is Matthijs Mekking staying on the topic of DNSSEC and Matthijs will give us an update on open DNSSEC and implementation used by at least a couple of TLDs for deploying DNSSEC.
MATTHIJS MEKKING: Thank you, Peter. Great presentations so far, enjoyed them. There is only one of them I couldn't really follow this morning but, hey, that is OK, Ed. This is open DNSSEC status update. For those who don't know what open DNSSEC is yet, a short description, quite recap: It's a zone signer that actually keeps your signatures fresh and keeps track of your keys if you are doing roll?over, implementing your signing policy and does it automatically. These are the authors. I will give you a few seconds to look at them. And if you talk about open DNSSEC you also sort of implicitly talk about soft H S M which is a sort wear version of H S M, it's P K CS 11 compliant and you can use this as a replacement for a real H S M.
So, what happened? I think open DNSSEC was introduced at RIPE 58 last year for the first time to the RIPE community and since then, we saw a technology preview that it was the first release in July 2009, in 75 in Stockholm, and that allowed early users to play with the ?? play with it and ?? well, give us comments, feedbacks, what should be improved and that happened a lot and we are very grateful of that because this resulted in a lot of alpha releases, beta release, release candidates and it was only February 2010, 2010 that we released the first 1.0.0 release. This release is is a prototype release and it shows ?? hey, it's working. It's fault based, works on zone files, text files and it includes zone fetches, so you are able to fetch it from a different machine, to prove AFXR. This version is in production use by dot S E, UK, also ICANN makes use of open DNSSEC. I hope there will be more, or later.
Soft H S M is steadily improving. When it starts first release last year as well, it grew to 1.1 .4 and that is mostly configuration clean?up, documentation clean?up and buck fixes. And it's now we have an open DNSSEC 1.1, release candidate 2. So we are hoping to have 1.1 out really soon, if the release candidates don't have any trouble and what does this release focus on? It has speed optimisations in zone sorting and NSEC3ing, cost a lot of time so this is good news for operators of large zones. And of course, if they are going to use NSEC3. Partial auditor is added because also the you had a nor the 1.0 release took very long time to audit large zones, so now we have a partial audit that doesn't do all crypto graphically checks but does sort of sanity checks. Furthermore, an important thing is that we have added an EPP client, this is experimental, but this allows you to more easily up lead the DS records to the parent. Than it is now.
So, future work for open DNSSEC. This is slide that was presented during the.0 release. The red one is handled in 1.1. We still want to look at increasing performance if you want to serve and sign many zones, and with that comes that key sharing between those zones should also be improved. We also want to include IX F R input/output so it can be a bump in the and get signed IX first in and out. How does that translate to version numbering? So 1.2 will work on that after the 1.1 is out, very soon hopefully, and that will actually focus on these three items. Improve key sharing, improve performance for many zones and one I didn't mention, remove the pie on this dependency. Open DNSSEC has a lot of depend an sees and this is one we now going to remove, decrease a little bit. Then 2.0, then after 1.2 we are going to focus on 2.0 and that will focus on different adapters. Now, it works on text files but for 2.0 we want to add all kinds of adapters and we will start with the IX F R adapter but also thinking of the dynamic update adapter or database adapters, so it can work on your favourite database. What is not really on the time plan but we are on the long road is user interface which makes it open DNS SEC a little bit more easy to handle. What is the plan for soft H S M 2 will focus on enhanced security and this means a few things, one of them is it will try to improve the scalability, if you have a huge number of keys; it will add support for other crypto libraries, it now depends on we also like to support open SSL or others, there will be an internal API that will handle this. And there are some other smaller things, support for cost ?? that is ?? zeroise memory before you free it and more stuff like that. That was it. Questions?
AUDIENCE SPEAKER. ....isburg, Dot New Domain. You spoke about an experimental EPP client. Have you based that on any ?? on any software or have you built it by yourselves?
MATTHIJS MEKKING: The project build it by itself, yes, and the main drive is I believe for the dot S E domain and they are really pushing DNSSEC to their second level domains.
AUDIENCE SPEAKER: When we can expect support of ?? open DNS SEC, it is already supported to openness but we failed to use it?
MATTHIJS MEKKING: And that is a problem because soft H S M is built on bow town and I believe it needs new upgrade in there so we are waiting for that.
AUDIENCE SPEAKER: So we should try to find another ways before open DNSSEC was designed for, yes?
MATTHIJS MEKKING: So I don't think this is a long time, but I don't think how long we should wait for this depend an sees.
AUDIENCE SPEAKER: Years, months?
MATTHIJS MEKKING: Sorry, please ask this on ?? I don't have this on the top of my head. Sorry.
CHAIR: Steffann AFNIC: Again a customer who wants to know when it will be available. Did you mention any E TA for open DNSSEC 2.0 because like NomiNet for CO dot UK we provision .FR with dynamic update and with DNSSEC 1 it's Payneful so any idea when we will be able to do so with open deck, it was not clear if there was a specific commitment to a specific project or if it was only idea floating around?
MATTHIJS MEKKING: For the 1.2, we are planning that late summer, time?line for that is August and 2.0 is planned for December 2010, but these are not real hard commitments.
AUDIENCE SPEAKER: Because December, it's close now?
MATTHIJS MEKKING: Yes.
AUDIENCE SPEAKER: You have to go back to work.
CHAIR: Thank you Steffann, and I guess with that we can release Matthijs a bit.
(Applause)
Next up is Joao Damas with update DNSSEC for humans as opposed to the aliens or whatever.
JOAO DAMAS: Is the name we chose for BIND 9.7. Dogs are excluded now from the Internet. So, quite overview: Why we chose this name? What are the features does it have that you might find useful and if you like this, what to do about getting more.
So, before 9.7 came out, if you wanted to do anything with the command ?? the tools that were available in bind, to deal with the DNSSEC, you'd be faced with things like what is on the screen. That is the command you would have to use to generate the keys, both ZSK and KSK. If you were a bit more twisted, do you want normal key, you wanted support for NSEC3 in that you had to extend the command little bit longer and remember how to actually spell that NSEC3 thingy. With 9.7, we changed it to this. And left the software figure out what you mean and do the work which is basically the way software should be done.
What else did we do? Smart signing. Smart as in I will figure out why you are telling me and I will do it for you rather than have you type everything you need. Before, typical way of doing this, signing zone would be you pump the key into the zone, file would be, which you had somewhere else, so I was available from the file ?? zone file itself, and then you'd go and type that command that you see there, that takes two lines. Specifying the zone sign key. The new way, minus capital S and it does it for you, it figures out where you have the keys, which one is the ZSK and KSK, which parameters you are going to be using for that and it just signs it. It also remembers from one time you sign ?? the first time generate a sign zone to the next, what parameters were used for signing and it keeps using them rather than asking to you specify every single detail as you did the first time around. So that is basically, use interface but makes life much more easy for everyone and this is the amount of errors that are likely to happen.
Later to these we added fully automatic signing of zones so once you load the zone, bind will now keep an eye out for signatures expiring and keys expiring if you ask it to. And deal with it, if the signature is about to expire it will resign it, it will increase the serial number of the zone file that is published, to go with it, so basically one of the biggest most frequently, most failure for DNSSEC we have seen up there so far, perhaps not at TLDs but in all other zones is that signatures expire because people forget about it, they sign it, DNS used to this be service that you deal with once every six months if at all and so now that they have to go and resign the zone people will just simply forget. So now bind will keep things running for you. You can even automate the key roll over process, the key files now have a few lines support ?? a few lines at the beginning which start with the semi?colon which indicates basically it's a comment so it won't break past implementations but in these comments if you ?? use the structure that will provide, you can give the ?? can give bind hint about for how long this key is supposed to be used, when this key is supposed to be start using and when withdrawn and so on, so if you generate the keys and you can generate any number of them half time, bind will then just read the file, build its own information table about what you actually want to do and then keep running and do the signatures, do the key roll overs, do everything for you and instead of demanding that you keep watching it every minute.
Protocol wise, and related to this somewhat, to make the package complete, 9.7 has no support for IC 5011. IC 5011 is a signalling mechanism using bits in the keys, to signal to resolvers, how to go from what is today an authored ?? key to tomorrow, what is the key for that zone. So resolvers themselves don't have to keep track of the changing environment they have to live in. So before another classical failure mode for DNSSEC this time in resolvers, the previous one informs authoritative servers, you forget checking with the TLD in question or zone if question whether they had achanged addressed or not and getting calls from users they couldn't visit websites any more or send mail. This is taken care of with the protocol, we implemented the protocol. Somewhat related to these, the slide in Italy, we simplified D DNS. It use to take a lot of ?? getting for work with bind, which a lot of people found quite inconvenient. When the decision was made to, how to implement all mated signing 9.7 it was decided we already had had a mechanism which was dynamic DNS so we leveraged that and introduced the signing mechanism is based on dynamic updates, so it was crucial that dynamic updates as a stand?alone process were also made easier to use. And in fact, some processes ran by sending dynamic updates to the local host. The configuration generation, getting all the parameters right, you can use a tool instead of making 30 mistakes before you get it right.
On a separate item, LIB DNS which was separated as a package indicate from bind has now support for DNSSEC, including some API changes as you see there. And one of the final things is that, there is much improved support for using P K S 11 in bind. There was some support already there limited to the SC A 6,000, we have added the AP keeper, we have debugged quite a lot of the support. It turns out as ?? also figure it out ?? although PKCS 11 is a standard, it's you can choose in vanilla strawberry, chocolate, and the vendors do, you can have not one single of this and expect to talk to every device out there, you have to tune it, which is a bit of a pain and well, we try to do it for you anyway. There is ?? there are some tools there listed at the bottom part which are tools that allow you to talk in a H S M independent way to the ?? to the H S Ms that are supported to create list or keys.
That gives you a ?? overview of what is new. The whole to make life easier for everybody and reduce the number of failures we have seen. There is also some improvement in documentation. If you dare ?? more things would you like to have there, if there are things you clearly see missing, do let us know and as I said before, if you like this kind of beer this is how you can get more. I am done.
CHAIR: Thank you, Joao.
JIM REID: I think these and signing tools are great there is a lit more that still needs to be done there. ?? it's great we have made some improvements with the signing tools and arguments to zoning, but there is still a long way to go because I think there was horrible K star dot whatever blah?blah thing files that have been going on, that is historical legacy of the very first DNSSEC implementation that was done around about 1998 or so. It would be nice if there could be better improvements in that. I realise it's a first step, it helps us more with issues around key management. One thing do I have a big problem with about BIND 9.7 is the default installation of bind dot keys, I think that is a big, big mistake and I wish you would reconsider that. Although my views about DLV are well?known, I am not going to repeat them here and now, I think it's bad to automatically install configuration files into slash etc. When in many cases people don't need a what not file and wondering why is that there and that will create confusion and you have got config files, it's not a config file to marriage, why is it not in the repository, you really shouldn't have installed that by default and I would wish you would recar that.
JOAO DAMAS: Valid comment. One thing I didn't mention actually, regarding the ucky names as you call them. We pick 11, you can refer to keys by labels so if you choose to use H S M that is a benefit you get. You can get ?? call the keys by whatever name you like.
AUDIENCE SPEAKER: If you tried to interoperate with the soft H S M that was mentioned? Because that is a stand?alone thing and could you actually plug it in and ??
JOAO DAMAS: Yes, that is the chocolate flavoured PCKS11. I think there are tests done but it didn't work first time and I think there is currently no one working on it. I think it should be included in support, yes.
AUDIENCE SPEAKER: I am sure there is people willing to want to work together.
CHAIR: OK. Any further questions? No.
AUDIENCE SPEAKER: Just one question: Casey: Just a question about the way that the automated checking for expired signatures and zone resigning works, is that done currently by the name D itself.
JOAO DAMAS: Yes.
AUDIENCE SPEAKER: In addition with the idea of the soft H S M for actually ?? for storage, are there considerations for moving that to a separate process, for example, for separating privileges from the actual name that is doing the ??
JOAO DAMAS: Not that I have heard of. I don't think we had the requirement before. In fact, the requirements so far have gone in the other sense, in the other action because bindism of the application, the fact that you can buy a single gar processor any more, people wanted to have everything done inside the process, while bind is still answering it's also resigning the back drowned and keeping things in check and all will be very coherent. There wouldn't be separate image of the ?? of memory image of the zone everywhere so everything would be always kept in sync, but yes, there is the issue of whether you can access stuff, with the same privileges that you use for bind. That is a valid point.
CHAIR: OK.
JOAO DAMAS: The immediate solution is to run two binds.
CHAIR: OK. Thanks Joao.
(Applause)
And next up on the agenda is on Andrei from C Z.nick and he will give us an overview of another development that have registry is Firefox plug in and we are again dealing with DNSSEC here. My name is Ondrej Sury, this is just again the marketing presentation.
So, what was the motivation for this project? Well, the main motivation was that DNSSEC is basically invisible to end user, to domain holder, to whoever is using that. The person will only know about DNSSEC if something fails. So the idea came up when we were using the ASN number add on for Firefox, while it shows ASN and some more information and well, the credits for this idea goes to my clone Ondrej there, while for those who ?? don't know the joke that people are constantly confusing us two because our names are Ondrej. And the coding was done by my department and I am only here to take all the other credits for this project.
So, what is the DNSSEC validator? Well, basically it's Mozilla Firefox add on. You can install it into your router and it will show the four ?? well this is the four visible DNSSEC states inside the browser: These can show three colours, the green one is when the domain is validated and everything is OK and it has DNSSEC; the orange key basically means that well I could validate but something happened so, well, the domain name has the signature but there was no A D flag in the response; the red key means go away, something failing, the validation has failed and the domain name has invalid signature. And the last the no key, no DNSSEC ? well, poor you if you don't have DNSSEC. So, well, the thing only the visualisation of DNSSEC, it just shows the validation status of the URL, it doesn't check all the links on the page and it's not meant as security tool. It doesn't check for those nested pages, frames, all that stuff which could be in the web page; it just shows the URL. So here are some pictures, how does it look. This is one of the main magazines or newspapers in Czech Republic and it was already, before we get those almost DNSSEC signed domains, it was already signed. They decided to go for it on their basis. Well, and I would like to thank you here for the RIPE staff that they enabled the DNSSEC and the resolvers here. Thank you. So now, for the the RIPE resolvers can do NSEC3 here some bind, you get the orange key and, well, you can use ours. This is just ?? green key is better on this page. So if your ISP does the DNSSEC, then you will get, well, something like this, the server is not found because the domain name doesn't validate, it's deliberately unvalidatable but if your ISP doesn't support DNSSEC, you can use your own DNS or you can use ours. This is the settings. We run it on IPv4 and IPv6. And there should be a web page soon for that. So, you can get some security even if you are using some external like open DNS or something. And if there is no secret at all you will get no key. And no money. So, what you get it? It is nice new shiny web page at wwwDNSSEC?validator.cz. You can find it on add ones, you can address search for DNSSEC or go for the URL. It's still in send box so you have to upgrade it manually and it's in the queue for review, we get some comments to send it, source code because a guy can basically, is not willing to download it from our versioning system, and some technical background: It's written in CX U L Java script, openness S NL we found some issues which are fixed now in the trunk. It has hidden configuration for debugging and, well, such stuff. Then, the developers is on our lapse dot ?? well it should be DNSSEC validator, and bug reporters go to that e?mail address. There is some known issues the last version, on Windows XP you need Microsoft library and there is new validation status cache which is not shared between windows but tabs. Any questions?
CARSTEN: I have one. Have there been any first initial talks with the ? already or do you intend to do so it's not going to be an add?on sometime in the future but natively built into a Firefox version 4.whatever?
ONDREJ SURY: We tend to talk with other people but for us it doesn't make sense before the system library gets support at least for E DNS 0 by default. Because you cannot use system library resolver for that.
AUDIENCE SPEAKER: OK. Thanks.
CHAIR: Any more questions? No. OK. Thanks Ondrej, thanks very much.
(Applause)
CHAIR: And now it's David knight giving us again an overview over some ICANN/IANA activity, the ARPA zones children.
DAVE KNIGHT: Hi, I am Dave Knight and work in the DNS group at ICANN, this is going to be a brief update on the status of DNSSEC in under the ARPA TLD. ARPA was signed internally at Verisign at the end of 2009 and was then distributed to the route server operators for their own testing. It's been published, signed, since March 2010. This is currently considered a test deployment, that test is now complete without any found and we will submit a test report after which this will be considered to be in full production. The focus of this particular presentation is on the second levels under.arpa. That is the complete set of those. Currently, E 164.arpa has been signed by RIPE NCC has 2007. They have told us that after their upcoming key role they will ask us to include the DS record for that are in the ARPA zone itself. In?addr.arpa is not yet signed. A proposal to do that has been submitted to NTIA along with a proposal to redelegate the in?addr.arpa zone away from the route servers to a new set of servers operated by the RIRs and ICANN. This plan is being coordinated with the RIRs, it's come together and the proposal is currently with NTIA. The other ARPA children have been signed signs last week. That was signed on the 29th of April and that is being done by ICANN as an IANA function. The equipment we use to do that, I actually described in a presentation at work at the weekend, if you want more information on the infrastructure you can go grab that presentation from DNS ? OARC.net, one on east coast and west of the US. It's a big safe with a 19 inch rack inside it and the equipment is inside that. The H S Ms that we use are the A E P keeper. The DNSSEC parameters in use for these, it's exactly the same as for ARPA and for the root, Sha 2356, 2004 8?bit KSK, we roll the ZSK every three months and KSK annually but also manually.
The ARPA Trust Anchor is currently published in the ITAR. The ARPA children will have their DS RR sets included when test something concluded and reports have been sent to the NTIA and authorised. Arpa currently signs in?addr.arpa. As I said, there is a proposal to be advised on, we expect to get this done this year. All of the other children are now signed and the Trust Anchors will go into the ARPA zone shortly. Any questions?
CHAIR: Peter Koch. Two or three slides back you mentioned that the request to sign the children of.arpa was going to be sanctioned or approved by the NTIA, is that correct? Or is it for.arpa itself only.
DAVE KNIGHT: We requested authorisation to sign those and we asked authorisation to modify ARPA through the insertion of the DSRR sets for these zones.
CHAIR: OK. Maybe you are the wrong person to ask here because of this stuff that is involved. I am just wondering how far that authority would trickle down the tree, especially given given that.arpa is is a top level domain controlled by the i.e. P ??
DAVE KNIGHT: You are quite right, I am the wrong person to ask.
CHAIR: OK. So since he.
AUDIENCE SPEAKER: I will ask one. Sam: You said you were seeing the same DNSSEC averages for the root and yet the last line said you would be rolling the KSK annually. Will you also be doing that for the root please.
DAVE KNIGHT: We will not be doing that for the root.
CHAIR: OK. Just for the ease of stage tuning, Dave is now going to give the update on root signing and after that we will have Jaromir from C Z.nick.
DAVE KNIGHT: This is some very early observations on what has happened since all root servers have made the transition to. The roll out of that zone started with L root on the 27th of January of this year, since then there have been 6 transitions or five since then, with an increasing number of root servers at each transition. Last night, J?Root was the final route server to make the transition to carry the DURZ. Here is a graph showing TCP queries received at J?Root. The white bar in the middle will is when they made the transition. I think Anand said this morning when K?root made theirs they went from around 5 TCP queries per second to somewhere close to 40 and we see very much the same thing for J?Root here. There is really nothing surprising in this picture. At the time of the transition, this is query load seen at K?root, and again, there is no immediate change following the transition, there is nothing surprising to be seen here again. Moving on to the L root graph we did see something interesting but it's not touring the transition, again there was nothing interesting to see here, but a couple of days earlier it's hard to see due to the scale of this graph, but there was a reduction in the TCP queries that we have seen. When L made its transition to the DURZ, we saw the same huge increase in TCP queries that everyone else until two days ago and Dwayne spotted this, and we have this graph which shows all of the DURZ transitions since January, and you see, if you look at the, not this current one which is over the right?hand side but the one just before that, where I think these ?? I think orange and yellow there are F and E, they had a very marked increase in TCP queries and this is consistent across the system, until this latest collection where all of it is very much reduced. And it turns out that this is due a single/23 inside Cox's network which between the last transition event and this one, has stopped sending TCP queries. So I think this is just a good illustration of, we are looking at the data, we are not really seeing anything that is wrong but while we are looking you can see that individual clients or groups of clients can cause really big changes in the graphs, but as far as the DURZ transition is concerned, there is really nothing to report at this point. Any questions?
CHAIR: We would have time for one or two questions here.
JIM REID: Not a question ?? this is not a question, I just want to say Dave, Joe, mat, Dwayne, everybody else who has been involved in this, thank you very, very much.
(Applause)
AUDIENCE SPEAKER: New Zealand registry services. One of the DNS operation mailing list, someone mentioned thought from Stefan, about this increase ?? actually the sky didn't fall the TTL associated to the root zone, so we shouldn't speculate on maker failure now but it might be produced in the following days, so I was wondering if the root operation team is, has any plan to keep the traffic capture during like a week but only the priming queries not all the traffic, in order to be able to defect?
DAVE KNIGHT: Right. Sorry, did you say only the priming queries.
AUDIENCE SPEAKER: Yes.
DAVE KNIGHT: I think since before L root made its transition in January we have been collecting all priming queries at all of the roots.
AUDIENCE SPEAKER: OK. Thank you.
AUDIENCE SPEAKER: To add, yes, enormous amount of fat going on on this operation and to be honest saying we have to wait until ?? is out is even more of that because if this was a real problem and then you should have seen the effect earlier of adding, is my opinion.
DAVE KNIGHT: Joao made the observation that because there is the possibility that as caches slowly run out at least it's not going to be seen as a big event, people are individually going to encounter this and see it as their problem to solve, we expect.
CHAIR: OK. Thank you, Dave. And everybody else involved.
(Applause)
And we are now going to have the final presentation of the day by Jaromir Talir and while the title suggests this will be a DNSSEC?free presentation, I really doubt that.
JAROMIR TALIR: Well hello, good afternoon. Technical manager from C Z.nick and I am standing here maybe for sole purpose,y superb leer after Ondrej's presentation that we are doing serious work, not just fancy things, shiny things like this.
So, my presentation is just briefly overview of the work of our technical department over last half a year, maybe more than half a year. We changed a little bit our DNS infrastructure. We planned to fully run out our infrastructure Anycast technology so I will speak about our plans, the situation where we started and where we are now, the steps we had to make and issues we had to solve. And also some graphs.
So, because I am speaking about Anycasting, DNS infrastructure so I will have to start with description of our DNS infrastructure. As you probably know we have almost 700,000 domains, with with quite a lot, around 8,000 queries per second. We managed our DNS secondary service fully ourselves and we do that on nine localities around the world. Each local locality is the same, we have some hosting for two servers with different architecture for some diversification, AMD, Intel and some Sparks. We took on those basis usually one transit connectivity and somewhere we are also in peering centre. We install on servers DNS, NS D or bind and we have there some of statistic collection made by DS C.
Brief overview what Anycast is, routing technology where one IP address is announced from different places. There is a special policy, a special pool for addresses in RIPE, for example. And the add advantages of this technology is bigger reliability of DNS services, because there can be more and more new DNS servers with a limited number of IP addresses and the second advantage is the speed because of routing principles, always the nearest note is chosen for specific client.
So where we started, about a year ago we were in situation we had 1 Anycast address signed and we have five unicast addresses so we had 6 addresses in a root and almost all of them were v4 and v6 except of the node in Sweden. I will speak about it a little bit later and our plans was to have 4 Anycast aaddresses properly spread around the world. What we have to do first was to change policy for, former policy allowed only one Anycast address per TLD and there was some proofs that TLD has to provide like that he really needs Anycast address and so we initiated a change of policy together with colleagues from NomiNet and this policy was accepted a year ago in Lisbon and right now it's possible to have four Anycast addresses her TLD or ENUM operator and it's much easier to get those addresses right now.
And other steps are quite simple: We installed BGP daemons on every service, we use again for ?? from proposals of diversification, we used all implementation that are right now possible, especially BIRD which is our flag ship of our R and D department. I hope awful you has T?shirt already, maybe. We had to negotiate with connectivity partners BGP sessions and update filters for Anycast proposition. We changed a little bit our high availability design that both servers that were previously providing services using are now working using both are on and one of them has longer S path so in case of one server die, immediately the second one is active. We had to install some monitoring script on these servers to get over troubles in case name server die and we have to stop BGP session. And finally, we had to update root zone for three of our addresses, to change them to Anycast.
This is the current state, convenient shot. Right now, we have all 4 addresses transferred to Anycast and we have just one Anycast address left. I will again speak about that later. This is the same in my red/green table. This is the map of locations of our DNS servers. We got inspired from root servers dot org website so everybody uses now Google maps. And we have, I will speak about two issues we have to solve: We wanted to change to support fully v4/v6 protocols. You may have seen that there was one node in Sweden that had just v4 address, because we are afraid of some bad behaving resolvers that could possibly in case of some IPv6 problems just pass to the next name server and then our DNS would not be accessible in this ?? it if there would be such a problem, so we send some queries to mailing lists and checking root zone and we got some responses that it's not a problem or that there is a lot of TLDs that use fully both v4 and v6 addresses. So it should be OK. Anyway, we checked DS C statistics and we are looking for significant degrees of IPv4 queries in case there would be such a problem but actually there was not such a problem. This is the statistics from our Sweden node in the time where we started to ?? actually we changed unicast v4 address to both v4, v6 Anycast addresses for our.cz zone and two weeks later the IANA changed also these addresses in the root zone. There is maybe really small decrease in v4 traffic, but really not significant, so the conclusion was that there is no such problem. And the second problem we are facing was Anycast address filtering, in the third case when we were trying to change address in our London node, we faced some problems that our Anycast address was not seen from different parts of the world. We found that by putting address in zone file and look to DNSMON, real nice tool, and we have seen that there are some probes that doesn't see our name server so we contacted about three ASs to find out where the filters are blocking the propagation of our addresses, and finally, after sometime, they fixed their filters and now there is no more of those problems.
And the last thing I am going to speak about is some really simple tool for measuring distance of our name servers from different parts of the world. We created a list of IP addresses especially from DS C, those are most active clients, from each country, and we tried to ping these IP addresses from all of our nodes and measure round trip time and expect that had we will get some simple view of distance from name servers from different countries and of course, also, which name server is is a little bit responsible for that country. And I have two pictures about the result of this test; this is the ?? a distance test where there are four colours and there is an actual ping time for risk point so you can see that the developed part of the world is quite fastly responding and we have to work more on the red part of the world, the Czech people living there. And the second picture is about which node probably works for the best for which country. There is some interesting things that it's not seen very well, there are still some white places like it's French mar objecting co?, some ail I can't, something like that, but maybe this could be a problem with choosing the IP addresses but we found that there may be some IP addresses that are not able to ping using Anycast address, but just ?? but they were responding properly from unicast address, so the conclusion was that right now we still have that one unicast address in Vienna and we are ?? we will explore it a little bit more and do some more research about it if we are able to also to change this remaining unicast to Anycast address, and second conclusion, because we pass three rounds by updating our records in the root zone and actually almost during each attempt we got a response that we had to do something, something differently to pass the checks of IANA so we are thinking it would be good to have some web service for those technical checks so we can do those checks before we send the actual request for a change in the root zone. And the last slide is about our plans:
We are soon, we will have ?? we will start new node in Tokyo, in JPNAP, and we would like also to do some more serious research about the distribution of Anycast addresses to different places. We, right now, we support DNS hosting services for some developing countries like Tanzania and Angola so maybe we will continue with that and offer the services for other countries. And that is it from me. So if you have some questions?
AUDIENCE SPEAKER: Could do you me a favour and go back a couple of slides to the ?? these two Google maps. The other one. I just wonder why chilly is very well?served with the chill Jan name server you have deployed down there. I just wonder why the rest of South America is not ?? well, has such a long round trip times other than chilly?
SPEAKER: I have no idea right now. We need to explore it a little bit, those results are about a week old so we didn't do any proper checking yet, but yes it's French and ?? or maybe we will get
Answer:
AUDIENCE SPEAKER: Could I comment maybe, South America there is no ?? not many exchange points there so maybe all the fibres go to the north and back to north America and back so that could be the reason.
AUDIENCE SPEAKER: Exactly more or less was my question whether you sort of mapped your findings on to the topology that exists, simply exists down there?
AUDIENCE SPEAKER: I can confirm there is no good routing policy back in South America, so actually, the node that C Z.nick has there is ?? twice Peta now and they supposed to be working with everybody in Latin America, but it's not the case.
AUDIENCE SPEAKER: OK. Thanks.
CHAIR: OK. Thanks. Any other questions? So with that, thanks Jaromir.
(Applause)
This brings us almost to the end of today's session, we have now any other business and already had one item on the any other business. Any any other business anyone? 3, 2, 1 ? gone. OK. So, now, to conclude, I would like to express a couple of thanks. First of all, for compiling the agenda, thanks go to Jaab and I would like to thank the colleagues from DNS org, Wayne and Marco. We tried to compile an overall DNS topics agenda for a couple of meetings this week, for those of who had to, well, say, attend more than one session and we hope that worked out quite well so thanks to these colleagues again, thanks also to the staff from the RIPE NCC for doing the slide juggling and I think veg in a and Alex for doing the Jabber scribe and Adrian for taking the minutes. Anyone else I forgot? Oh of course ?? that is going to be fun. Of course I would like to express my on?line thanks to the stenographer for doing a marvellous job here, helping us getting everything captured. We can express our applause here. So with that I guess we can almost on time conclude today's meeting. I would like to say thanks again see you all in Rome and some of you outside some of you might be interesting in visiting the DNSMON exhibition stand to see what is going on in the RIPE NCC.
LIVE CAPTIONING BY AOIFE DOWNES RPR
DOYLE COURT REPORTERS LTD, DUBLIN IRELAND.
WWW.DCR.IE