SEC DNSsec 29 October 2007 Los Angeles, California. >>RUSS MUNDY: So a preliminary welcome, folks. I'm Russ Mundy. I cochair the DNSsec working group with Steve Crocker. Steve is the main organizer of the session today, and has arranged for most of the folks to do the presentations, and I'd like to wait for just a few minutes for him to arrive. I just spoke with him by cell phone and he said he is on his way. So that way, we can have him involved from the beginning and let him make a more complete and proper introduction of our panel here. And until he actually arrives, what I'd like to do is let our panel do a little bit of self-introduction, and tell us what their involved with the DNSsec deployment activities are, and just give us a real high- level blip about what they'll be doing in their presentation this morning. So Richard, let me start with you. >>RICHARD LAMB: Okay. My name is Richard lamb. I work for IANA. I work for actually David Conrad now who now is fort enough to be given the task of developing the DNSsec system for IANA to sign dot ARPA and as well as to work toward signing the root. And so that's been my introduction to DNSsec, and hopefully my presentation is going to be on relaying some of those experiences and hopefully those will be useful to others trying to implement DNSsec. >>NAI-WEN HSU: [inaudible] dot TW domain name. So currently we are not a signer top-level domain, but we have tried to do some trial experience under DNSsec, so today we are talking about dot [inaudible] trial experience on the top-level domain name enable DNSsec. Okay. >>SHINTA SATO: My name is Shinta Sato, from JPRS, and today I brought some experience for the study of the DNSsec, what we've done for the dot JPs, and -- actually this really is work for my colleagues and I'm just presenting -- making the presentation for this, but I will show that data. >>HANSANG LEE: Good to see you, everyone. My name is HanSang Lee. I'm from NIDA, which is the registry of dot KR. Actually, me too, I'm not the actual organizer for the DNSsec deployment in dot KR, but I still manage -- I am the manager of the dot KR DNS, the whole system, and maybe I could just give a -- give you a good brief introduction to what we are trying to do in dot KR for deploying DNSsec. Thank you. >>STEVE CROCKER: Hi. I suppose I should grab a microphone here. Thank you all. I apologize for coming in late. The scheduling of these meetings is all a rather interesting puzzle and I was sitting in the president's report downstairs, which was supposed to be over in time to flow smoothly into here. So I appreciate the fact that everybody, except me, managed to come on time and be here. This is very nice. You've now heard introductions by each of our speakers. This is actually a very exciting point in the development and deployment of DNSsec. Some people may be aware that the original location for this ICANN meeting was supposed to be in the Asia-Pacific region, and there were some scheduling difficulties, so it's been here. So we brought Asia-Pacific here instead of having to go -- to go there. I think there is nothing useful to do except to proceed with each of these very contentful, very substantive presentations. We have until 12:30, and hopefully we'll have a few minutes or more to have some vigorous discussion, some open questions, and interplay with the audience. I see a mixture of people that I know and many people that I don't. I'm actually quite pleased to see a lot of people that I don't know because that means that we're not just talking to ourselves. Is that a sign that we're now being Webcast? >>SCRIBE: No. >>STEVE CROCKER: Oh, too bad. [Laughter] >>STEVE CROCKER: And Russ, did you get a to say something previously? >>RUSS MUNDY: I just started, yes. >>STEVE CROCKER: So Russ and I cochair DNSsec deployment group. I chair the ICANN Security and Stability Advisory Committee. I think the thing to do is just simply to proceed and maybe if you don't mind, I'd like to go in reverse order and have you start. Is that okay? >>HANSANG LEE: Okay. >>STEVE CROCKER: Okay. >>RUSS MUNDY: So is this the picture for the... >>STEVE CROCKER: And the reason why I did that is because I really want to focus on the country code implementation, so Richard, what I've actually done is select you to be last. >>RICHARD LAMB: Okay. >>HANSANG LEE: Nice to meet you, everyone. My name is HanSang Lee from NIDA, the registry of dot KR. Formerly they put up in the ICANN Web site that shows that I was in dot KP, but actually I'm in dot KR in South Korea. [Laughter] >>HANSANG LEE: Just a moment, please. This is not coming up. Now it's up. Today, I'm going to give you a brief presentation about DNSsec pilot servers in dot KR DNS. Actually we don't -- we didn't start the pilot service yet, but we are having a demonstration and making some presentation to the people who actually are interested in DNSsec in using dot KR. So why do we need pilot servers? Because based on reasons -- there was some reasons, like four kinds of reasons, and I think the market is not ready, but still the urgent needs are arising, and secondly, the users don't know how to actually work on the DNSsec, and -- well, actually they have the services. I think they'll be pretty much -- get to know and learn it. And third, the overhead of DNSsec for all zone is kind of having so much overhead and -- but still, better hardwares and softwares are coming, like -- you know, like NSEC3 when it gets to actually use it, so it should be more -- much more faster than now, and nobody uses it yet, but everybody needs to be prepared. Actually, we didn't sign all the zones in dot KR, but instead what we are trying to do is make another secondary domain name called SAFEDNS.KR and we are trying to open this to the public in the near future. Hopefully next year. And we are trying to implement DNSsec in this secondary domain name. So the actual work flow is the users who -- actually, these are -- we had a connection to the actual users who actually wanted to use DNSsec. Those are like banks or stock markets and government agencies who actually needs to use a secure DNS much more than other users, and that's why I put down the domain -- bank domain administrator down here [indicating]. And we had several contacts with the actual bank, internal banking service providers, and they are trying to -- they're really interested in using the DNSsec, and what they can do is they can actually connect to our DNSsec pilot servers Web site and register whatever their -- they need to use for the DNSsec compatible -- I mean, DNSsec usable domain name. They can make a domain name, and then use the DNSsec pilot servers from then. They make the domain name -- when they register the SAFEDNS domain, it comes to the SAFEDNS.KR nameservers, and actually the -- it doesn't show on this diagram, but DNSsec pilot servers, Web server, besides the Web server, it has a zone signing mechanism with everything else in it. So they can actually -- they can easily make the -- they can easily make -- register the domain with having their actual zone signed. This is another diagram about the actual signing mechanism. The left-hand side is the pilot service Web site, and actually you can create the KSK and ZSK and sign the keys -- and sign the zones with the keys. And the actual pilot domain register database, it goes -- it inputs it into the database, and it automatically generates the named.conf and sends those configuration files and zone files directly into their slave nameservers. This is another diagram for how they actually use it, and there are kind of two ways to use. When they have their actual nameservers, which is DNSsec-ready, they could use their nameserver to operate their own SAFEDNS, and if they don't, we are trying to provide our -- one of our nameservers, and to make sure they can use the SAFEDNS. Actually, I was trying to connect to the Internet and show you how you can actually -- how this registration works, but I couldn't have the connection right now, so I'll just show you -- I just captured all the Web pages step by step. Let me just show you about this. This is all in Korean language, but still you can see the actual configuration down here [indicating]. Over here [indicating], you can see the user ID and password, so they could actually log on. This is the first step of making the registration of the SAFEDNS. You can actually put down your domain name right in front of your SAFEDNS.KR. This shows if that domain name is usable or not. This is the first step of making -- selecting which nameservers they are going to use. If they're going to use their own nameserver, you can select it right here [indicating]. The second one is if they don't have a DNSsec-ready nameserver, they could also -- they could select to use one of the -- NIDA's nameserver. Over here [indicating], when you actually create your domain -- for example, mydomain.SAFEDNS.kr, you can put in your SOA records and put in your master nameserver and secondary nameserver, also the A records for the nameservers. And when you click the next button, it automatically generates the zone file. And this one is for the -- making the keys. You can actually select one of the size of the key. Mostly default is 1024. And this shows what happens if -- after you make the KSK and just hit ZSK DNSK resource records. So mostly, this is a step-by-step of registration -- registering our SAFEDNS.KR pilot servers. We are trying to open. It's now a closed service for -- only for the banking -- internal banking services or the stock services or the government agencies, but we are trying to open it up as soon as we can when the market is actually ready, and for -- mostly we are trying to do -- we are trying to sign every zone. Hopefully if root and -- like the -- one more thing is, about DNSsec, when you need to -- I mean, the actual users need to use it by having the Internet connection to the telecompanies, and most of the ISP are not aware about DNSsec in Korea. So actually the cache reservers should be having the DNSsec-capable reservers, so we are trying to educate the -- not educate, but give them more information and guidelines about DNSsec and when the market gets ready, we are trying to deploy a full DNSsec usable name services. Thank you. [Applause] >>STEVE CROCKER: I think we'll -- we'll try to aggregate questions toward the end, unless there are any that are urgent right this minute. >>SHINTA SATO: Okay. Again, my name is Shinta Sato from JPRS, and today I brought here, the title is "A Brief Introduction to JPRS' DNSSec Implementation Research for TLD," which I show you some incremental signing system we made in the research activities. I'll skip this contents. Our background is shown here. Currently, the dot JP has 1 million domain names. Almost 1 million. And we are making frequent DNS updates, which is conducted every 15 minutes. And there is about 30 DNS servers which has the dot JP zones, including the standby servers and not answering queries -- some of them are not answering queries, but there's 30 DNS servers there. And for the issues regarding implementing DNSsec, what -- the reason we made this research was that the zone signing with existing tools, like DNSsec-signzone takes longer time than our update interval. Which means they take about 20 minutes or something to sign whole zone every time, so that doesn't make sense in 15 minute updates or much more frequent updates, so we have to think about something for there. And we decided to create some prototype implementations to solve these issues. That's the background. Here's our current system. Just a simple system. And we registry database in the left-hand side right here [indicating], and every 15 minutes we extract all the -- all zone data from this registry database, and put it into the BIND 9 server, and there we use ixfr from differences functions and make the ixfr data from that whole zone data and server them to the DNS servers here. And this two places are the bottlenecks against update -- making further updates, frequent updates and creating related DNS resource records. Okay. We made some requirements defined for this research. Dot JP is increasing from -- still increasing, so we are making target to 10 million domain names, so thinking of the large size zones. And much more rapid updates are demanded, so we are thinking that we are making updates in every minute, and in that case, the maximum updates can be done in 10 second -- within 10 seconds. A hundred domains updates can be done. That will make the requirements suitable for our zones. And furthermore, reliable zone data synchronization is requirements for our TLDs, and of course DNSsec capability. And we think that the NSEC -- we are not thinking to use NSEC, but NSEC3 for the -- our TLDs, if we make the DNSsec available in our country. And one more thing is about the key management. Generating the zone signing keys and making the key rollovers, that will be the requirements. Okay. And here's the design concepts of the prototype. Our concept is to do that in easy integration to current registry systems. We don't want to change so much for our existing registry systems, and DNSsec and related features will be provided in the -- some other components. Other components separated from the registry systems. And we want to use incremental manner for extracting the data from registry database. And data integrity checks of DNS servers, we want that to -- we want that -- to do that without service interruptions. Even in rapid-update environments. So we made the two new systems. One is the zone distributing system and one is the integrity checking tools. And registry system and DNS servers are the same what we are using. Okay. Here is the system diagram. This gray area in the middle of the figure is what we created in this research. Zone distribution system and integrity check tools. This is current JP system -- registry system [indicating], registry database. They push update information for the domain to the interface modules, and they extract the data from this data -- registry database, and put it then into the zone distribution system. And they'll make the incremental zone data synchronization to the -- some other nameservers. And that's what zone distribution system does, and integrity check tools, they monitor all the DNS servers and compares with the zone distribution systems which holds the whole data of the nameserver zones. Okay. Zone distribution system is the somewhat intelligent box between registry system and DNS servers. This does the incremental data extraction from registry database and they provide -- this provides ixfr/axfr for BIND or NSD or whatever the DNS server is. And it manages the zone data revisions, and this distribution system is possible to obtain any number of serial of zone data. You can choose any serial -- SOA serial number to extract from these systems. This is used for the integrated check for the nameserver. And of course DNSsec features this has. I'll explain this in next slide. DNSsec features of zone distribution system is -- this system is compared to NSEC and NSEC3 both. Zone signing key creation and RRset signing for all domains of the registry database, it will be done in the system initialization phase. Incremental RRset signing according to the updates on registry database. And it has semiautomatic zone signing key rollover and resigning of the RRset. The reason I say "semiautomatic" is the KSK -- private key of the KSK has to be attached every time use it and manually and that's -- and because of the security reason. And that's the reason we call that semiautomatic. But everything else is done automatically. And also for the key rollover, we can resign the zone. After the signing, all the DNSkeys and RRSIGs are deleted with some appropriate time considering their TTLs. I think I will skip this integrity checking tool because it is not for the DNSsecs at this time. We check the performance of the system and what we find is for the current registry system and if we add DNSsec function to this system, we will take about 25 minutes to -- from entering some data to the registry DB. And you see the data in the actual DNS servers. It will take about 25 minutes, and most of this time is done in this DNSsec signing zone functions. In the prototype system, we take about only 10 seconds to see the actual data in the DNS servers. Zone distribution system is doing this zone file generation and DNSsec signing zone in incremental manner and also distributing the data to all other servers. It takes only about one second from extracting the incremental data from registry database and signing may take just about five seconds. And incremental transfer of the zone data will take only about three seconds or something, so it is about 10 seconds from entering the data and seeing that in the nameservers. Yes, it is far better than the current system. Well, we made this system and actually we did some field tests, not only for the -- we did not just made the system but we attached that to the real dot JP systems, checking the update latency from JP registry database change and data integrity checks for long-term running. But, actually, the field test was not done with DNSsec signing due to some implementation problem at that time. We connected this system to the real dot JP registry database for one month and the DNS servers we used for this was not open to answer queries, but we made many -- applied pseudoqueries to the servers to see what happens. This is the field test scheme. The lower one is the system we are using right now and we put the prototype system in some other place and we extracted the incremental data every minute and zone distribution system made ixfr for some testing servers, and we applied pseudoqueries which was pulled from the real servers to the nameservers. Okay. What we have to do for this field test was some modification to dot JP registry, and we created some new dating port Java class to the zone distribution system and it was very easy to put it to the real system. The result, there was only -- we only need two seconds for dot JP data update in this field test and we didn't see any data inconsistency after one month running, so it was very good test and it was good results. So this is the last slide, I think. What we have done is we developed incremental data processing mechanism from dot JP registry updates, which included DNSsec signing, key and management features. This was designed as the zone distribution system. And field test results satisfied the requirements of the dot JP TLD. We can say that there -- DNSsec is appliable with very rapid update system and also for the very large number of domain names, TLDs. That's all I have here. Thanks. [ applause ] >>NAI-WEN HSU: Hi, everybody. I am Nai-Wen Hsu, TWNIC. This is the content on my presentation. First, I am talking about why TWNIC want to implement DNSsec and that we are talking about the pros and cons of DNSsec and some DNSsec issues and the time schedule. Why we want to implement DNSsec? Because one of our customer has some issue so we need -- we must implement DNSsec. And DNS poisoning and BIND vulnerability, there may be some issues on the DNS server. It is a real case. There is MSN.com.tw. It is a famous portal in Taiwan. Microsoft has domain name. In Taiwan, the default Internet Explorer, the default home page is to the (inaudible). But there is some error here. The first DNS and the other, they are a little different. The first one you can see here missing a dot here. But the error run for many years. Nobody find there is an error here because the DNS protocol (inaudible) capability involving redundant. If you send queries to the false DNS server, you are not responsible because it is just a host. So always MSN.com.tw always responds because they are still false DNS server (inaudible). There is an error on the DNS compilation. So the registrar cpmsft.net domain name and the server DNS for Microsoft Taiwan, so he can hijack 20% of the (inaudible) traffic. The hijacker is not the intention. Just try to tell Microsoft that the domain configuration is in error. But we think about this issue. We must do something for our customer to protect the DNS data. We assume we must enable DNS on our domain name. Another issue is DNS cache poison. It means that you can change your data in our cache DNS server. When the user send a query to cache DNS server, maybe the user is controlled by the hacker. The cache DNS server try to find an authoritative DNS server and send the query to the authoritative DNS server and wait for a response. But in the time, the hacker can send a fake reply to the cache DNS server and the cache DNS server will receive the fake reply. And also this cache DNS server response will not be (inaudible) response. And the hacker can change the data. And the cache DNS is caching the wrong data in each case. The DNS protocol uses transaction I.D. to verify authenticity. The transaction I.D. is only 16 bits, so you can send n spoofed replies for one query and the probability of this is N/65,000. Someone says it is secure. But you can -- if you know the birthday of the attacker, how many people in an office, two or more share the same birthday, the probability greater than 50%. The answer is 23. You can calculate 1-P, the P is the probability of N people not having the same birthday. The formula looks like this here. So DNS cache poisoning. The DNS changes the I.D. from 1 to 65,000. So you can send 302 queries and 302 replies, then you have the probability of 50% success. If you send 550 queries and replies, then you can have 90% success. If you send 950 queries and replies, then you can get a 99.9% successful rate. So these are the things I can use the function to change the cache DNS server data. And there is a BIND vulnerability. In two or three months ago, the BIND 9 and the vulnerability, the transaction I.D.s depend on the BIND 9 and BIND 8, the number is not important. If you know the current transaction I.D., you can get the next transaction I.D. So it is very dangerous. The SANS top 20 Internet security attack targets. Since 2005, the DNS is in the top ten. I think in the future the DNS servers is always in the top ten of attack targets. So how to protect against DNS server. I think DNSsec is one solution. The DNSsec can help with data spoofing and corruption and be the man- in-the-middle attack. In the case of msn.com.TW, you will not be hijacked by a hacker. Also, the hacker, with all the pirate key, all the MSN.com.TW, so he cannot create his zone sign for Microsoft. The DNSsec cannot provide confidentiality of DNS responses because it does not encrypt the data and it does not protect against DDOS attackers and it does not provide authorization. In RFC4035, introduce 4 RRs for DNSsec. The first one is DNSkey. It contains the public key of a zone. And the second is RRSIG. It will put a signature in the resource record in the NSEC. NSEC, every name in the zone -- NSEC resources is going to contain the next name and resource types of the name. This is the issue on the DNSsec that I will talk about later. And the DS resource record, the DS resource record point to a child zone to a public key. We have tried to enable our dot TW domain name to try DNSsec. We must have two minutes. But when we enabled DNSsec, we had 21 minutes. Almost ten times. But we have multi-files that (inaudible) program and that uses some hardware before (inaudible) CPU server. We can reduce to 10 minutes. And the zone file size from 20 meg queries to 97 meg. We test the query time. One query 3.47 microseconds to 6 microseconds. The query time included (inaudible) time on the network. We just tried from our office to our DNS server every two times. And the start named server, almost four times our original because of the zone file size is bigger. There are some issues with DNSsec. The first is the key maintenance and the root server enable DNSsec and the zone walking issues. The key maintenance. When the key change, you must distribute the public key to end user. How to distribute public key. (inaudible) resource record. But we prefer to enable DNSsec in the root zone so we can update the key in the root server. And how does the root server's key get to end user is another issue. We know that there is to RFC (inaudible) a key rollover. The key rollover issue maybe is not an issue. And zone walking. I talk about NSEC. The NSEC, there is an issue on the NSEC just about zone walking. You can get a NSEC resource record (inaudible). So, for example, the (inaudible) also enables the DNSsec. You can query the NSEC, dot SE and you can get a 0-0.se and you query the NSEC resource record 0-0.se and you can get a (inaudible). The security issue, attacker and hacker, it is easy to identify the target because it can load whole zone file and the spam is easy to collect spam list. And there is a privacy issue. You can send to WHOIS and get personal information. Actually, we have regional meeting in Taipei several days ago and the (inaudible) NSEC records were published. In the NSEC registry, the zone walking issue will be solved. We expect to implement DNSsec on dot TW zone in one or two years. NSEC3 publish as RFC and, the root server has DNSsec. So if the key rollover and the zone walking issue are solved, we have (inaudible) to our customers. And when the (inaudible), we reduced DNSsec service to our customer. Okay, thank you. >>RICHARD LAMB: Okay, all right, there it is. All right. My name is Rich Lamb. I'm going to describe some of the work that we've been doing at IANA regarding deployment of DNSsec. We started a lot of this work at the beginning of the year, so some of it is still a work in progress. First of all, I would like to thank a lot of people in this. In order to avoid having to take the same path -- difficult path that others have taken already, and being that my focus was very much an operational one, I wanted to make sure whatever we came up with was maintainable and reliable and so what we did was we looked to see what systems were already out there. And there are very few. And Sweden was one of the very few that had any operational experience. So we relied a lot on some of the folks at dot SE, particularly Jakob was very, very helpful. Without him, I would still be in the dark. Then we actually got a lot of help from some of the work that has already been published out there to try to make DNSsec easy to implement and understand. That was the DNSsec how-to as well as the RFC4641 which actually laid out some of the parameters, key sizes, rollover times and things like that. So based on those two things, we developed a lot of the technical work. Last, but not least, without some of the guidance and nudging by Steve Crocker and the DNSsec deployment group, we wouldn't have made it as far as we had and also thanks to President's IANA Consultation Committee. I wanted to make sure -- this is not work that I have done alone. Thanks. All right. Our goals were in this order. Maintainability. One of the difficult things about DNSsec is how to make this -- make it easy to use. It's -- the key rollover mechanisms are not easy to understand and so we -- we were looking to try to simplify this as much as possible. This is one of the main goals here. Reliability was another one. DNSsec already has a little bit of a time being adopted, so any error would be a bad error. Any failure would be a bad failure. We wanted to make sure that any user experience would be a good one, so customer's always first here. That was the focus here. Security very important as well. But it also has to look secure as well as be secure. So there is some work that I will describe toward the end of us where we use hardware devices to store keys because that's what the financial community uses and lot of the militaries use to have a certain level of trust. Our target, the goal was to have by this meeting dot ARPA signed with secondaries ready to go. Not quite there. Technically everything is done. We're still working on what's often referred to as Layer 9 issues, actually some contracts, agreements, looking for the right secondaries to provide some of this data. So we're still in that stage, but technically we're ready. I don't see any major obstacles in the way here, but that was our goal. This platform that I've developed is also designed to act as a demonstration platform for root zone signing and it has actually been operating that way for many months now. It is open to anyone. I even have a mechanism in there to supply DS records if someone wants to submit a DS record. More on that later. There are other ways that I would like to get a lot of feedback from the community to find out what the best way to get a DS record from someone is. We're also signing dot Int. That's again something that has some issues that are beyond my control, definitely beyond the control of a lonely engineer like myself but there are things that we need to overcome there. But, technically, we're ready and we have had some feedback actually on the demo side already which has been very good, very helpful. Particularly for a newbie like me. Let's start right off with the picture. It is a very simple design. I will have to admit some of the previous speakers have a much more difficult time than we would have at IANA. They have millions of zones, millions of domain names they have to sign. They need something that is actually fast as well as secure and reliable. So we don't have some of those problems, and I took advantage of that in the former reliability. The dotted line is what we have implemented right now. We have proposed something to a mirror site to actually operate in Europe as well because that's -- we live in an earthquake zone here. It would be -- it would make sense to have at least one other place that acted as a backup to all this. So, anyway, that's the basic layout. HSM there in the corner. Mid left-hand corner is a hardware security device. That's where we were storing keys. Keygen is the key that actually generates the keys. If you are familiar with DNSsec, KSKs, ZSKs, zonesigners are the ones that take the zone and sign it. There are multiple of those for multiple reasons and then the zone generation machine is actually what might be called the hidden master. All right. And even more details. If someone is interested, I'm sure this presentation will be up on the net at some point. Real I.P. addresses, real design, one of the things I have the DNSsec deployment initiative to thank for is to emphasize points of transparency here. For a number of reasons, we want to show exactly how the stuff works. There is no security through on security. From my point of view. If there is a problem, I want to know now and not later. So, you know, if someone is ready to throw a tomato, do it now so that I can try to fix it. Anyway, so that's details. All right. Actual hardware that we have running this is commodity stuff, a couple just regular Dell 1U servers. Each one of those servers, each one of the boxes in the first picture, first figure, represent a run by a 1RU server. Nothing special about these things. 2 gigabyte of ram. Not particularly fast or anything. The security module that holds the keys is something we selected. It's -- that's the name of it, AEP Keyper Pro. The important thing to note there is it's FIPS140-2 Level 4, which means that if the box detects that it's been tampered with or someone's tried to get the keys, it destroys the keys, self-destructs the keys. It's not -- it doesn't blow up or anything. That would be cool. But it just destroys the keys. And it's an external device because this is something that we would like to not have to replace often because it's a difficult -- difficult device to program. And something to access the machines, smart cards, flash drives. These things are all located in a rack inside a colo facility not far away from here. It's inside a locked rack within another secured cage in a very secure 24-hour manned colo. Again, if there's any suggestions, people have more experience with this sort of thing in the financial community, we certainly would like to hear them. All right. Maintainability, one of the most important things was to make sure this was something that could be maintained. The key updates, key rollovers could be done in a -- as automated as much as possible fashion, but if manual, then something that could be handled pretty easily. So there's two scripts. It all boils down to basically these two scripts, signall, keyall. Signall is just run by chron, or just periodically run on the zonesigner machines that looks at the serial number for zone files. If it's -- if it's been changed, if it's been incremented, it actually then triggers another resigning of that zone file. It looks for any new DS records. In other words, child zones that have been handed to it and expiring signatures. Wants it's done that, signs the file, sends it to the hidden master, kicks reload and then also tries to generate some status -- some statistics and things for a statistics Web page, which is publicly available and publicly visible. It also sends e-mail notifications out because after while, this can start to be annoying, so you -- at some point you do want to just send e-mail when things have to be done. Keyall is the half that is actually done to -- used to generate keys. It's got to be run on a monthly basis. That's, again, using some of the guidelines in RFC4641. A lot of these implementations tend to fall in this monthly range so every month a new ZSK has to be generated so this is a script that is executed by someone who visits the collocation facility and just runs the script and that's it. Doesn't have to worry about anything about what actually it's all doing, so to try to simplify this as much as possible. All right. And also, I'll get to this later. It also backs up some of the keys inside the crypto device, does this also transparently. All right. Borrowing from the excellent dot SE implementation, we used three keys, three ZSKs, and three KSKs. The KSKs are the top- level keys and the ZSKs are the keys actually used to sign the zone file. So the ZSKs are the ones that get replaced every month. We have three of them there, so that when we introduce a new one, it's very easy. We -- one -- they're staggered, so that one -- one expires, the next one gets used, another one comes in and expires. It's this kind of rolling thing and it makes it very easy to replace ZSKs. It's literally just a matter of generating another key and sticking it in the system and it just propagates through the DNS -- DNS system naturally, without having to worry about TTLs or caches. So that's why we have three of those. It's -- KSKs, we have two, again, for the same reason. If we need to replace one for any reason or the yearly -- the KSKs get generated every your in our particular design and when that happens, all that has to happen is another KSK introduced, one deleted and it will automatically get propagated through the DNS. Again, all of this is taken care of through one script, so the operator just needs to execute that command and everything else happens. Below that is just a diagram, a little bit of a geeky diagram for myself. It's something that actually lays out the -- the key lifetimes in a form that I can -- I can see, and it's actually something that's displayed to the person running keyall if they want to know how long it is before a key is going to expire. So all right. We also tried to -- this is not often addressed. The compromised key situation. Because it's supposed to be very rare, and it is very rare, which is all the more reason to make it something that is automated as much as possible because this could be when -- when panic ensues. So we've decided to try to make a script for this as well. I've created a script called badkey for lack of a better name, so someone gets the ID for a key, enters it into the badkey script along with domain name and it -- it encompasses all the logic necessary to remove the old key, replace it -- generate a new key, replace it, and then carefully propagate out that to the -- through the DNS. So there are some explanations there. It's -- you know, you can read it, if you want. And by the way, I mean, I'll say this later, but all the software that's been developed here is all going to be open-source, available to everyone. That's, again, very important for a number of -- not just for transparency but also for sanity and making sure that we're doing things right. You see there, there's something if both KSKs go bad, that's -- you know, so if all security is lost, it is a very -- it is a question mark there, because there are still a number of questions about how one would handle that effectively, so, you know, this script would handle it. But to replace a key is basically going to cause some problems for people that are relying on DNSsec down the chain. Reliability was another issue. Focusing on customer service, and that's more from -- from my background in the past, I just -- you know, customer service can kill you. You just need to make sure that the end user is happy and you get no phone calls, and so reliability was very much of an important thing for me. So we have two signers, two zonesigners. Two machines running the same program, Ping-Ponging off of each other. That way, if one misses it, the other one will catch it. Commodity machines. Just thought that that would be -- that would be a good design. So... Reliability again key backup. Since the device we chose for storing the keys self-destructs, if someone tries to break into it or, you know, more likely somebody kicks it, drops it, something like that, we had to make very, very sure there was a way to back up these keys. Because there's no recovering them. The keys are generated inside the device. No one ever sees the private keys. So there's no way to know what they are. So we spent a fair portion of my time developing a system to back these up. These keys are encrypted inside the box, sent out in encrypted form, and then transferred to an exact duplicate device somewhere else where there they can be -- it's called "unwrapped" as opposed to "wrapped" -- unwrapped inside the device and stored there. So this is also automated, built into the second-script keyall, just to try to simplify the process. Nothing really new here. I think a lot of people follow this -- this particular paradigm. They split KSK generation and ZSK generation. They make sure that the key signing keys, the secret-secret most important ones, the long keys, are stored -- are generated in a separate off line device and saved there. So this is -- this is something. And, in fact, just -- just like one of my fellow speakers, the key generation machine is not connected to anything. It's only connected once the key is generated to transfer the key over. All right. This is more on the crypto device. It's HSM stands for hardware security module. They're standard in the financial industry. One we picked, I'm told -- although I can't -- I can't -- you know, this -- some of that is just proprietary information for the vendor but I'm told a number of credit card uses it, some Department of Defense organizations use it, and it's manufactured by an Irish company, actually. So that -- just thought I'd throw that out. It's -- you know, it's developed by engineers. All right. Let's see. Okay. So I mean, all the information is -- the keys are generated inside. One of the things that, again, took me a long time was, this is a new -- this is a new territory for a lot of us Internet guys. We don't deal directly with the financial community too much, so they have a whole bunch of standards called PKCS11 and PKCS, you know, 7, 12, et cetera. Anyway, I wrote tools to -- a modified BIND to directly support this protocol in BIND, so that we could actually use the HSM effectively, and that was a difficult thing. Again, I'm going to publish those tools as open-source, because examples that it particular area were very scarce and others have approached me for them as well, so I'm hoping that that's a positive contribution I can make to the Internet community. Let's see. Last bullet there, just as a matter of practicality, we actually use regular software keys for some of the KSKs that lie under dot ARPA. This is in the current setup. This could change if someone thinks that's a bad idea. You know, the hardware and software is there, but we do that just to make it fast and easy to maintain, and it's also easy to recover if you control both the parent and the child in DNSsec, so... More details. The 1024 bit key for the ZSK, 2048, this is -- yeah, repeating some of the other stuff, two KSKs so there's orderly replacement. The signature -- the signatures on the zone file are good for six days. We deem this to be a reasonable time, enough to recover some -- from equipment failure but also limit replay attacks. 1.5 months, as I said, the new ZSK is generated every month. 1 1/2 months gives a little bit of leeway, so at the beginning of the month, the DNSsec administrator gets an e-mail that says "Wake up, it's time to go over and generate another key." Well, he's got about two weeks. So it's not that critical. You know, if -- it doesn't have to happen exactly on that date. So let's see. All right. This is more on the key backup. This is -- I apologize for saying a lot about this. This was something that just, like I said, took a lot of my time and so therefore, I'm kind of interested in it. So I mean, the keys -- keys are encrypted inside this -- inside the box, so they never reach the outside, and no one ever sees the private key material. The encryption is done internally, and the key used to do the encryption is backed up onto a number of separate cards, so that no one person can regenerate that key and effectively copy all the private keys. And that's a standard procedure in the HSM community. All right. This is -- this is an area that's still -- still a little bit in transition, but who could -- who holds what is one of the questions we had. Just strictly from a security point of view, not from a political level, but strictly from a security point of view, what makes sense? So the way we have it now, there's one security officer that -- two people, at minimum, have to go to the colo to perform a key signing. One basically to watch the other. To make sure that things are done properly. So one of them will be a security officer with a car which enables the HSM -- the HSM will normally not be enabled, and another one that actually runs the keyall script and has the PIN number for that. That's -- this is, again, parallelling a lot of the difficult and very sensitive work that dot SE did in this whole area. They helped by sharing some of their operational documents with me, and so this -- a lot of this is patterned on that. I think we're doing the right thing here by -- by ensuring that there's separate control of these different components. Of course the equipment's secured in a -- in a facility, so there's actually that aspect too. Whoever needs to do this signing needs access to the colo facility. That very last bullet on there, complete catastrophe. These are all - - every one of these conditions have to be considered. What do you do in complete catastrophe? The machines are -- there's an earthquake or machines are completely blown away. You can't get at them. There's got to be a way to recreate these things. That's kind of a sticky situation, because that means one person's going to be able to have access to everything and they need to copy everything. So that's -- that's a situation where we'll break it up into a number of safety deposit boxes, separate keys. In our case, current setup has two -- you need two out of four of these smart cards to regenerate the special key, and if you split those across multiple sites and even if a couple sites have a hard time getting -- getting back to building or rebuilding a system, this should be enough redundancy to create another system and still be secure. All right. Software, like I said, all modifications and software that we've developed, open-source. There's a list of some of the problems that I'll make available. And I'm sure I'll get some feedback from some of that. That last piece of software there, the zone generator is something called upsite. It just pulls together all the various statistics that are generated and tries to create a pretty Web page. Okay. The status page that we have for this DNSsec setup right now is at that URL. I've tried to again make it as simple as possible by having those bars on top, which literally just check machine health, whether keys need to be generated and, you know, they change between red, yellow and green, basically, and so that's part of it. The page, as you notice, is HTTPS, so it's SSL'd itself. One of the things that would really be bad is if someone, you know, had a Web page up with their root key up there, and someone spoofed the Web page or, you know, hijacked the Web page and put up their own root key and then all of a sudden, you know, they've gotcha. And for the ARPA keys, if you go -- if I was able to show the whole page, I mean, the demo root is up there, and then there's a dot ARPA and dot Int below that and they scroll down. The keys are -- the large blogs on the right-hand side there. They're also signed with a PGP key, so this is belt and suspenders time. So we have two elements to make sure that people are going to get the right key. Now, those keys on the right are -- some [inaudible] you need to be able to take those, copy them and just put them in your named.conf file or what have you. Let's see. All right. And then I've been approached by a lot of people, okay, how do we participate in this -- in this demo? At least as far as the root zone area is concerned. We have something called a root zone management system that IANA is developing. It has information -- contact information, as well as NS record information in it. We envision that that will just have another field for DS records, so that should handle the majority of ccTLD or it would DS record, parent/child relationship, DS record handling. We also have this demo up that just -- just to see how it works. Basically, in this demo, you type in your top-level domain name in the field, click "Submit," the implementation goes out the back end and grabs DNS keys off of the public DNS and generates DS records, displays them to you in the second image on the lower right-hand corner, and if they look okay, you click OK, they're submitted into the demo, and signed, and published. So on this particular note, we've had, like I said, a number of conversations with people. There are other mechanisms that will -- we'll probably be supporting here that give the child zone more control over this. In fact, there's been some recent experience that says they should even have control over their TTL as well. So... All right. That's basically it. You know, I'm -- I'd love to hear what people think about all this. Compromised keys is one of -- one of the questions that's always brought up every time someone says, "Why isn't DNSsec -- you know, why isn't DNSsec more popular? How do you recover from a compromised key situation," particularly if both keys are compromised?" Compromised here, by the way, is going to be something that would be mostly key guessing would be the only way to do this, because it's all -- again, like I said, generated and stored inside a hardware device. But nonetheless, there are a lot of bored graduate students out there. They might find some way to do this. You know, I spent some time once doing that so, you know, I could see that being a problem. So I'd like to have some feedback on that. How do we detect it? You know, if there's a compromise, other methods to accept child zone information would be great. Any other suggestions? Thank you. [Applause] >>STEVE CROCKER: Thanks. Before we move right to questions, I see Danny Aerts here. I want you to stand up for just a second. This is the head of the dot SE operation, and under whom all the pioneering work there has gone forward, so I thought it was -- and I know from firsthand experience there, as you do, Rick, that this didn't come for free. There was a considerable amount of energy and effort there, and leadership, so I want to thank you very much. So it's time for questions. I've got a couple of questions that I can put forth, but I'd rather that things come from the audience. Has anybody got burning questions or points -- aha. Now, we need a microphone. >>OLIVIER GUILLARD: I can talk like -- [Speaker is off microphone] >>OLIVIER GUILLARD: Hello. Thank you very much for the interesting presentation. Do you hear me? >>STEVE CROCKER: Can you identify yourself? >>OLIVIER GUILLARD: Yeah. Olivier Guillard from the French registry and also chairing the IANA working group for the ccNSO. I had a couple of questions with regard to your presentation. One of them is who is maintaining the PGPK, which is used to publish the root zone K on the Web sites. The PGPK that you used to publish the root zone K on the Web sites. >>RICHARD LAMB: It's a demo system. I'm maintaining it. >>OLIVIER GUILLARD: Okay. >>RICHARD LAMB: Yeah, I mean, again, suggestions would be -- suggestions would be welcomed. >>OLIVIER GUILLARD: This is one of the hot questions. To let you know, I couldn't -- I couldn't -- >>RICHARD LAMB: Okay. >>OLIVIER GUILLARD: -- I couldn't verify the data using this key. I got a wrong signature, just for your information. Another one, which process do you use today to pick up the DS key from the -- from the -- from your user, and what kind of process do you consider to use in the medium term. >>RICHARD LAMB: Okay. Good question. What we're using now for -- again, I want to emphasize dot ARPA is real, root is experimental. >>OLIVIER GUILLARD: Yeah, I understand. >>RICHARD LAMB: Okay? All right. Right now, we're using -- I mean, I have some scripts that's basically scrape. Scrape meaning walking down the root zone file and seeing if there are any DNS keys published for any of the -- any of the TLDs. If they are, I take it, I generate a DS record, and stuff it in. So that's -- that's one way. The other way is through that interface I have. Now, for the long term, which is probably what you're really asking, how we want to accept DS records if we go forward -- right? -- is there's this root zone management system that's being developed by IANA, and it -- and it's a natural extension to that to have another field in addition to just the NS records as a DS record. Now, if this is not something that makes a lot of sense, you know, it would be good to hear of other things. I just came back from the RIPE meeting. There's definitely interest in the children -- the child zones having tight control over when that DS record is submitted and, you know -- including TTL and other things about that DS record. I'm open to suggestions. Others have suggested some of the RIRs that have many DS records, not just one but say 35, 40 DS records for in- addr, for example. They would like to ship across them in bulk. I've talked to some SCP. You know, if we just use some sort of secure shell where you generate the public/private key pair, you hand us the public key so that then you could transfer the file directly, and we accept it. It's -- some of this is actually perception, too. It's got to also feel -- both from your point of view and everyone's point of view -- that it's secure. So short answer: I don't have anything official now. Okay? >>OLIVIER GUILLARD: Sorry. Maybe a last one. >>RICHARD LAMB: Yeah. >>OLIVIER GUILLARD: Would you consider to publish the root zone -- the same root zone using a DNS -- an experimental DNS rather than the Web site? >>RICHARD LAMB: It is. Port 53, just go ahead. It's wide open. >>OLIVIER GUILLARD: Thank you. >>RICHARD LAMB: And it's been open for a while and if you can try to break it, break it. I want to try to break it. >>STEVE CROCKER: Okay. Other questions? Let me insert a question or two. Mr. Lee, on the Korean one, you talked about beginning to engage with the ISPs. How many ISPs are there in Korea? I remember from the interactions in Sweden that there was relatively few, and that made it easy to bring the ISPs into the situation. >>HANSANG LEE: We have more than -- I think for every ISP, it's about a hundred, but it's all small. I mean, small ISPs. And the majors are all the big three, so we are concentrating on making contact with them, and actually they have our secondary nameservers operational and we have a close content with those major ISPs, which is like KT, Korea Telecom, or LG Dacom, and stores like that. And I don't think we have that much issue about making contacts and having a discussion about implementing DNSsec into their [inaudible] DNS servers. >>STEVE CROCKER: That sounds like very good news, actually. Shinta Sato, in Japan, so you have quite a big operation, actually. My understanding from what you said toward the end is that you simulated side-by-side operation by rerunning the queries that you had accumulated for a period of time? And then running those through DNSsec? >>SHINTA SATO: I don't need three of them. [Laughter] >>SHINTA SATO: Okay. What I -- actually, we did not simulate any queries of the DNSsec. We just made the queries -- we took the queries from our real servers and [inaudible] them to the testing servers, so it's not for the DNSsec. >>STEVE CROCKER: Ah. I see. And have you done any testing of DNSsec queries? >>SHINTA SATO: Well, just testing for the servers, but not for the -- that -- that -- the system being made. Okay? >>STEVE CROCKER: Uh-huh. All right. >>SHINTA SATO: Because that's -- DNSsec is -- the DNS server is only in the edge side, so we are not concerned about is that right now. >>STEVE CROCKER: Okay. Thank you. Nai-Wen Hsu, from Taiwan, you put up some numbers about the -- how much longer queries take, how much more memory, and so forth. And I wanted to go back and visit one or two aspects of that, if I might. The numbers I jotted down say that the time it takes to respond to a query was close to two times the normal time. >>NAI-WEN HSU: Yes. >>STEVE CROCKER: And that the amount of memory was about five times. >>NAI-WEN HSU: Yes. >>STEVE CROCKER: And that it took maybe ten times to create the zone and four times to start the -- the process up. I don't have precise numbers, but I've been accumulating numbers over a period of time and I have some rough rules of thumb in my head. The memory expansion of five times is comparable to what I think we've seen in a lot of places. >>NAI-WEN HSU: Uh-huh. >>STEVE CROCKER: The time to respond to a query seemed to me high compared to other numbers that I've seen, and I was wondering if there was a reason why it takes that much longer to respond to a query, to a signed query than to an unsigned query. And if I might, one more question. There's a different statistic which we've also seen, which is the amount of bandwidth that it takes in the response is longer for a signed query, and I don't think you spoke to that particular number. >>NAI-WEN HSU: Okay. Actually, the response time includes the round trip on the network. I see maybe the network bandwidth is an issue, because the DNSsec package is more -- the size is larger than the package without enabling DNSsec. >>STEVE CROCKER: Aha. Yeah. So the figure that I've had in mind is the amount of CPU time and whether or not there was more load -- how much more load there is on the CPU, and that, in past experience, my understanding is that's been relatively modest, and you're saying that the number that you showed includes the transmission time. >>NAI-WEN HSU: Yeah. >>STEVE CROCKER: And that the load on the CPU might not be exactly that. >>NAI-WEN HSU: Yeah. I mean, [inaudible] CPU time, yeah. >>STEVE CROCKER: Yeah. And do you have a time schedule? >>NAI-WEN HSU: Depends on the NSEC3 publish or not, because we -- we want to open to end users to try the system. We think this is important. >>STEVE CROCKER: Uh-huh. So fortunately NSEC3 is coming along soon. >>NAI-WEN HSU: Okay. Yeah. >>STEVE CROCKER: Real soon. Doug? I suppose that was to raise a question, and not to say hello. >>DOUG BARTON: Yeah. And Russ is going to get the microphone. I'd get it myself but I'd block the whole screen, so... I thought the presentations were excellent so I don't have any questions for you guys, but I am going to pick on Richard a little bit. Hopefully not really picking on, but a few suggestions. One, which is a -- sort of a hobbyhorse for me is the bit size of the signatures that you're using. >>RICHARD LAMB: Uh-huh. >>DOUG BARTON: I have a theory, which is shared by some and ridiculed by others, that we would be better off using larger bit rates in the initial implementation to guard against the potential of a compromise in the hash down the road. And the reason I say that is that the initial implementation is going to have a lot of bumps. There's no argument there. I mean, I -- >>RICHARD LAMB: Right. >>DOUG BARTON: -- I think that's pretty well accepted. And what I'm looking to do is minimize the number of potential complications that can be added to the initial implementation after it already gets off the ground. >>STEVE CROCKER: Let me ask a clarification of your question. Are you asking for longer key sizes or faster turnovers to cycle the system faster? >> DOUG BARTON: I think the schedule he has to cycle the keys is a good one and I think dot SE's phases has born that out. I am actually asking for longer key sizes. If it were up to me, I would double the ZSK and the KSK. There is a cost to that. There is a bandwidth cost and a zone size cost, which I think the TWNIC presentation actually elucidated quite clearly. But my feeling is that if down the road there is a compromise in SHA1 or whatever we end up using, doubling the key rate or tripling it or whatever we have to do is going to be an additional perturbation of that initial rollout that could quite possibly be the deal breaker and my feeling is that if we're going to need bigger keys at some point down the road, it is better to do it now because that will give us experience in dealing with the problems with firewalls accepting larger DNS packets. There is a myriad of problems that we know and my gut feeling is that there is at least 50% more problems that we don't know and we won't see until we actually start rolling it out on a wider basis. That's my first suggestion. You answered part of my second concern which is the issue of physical security of the tools. I think I understood from your presentation that the key signing stuff is not physically connected to the network until it's needed. >>RICHARD LAMB: Right. >> DOUG BARTON: That's good. I just wanted to make sure that was clear in my mind. >>RICHARD LAMB: The device is also -- the device holding the keys is also disabled until someone shows up with a card. >> DOUG BARTON: That part I understood but thank you for clarifying that. Just to throw it out there -- and I'm sure you've already thought about this -- is backup staff to actually handle that responsibility. The most obvious question would be what happens if everybody is at an ICANN meeting on the day that you're supposed to rollover the keys. [ Laughter ] And so that is just something that I hope you can plan for down the road, that I'm sure you've already thought of. >>RICHARD LAMB: This is stuff that we are actually thinking about right now, so it's important to emphasize that. That's definitely on my list. >> DOUG BARTON: Good. >>RICHARD LAMB: How many people -- and one of the reason for making the script simple is everyone is gone for some reason and the only person available at the colo facility is the maintenance guy, you can't stop, so we'd have to share pin numbers and let him do the signature. But even he would be able to do it in the worst-case scenario. >>STEVE CROCKER: I love that question. It just brought back flashbacks of walking a guard at ARPA over a telephone line 3,000 miles away through a startup sequence to get some equipment restarted 30 years ago. >> DOUG BARTON: I think we have all been there. I should be clear, I am speaking only for myself here. I personally don't see anything inherently less important about the children -- the child zones in ARPA than in ARPA itself. And this is in response to your mention that the HSM isn't going to be used for those. In fact, I think one could make the argument that the more dynamic a zone is, the more important the security related to that zone is going to be. And since ARPA is fairly static, the top-level ARPA is fairly static, one could argue that more protection for the child zones is more important in that area. And then, last, but not least, one question and this is not in any way meant to needle you, but you mentioned that the source for the software is going to be released. Do you have a timeline for that? And then the actual question is, why hasn't it been released yet? >>RICHARD LAMB: I have released pieces of it already, some of the PCSK11 already. I am personally running out of time to. To release something just to put it on the net doesn't usually do a lot of good. There is a little text that I should try to write with it. The only reason I did very, very early development stuff for the HSM interface I did already publish on the DNSsec deployment working group. Very soon because I want the eyes of the community to look at the design, particularly key rollover. >> Doug Barton: That's actually the motivation for my question. God forbid there is a problem in there, the sooner we find it the better off everybody is going to be. Thank you, Richard. >>STEVE CROCKER: Good questions. We have exceeded the time that's been allocated here so I want to do two things. First of all, I want to thank our speakers who traveled great distance to come here and really excellent work and excellent presentations. So really quite helpful. Thank you. [ applause ] The other is that in an ICANN meeting, there is an awful lot of other stuff going on, attention to internationalized domain names and WHOIS and reorganization of governance issues and GNSO rules, et cetera, et cetera. It is relatively expensive to try to pack a meeting like this within that larger agenda and we've been successful at maintaining a series of these kind of meetings. Let me ask you, how helpful this has been -- I guess, I want to ask for two kinds of response one for right here and now and the other to open up and invite you to respond with what you would like to see in the future at successive ICANN meeting. Is this the right place and is this the right way to try to bring DNSsec forward? Just a brief sense of expression as to whether this session has been helpful to you. In the ITF, I think the usual protocol is to hum. (Humming). >>STEVE CROCKER: Any thoughts? Anybody want to say anything? Yeah? >> BRUCE CAMPBELL: My name is Bruce Campbell. My comment is it depends on the audience. The ITF is pretty much a technical forum. Everyone knows that we should do DNSsec, IPv6. This is more a political forum and so it is more getting people, the ones that actually pay everyone's paychecks knowing what to do. That's pretty much it. >>STEVE CROCKER: Good. Well, as I say, we are -- we did fill up all of the time. From my perspective, I thought these were amazingly, contentful, substantive presentations and I think that the collections of presentations that we have here are a very strong baseline for moving forward. So let me again thank you all. Thank you all for coming. And with that, I think we have to bring this -- you want to make a closing? >>RUSS MUNDY: I have just one final comment, especially in view of Doug Barton's question about people and availability. Now we know the real reason why the ICANN meeting was held in Los Angeles so Richard wouldn't be far away from the experiment. [ Laughter ] >>RICHARD LAMB: Just down the street. >>RUSS MUNDY: Again, everyone, thank you. Thank you to the presenters and the attendees. We certainly hope this was informative. Any feedback you have for us, we certainly would love to have it either directly to our e-mail addresses or to the DNSsec deployment group and the Web site. Thank you, everybody. [ applause ]