DNSSEC Workshop Wednesday, 28 October 2009 ICANN Meeting Seoul, Korea >>STEVE CROCKER: Good morning, everybody. We are -- (Audio problem) and on this Wednesday morning, we have an enormously dense and content-full session on the domain name security protocol DNSSEC. We're scheduled to run as long as to 12:30, although our hope is that we keep you not longer than noon. We have an amazing 15 presentations. And I'm glad that I'm not hearing terrible groans. But the intent is to keep the pace up and that you'll walk away with quite a lot of information. And there will still be time, if we've done this right, for a certain amount of interaction. The big picture is that we've now passed the point where people are asking, "What is DNSSEC?" Or "Why do I have to do this?" And "When is it coming?" And we're now in the accelerating phase of activity where more and more country code TLDs and gTLDs are saying that they're either -- either have or are intending to implement DNSSEC. We have a commitment that the root will be signed and the process for rolling that out is under way. And a variety of related technical and process issues are beginning to surface. So this is a very active period which I expect will go on for the next couple of years until we're -- (audio problems). The first talk is going to be focused on the signing of the root zone. Then we'll move into a series of talks on ccTLD progress, with considerable emphasis on the progress in this region, in the Asia- Pacific region, but including others as well. And then into a broader set of topics about extending DNSSEC deployment. So with that, let me turn things over. I believe Matt Larson will be speaking on behalf of both VeriSign and ICANN, with cooperation and interaction with the National Telecommunications Information Agency in the Department of Commerce of the U.S. Matt -- Matt Larson from VeriSign. >>MATT LARSON: Thank you, Steve. Good morning, everybody. This is actually going to be a joint tag-team presentation. Rick Lamb from ICANN -- >>STEVE CROCKER: My apologize. Hi, Rick. >>MATT LARSON: So we're just going to pass the mike back and forth as we advance through the slides. And, actually, Rick is going to start. >>RICHARD LAMB: Okay. All right. Thanks, Matt. I'm the DNSSEC program manager at ICANN. And what can I say, being the first presentation after a gala and a long evening. It may be a little tough. Hopefully, I'll wake people up as opposed to putting them back to sleep. As Matt said, this is a joint effort. And it's been going very well with VeriSign and ICANN, and with requirements set forth from NTIA. So go to the next slide. I'd like to start off first by just reviewing some of the terminology that we're focusing on here. We can go to the next slide. Anybody can sign the root, okay? That's not anything special here. What's important is to have a system that people can trust and is secure and people are faith and that they will use. Some of the key tenets behind our design effort are transparency. We want everything that we're going to do, everything that we are doing will be published, described. Designs will be shown to people. And there will be continual community involvement in the process. Next slide, please. The system will also be audited twice a year. Right now, we're going for the following -- trying to follow some of the industry standards out there. In particular, that says ISO, but there's something called SysTrust, which is a standard audit that the international accounting firms actually provide. And so we're going to have SysTrust audits of the system. That's important to have that third party review this. Next slide, please. The system is considered -- we're going to build the system as a high-security system. It's considered high impact, using some of the terminology that we've borrowed from the industry and NIST documents. I.e., this is a system that people rely on, that if it fails, there's a loss of mission there, and there's financial harm. And so we are following some of the standards outlined in NIST to develop a system like that with all the bells and whistles. And we will go into that later. >>MATT LARSON: Thank you. So let's talk about the roles and responsibilities in this proposed design. Next slide, please. So ICANN, as the IANA functions operator, its main -- two new responsibilities for DNSSEC are below. The first is, ICANN is going to manage the key-signing key. And then the other big thing that ICANN needs to do is accept DS records from TLD operators. And then, as usual, it will verify and process the request. And then send the update request to DoC for authorization and to VeriSign for implementation. Next slide, please. And then DoC's role, it currently authorizes changes to the root zone. And DNSSEC will be no exception. We're just going to add two new pieces of information that DoC will authorize, the DS records from the TLDs as well as the key-signing changes. When the key changes, DoC will authorize that. And these update requests follow the same process as all other changes. So there's not any -- anything new in that regard introduced to the process. It's simply additional data that DoC is authorizing. Next slide, please. And then VeriSign, in its role as root zone maintainer will manage the zone-signing key. And as VeriSign currently does, we'll incorporate the changes to the root zone that NTIA authorizes, and then the other new thing we'll do is to sign the root zone with the ZSK, and as we currently do, we'll distribute the signed zone to the root server operators. On to the next slide. Here's a graphical depiction of what I just said. You can see the TLD operator on the far left sending changes to ICANN. DoC is there in the middle. And then, finally, VeriSign is represented in the roles that we perform there on the right. And, ultimately, the root zone is distributed to the root servers. You'll also notice on the bottom, we have two new boxes underneath ICANN on the left, a box representing KSK management and a box representing ZSK management on the right underneath VeriSign. And these two roles require interaction. And we'll talk a little bit more about this later on in the presentation. But, as VeriSign creates new zone-signing keys, those need to be sent to ICANN for signing with the KSK, and then the results need to be sent back to VeriSign. So ICANN and VeriSign have developed a process as well as data format to handle that exchange. (Audio distortion. Inaudible.) >>RICHARD LAMB: -- talk about that later in the presentation. Next slide, please. Thank you. One of the tenets here is that we have designed a system where there are multiple tiers of access, including safes, various facility controls as well, and data centers. And there are seven tiers that we have. No one individual can access all tiers together. This requires that multiple people are involved in any action regarding the KSK, whether that's generation of the key or use of the key. We'll have two sites so that there's a backup and flip-flop between the two. And I also would like to point out at this point, a lot of this physical security, things dealing with keys and cryptography, we would not have made as much progress as we have to this point without some of VeriSign's help. They've been very forthcoming in opening up some of their experts and engineers to help us design this. Next slide, please. Part of the transparency aspect here we're borrowing from the secure or the SSL certificate business. They have a whole procedure and process which involves something called the certificate practices statement. This basically says, here's how we -- here's how we perform our operations. And this is a document that is public by definition. We've developed something called the DNSSEC policies. Same policy practice statement. We're just calling it the DPS. These are documents that you will see soon in the public. And, basically, they explain how the system works, who's involved. And, basically, that. It's similar, like I said, to some of the X.509 work that's out there as well, but still, unique to DNSSEC. And some of those are actually based on some IETF drafts that are coming out. Next slide, please. This is an overall view of the whole key management system, with the various parties involved and some of the processes that are involved. You'll notice that under the key-signing key side there, we actually have external trusted persons as well as part of the whole key system. This is a very important aspect, and I'll get to it a little later. But it does involve people from the community. And that, I think, adds to the value and the usability and trust in the system. Next slide, please. Okay. Community trust. Like I said, anybody can send out -- sign a root and offer it up. But it's not useful unless people want to use it and unless people trust it. I think we've developed a really nice system here where, at least at this point, we are thinking about -- nothing here is cast in stone. This is still -- we're still seeking, you know, input from the community and engineers, technical community. But we're thinking of a system where we have community representatives drawn from possibly -- that's really fine print on the bottom, it wasn't necessarily intentional -- but one example would be members from an entity such as the ccNSO, the GNSO, IAB, the RIRs, and ISOC, for example. These would be people that would have cards, not pieces of the key, but activation cards to use the cryptography parlance, that would have to be present in order for us to use the KSK to either sign or during generation. At this point, none of those crypto officers would be ICANN employees, VeriSign employees, or U.S. government employees. The idea here is that the community would be involved in this in a real tangible way. Just a side note, right now we're look at a three of seven, if you're familiar with "N" of "N" schemes, it just means that we would need three out of seven people to perform this act, for obvious reasons, you know, if someone would get sick, someone's not able to make the signing ceremony. We also do the same sort of thing with a complete backup of keys. Even though we have these wonderful pieces of cryptography hardware out there, there is always the possibility that -- you know, this is belt and suspenders here -- if all the hardware fails, we still need some way to recover. Next slide, please. Okay. Finally, auditing and transparency. We are going to be using a third-party auditor. We're still searching for that. And this will be based on some of the -- if you're familiar with the same sort of audits that are used for SSL certification authorities, but similar to that, you know, not quite WebTrust, but people with that sort of expertise we're going to try to leverage as much as possible, and the existing expertise out there in the CA field, certificate authority field. Other external witnesses may also be present, just for their -- you know, just -- the idea here is to keep this as open as possible. The whole process will be filmed, and people will be able to view the film as well as be witnesses in the ceremony. That's it. Matt. >>MATT LARSON: Okay. Now let's talk about some of the proposed DNSSEC protocol parameters that we're actually, well, proposing to use in the zone itself. So for the KSK, we're planning on 2048-bit RSA key. The intent is to roll this relatively infrequently. We're thinking on the order of every two to five years, to get as much time as we can out of a 2K key. And we will definitely be using RFC 5011 for automatic rollover. So any validators that have 5011 support will track the KSK and roll it appropriately. We are also proposing to use signatures based on SHA-256. This is not a new cryptographic cache algorithm to the community, but it is new in its use in DNSSEC. This has the advantage, if we use SHA-256 of not using SHA-1, which we know has a limited life span. And if we just start with SHA-256 right out of the gate, we don't have to deal with an algorithm rollover in the near future. Next slide, please. Thank you. And then zone-signing keys will be 1024-bit RSA keys. We intend to roll these once a quarter. And that is really not so much for security purposes as it is for administrative purposes. As we'll see in a moment, the way the key exchange will work at any given time, VeriSign will have one quarter's worth of signatures to use to create the root zone. And by rolling the ZSK once a quarter, it gives us a convenient way to do that. It's not -- Back, please. Thank you. It's not necessary, but it's the way we're going to handle that particular parameter. We are going to sign the root zone with NSEC. There's no need for the security provided by NSEC3 or the opt-out functionality also provided by NSEC3. So just plain old vanilla DNSSEC with NSEC. We're also going to use SHA-256 signatures for the entire zone as well. So both the key set signed with the key-signing key will be SHA-256, and then the entire rest of the zone signed with the zone- signing key will also be RSA SHA-256. In terms of signature validity period, we're going to have two different periods. The DNSkey-covering RRSIG, this is the RRSIG made with the key-signing key, it will have a validity period of 15 days, but we'll have a new one every ten days. So if you image the start of a quarter, on day one, we'll have a signature that will be valid from day one through day 15. But on day ten, we'll put a new one in. So, in other words, this is going to work out that there will be nine signatures per quarter, each one ten days long, and the last one larger, if necessary. And then all of the rest of the RRSIGs, those made with the zone- signing key, will have a validity period of seven days. And we are going to resign the root zone twice per day. We currently generate the root zone twice per day on schedule. And we're just going to resign the entire zone at that time at each new zone generation. So there should never be at any point an RRSIG in the root zone with really less than a seven-day validity period, because every time the root zone is published, there are new signatures that will last for seven days. >>RICHARD LAMB: Thank you. So there will be what's called in the industry key ceremonies every time we generate a new KSK as well as every time we use it. Currently, we'll have a key ceremony that will involve all of the various participants from possibly those entities I pointed out earlier. And a new key will be generated two to five years. And the reason that's variable, it's -- we really are looking at -- rolling a key is still something that does disrupt the system. And so we want to do it when we think it's necessary. So initially, we will be doing a number of key rolls just to test the system out. But in the long run, it's approximately two to five years. And the five-year comes out of anything, but sometimes the battery life for a lot of the equipment is about five years. But maybe that's more than you wanted to know. But that's where the five years comes from. Let's see. Processing -- there was a picture, part of the picture was the exchange of keys, the ZSK, between VeriSign and ICANN. And that is just the public half of the key. There's no private key material passing back and forth here. So there's no safety -- real security concern. There is -- there are some concerns about authenticity and the source of the key. Someone -- we certainly would not want to sign with the root key a rogue ZSK from someone who could then take it over. So we've spent a fair amount of time developing this key-signing -- ZSK key-signing request process between our two organizations. And it is protected both by SSL as well as a hash, as well as having out-of-band checks. We're being very, very careful with this. So I feel confident this is something we can completely trust. Okay. And then the root trust anchor, the next slide, please. The other part of ICANN's mission is -- job is to publish the KSK. And we're going to do this a couple ways. We'll do it in an XML- wrapped format to make it easy for automated systems to pull this off and parse it. We're also going to borrow some of the -- some of the existing familiarity with the PKI systems out there and use something called a certificate signing request. This will allow us to proof of possession of the private key, basically, we'll sign the contents of this CSR with the private key in there for proof of possession of it. The side effect of this that is somewhat interesting that people can then sign this certificate signing request and create CERTs, certificates, just like you see in SSL. It's something, again, that I think allows us to build on the familiarity and some of the existing tools that are out there for X.509 type of certificates. Multiple parties can sign this CSR, so various people can attest to it any which way they want. I think that will be further -- further add value here in the sense that it brings the community in and people can judge for themselves. Thank you. Matt. >>MATT LARSON: Our final section is to describe how we're going to deploy a signed root. Again, the word "proposed" is on here because we're interested in feedback on this particular scheme, which is somewhat novel, we think. And the novel part is that we want to incrementally roll out the signed root. So rather than deploy it all at once, we want to stage the rollout. And the reason for this is that we're somewhat concerned about the impact of the larger responses from a signed zone. Because, as many of you may be aware, many DNS resolvers today are setting the DNS okay or the DO bit. And that percentage is quite high, depending on, you know, when you look at the traffic and which root server you look at. But what this means is that were we to sign the root zone and deploy it all at once, there would immediately be a significant amount of large responses going to all of these resolvers that are potentially not able to handle those larger responses. And an incremental rollout will allow us to gauge the impact of these large responses without, hopefully, causing damage. So the plan is to roll out to groups of root server letters at a time. So to put a signed root on, say, one root server first, then on another root server second, and then perhaps two root servers in the third group, and so on. And every time we do this, we would watch the query profile to all of the root servers as this rollout progresses. The idea here would be to look for changes in traffic that might indicate there were problems. So, for example, if we put the root zone -- the signed root zone on the first server and we see a significant drop in traffic to that server and a corresponding increase in traffic to all of the root servers serving the unsigned zone, then that would indicate some sort of a problem, in that what you'd infer from that is that the larger responses were not being reached, or, rather, were not -- were not going all the way back to the resolvers that queried them, and that traffic, therefore, shifted to other servers that the resolvers could get an answer from. So the very important point here is that we're going to listen to community feedback as well. So there's -- one component of this is the root server operators doing their own monitoring. And another component is to listen to the community to report any problems. Next slide, please. And the other important aspect of this plan is that it will not be possible to perform validation with the signed root at this point. So during this incremental rollout period when some of the root servers serve a signed zone and some serve an unsigned zone, during this period, the real keys in the zone, both the KSK and ZSK, will be replaced by dummy keys. These will actually have the same DNSSEC key ID, but they simply can't be used for validation, because they're -- they are not the keys that were used to generate the signatures. And the advantage of this is that it makes it impossible for someone to shoot themselves in the foot by taking the key-signing key in the signed root, configuring it as a trust anchor, and attempting resolution. For one thing, that wouldn't work, because not all the root servers will be serving the signed root. So that wouldn't work at all. And we want to prevent somebody from getting themselves in that situation. Okay. So, then, finally we have the time line itself. On December 1st, the good news is, the root zone will be signed. However, this signed zone is going to initially stay internal to ICANN and VeriSign. Also, starting December 1st, ICANN and VeriSign are going to begin this KSR that is the key-signing request processing. VeriSign and ICANN will be exchanging these KSRs and performing both ZSK and KSK roles. And we're going to be doing it on the time scales that we'll eventually be doing it, that is, on these quarter-long boundaries. And this will allow us to completely exercise the system, make sure that we know how a ZSK roll and a KSK roll is going to work. So that will happen from December 1st through July of 2010. And then also during that same interval will be the incremental rollout that I mentioned earlier. So there's two things going on during this period from December 1st to July 1st, 2010, the interaction between ICANN and VeriSign, and then the incremental rollout. And the very last KSK roll that we do before -- this would be in mid-Q2, that will actually -- that'll be a roll to the actual real KSK that will have been generated at a real key ceremony. So on July 1st, we'll actually roll the KSK to the real KSK. ICANN can publish the trust anchor. And at that point, the signed root is fully deployed. We're very interested in your feedback here in the room. Steve, is it the intent that we can have questions and discussion? >>STEVE CROCKER: Yes, indeed. And I'm also tied into the Jabber room and we're try to channel questions from there. Any questions from this audience? >>MATT LARSON: Could I just ask for the last slide? We want to definitely give credit where credit is due. This is the list of ICANN and VeriSign employees and contractors who have developed the design that you have just seen. So, you know, if you like it, you can thank Rick and me. And if you don't like it, these are the list of people that you can go -- go contact. [ Laughter ] >>STEVE CROCKER: Let me start things off by saying thank you very much. And it's quite evident that there's an enormous amount of work that's gone into this. And I think there's going to be a -- this is a momentous period. This is a very important moment in the life of the Internet and the domain name system. I saw Jim's hand up. Any -- I just want to look around and see how many questions we're going to get. All right. Jim. >>JIM GALVIN: Thank you Matt, and Rick. Let me just echo Steve's comments. Obviously, this is an excellent piece of work, and a lot of expert people has gone into this. One thing I observe, it all seems to focus on sort of ordinary circumstances, if you will, the normal operational set of circumstances. Have you had any discussions yet or do you have any plans for dealing with exceptional circumstances? And there are two that come to my mind. I mean, there's always the possibility that there will be issues with the root, KSK, and ZSK, and you'll need to do things out of schedule, as compared to what's up here. And then, of course, there's the content of the zone itself is driven by circumstances. For example, a TLD itself may want to have a new key distribution. And so it may desire to have a ZSK at a signed zone coming out sooner than the frequency driven by your publication schedule. So I'm interested in exceptional circumstances and what your plans are or what discussions you've had about that. >>MATT LARSON: Okay. I'll take it first and Rick can chime in as he likes. You know, we definitely have talked about how we would handle KSK and ZSK compromise of the root, KSK, and ZSK. And how that interaction would work. So, you know, while that's not presented here in the slides, in the overview, it's definitely something we've discussed. I should say that this whole design is based on a requirements document that was developed by the Department of Commerce. And many of you may have seen that. It was, you know, widely sent around for feedback from, you know, various technical experts. And I also know that DoC intends to publish that requirements document very soon, perhaps -- Well, I don't want to give a time, since I'm not the one publishing. But, you know, very soon, that requirements document that this design addresses is going to be made public. Regarding emergency roles from TLDs, which I think was the second part of your question, you know, there are time requirements in that requirements document that we definitely have built into this design. So, you know, definitely we realize that there may be situations when a TLD will need to roll its key quickly. And the intent is to be very responsive and to allow that to happen. >>RICHARD LAMB: And if I may add, the DPS that will also get published soon goes into more detail as to what some of the disaster recovery issues are and how we actually handle these things. And that will be specific -- spelled out in that document. >>STEVE CROCKER: Let me ask a question of my own here. The schedule that you have, you focused on the incremental rollout in order to test the large sizes. And -- but it wasn't 100% clear to me when you intend to reach the end of that process. And is there a gap between that point in time and the full signing of the root? And if there is a gap, then what do you plan to use that time for? And overloading my prerogative here, the next thing that is on my mind about this process is the testing of the rollover process with the clients, that is, do the clients get to participate in a 5011 rollover process at high speed so that they can shake down their end of that process before we go into full operation? >>MATT LARSON: Okay. Let's see. So the first -- I'm sorry. I've already forgotten your first question. >>STEVE CROCKER: So, in order, what's the end of the deployment of the incremental deployment process? >>MATT LARSON: Yes, we definitely intend for there to be a period where. We're calling this the DURZ, the deliberately unvalidatable root zone. So we definitely intend for there to be a period during which all the root servers are serving the unvalidatable root zone. And that is potentially where, if there are going to be problems, we're definitely -- we would see them, because at that point, there's nowhere to hide. There's no root server serving an unsigned zone that a client that cannot handle large responses would be able to go to. So we want there to be a period, you know, of a number of weeks. You know, we're still deciding on the final schedules for this. You know, you're basically seeing an early version of this proposal so that we can socialize it and get feedback ton. But that's our intent, that there be a longish period measured in weeks rather than days, during which we're in this unvalidatable date. And then with regard to 5011, we at this point do not plan on doing 5011 testing with the production root zone itself. You know, we will, of course, support 5011 for rolls of the KSK when they happen. But we're worried about the disruption that would be caused were we to actually roll the KSK in the production root in an early period, especially since RFC 5011 support at this time, as our understanding of it, is not widely deployed. So we would be exercising a protocol that, you know, there aren't a lot of people at this point listening to. >>STEVE CROCKER: You make a very good point about the deployment of the -- there may not be a lot of support for 5011 at this point. But just speaking for myself, I'm concerned about making sure that that process does work when it needs to work. And so I don't know how to bridge that gap. I'll just leave that hanging there. And if this is part of the socializing the plan and looking for feedback, this is -- let me raise a flag on that. One other thing that I meant to include in that compound question: Where in this process do you plan to put DS records in? Will it only be when they're signed and fully included? Or might they be included beforehand? >>MATT LARSON: Yeah, at the very end of the process. >>STEVE CROCKER: So no unsigned DS records, then? And when the root is fully signed and operational, then you'll begin to fold in the DS records? >>MATT LARSON: Correct. There will be -- Do you want to talk about the ITAR and -- I don't want to -- >>RICHARD LAMB: No. You go ahead. >>MATT LARSON: Okay. So the intent is to not do a wholesale import of keys from ICANN's interim trust anchor repository. A TLD will have to very specifically send a request through the current TLD root zone change process to indicate positively that they want their DS record published. >>STEVE CROCKER: So that's -- that's interesting. And I hadn't thought about that aspect. But that -- that's genuinely interesting. But the other side of it, where I was focused, is, you're doing a very careful, incremental rollout across A through J -- or A through M -- sorry, I can't count -- to test the sizes of responses and so forth. But do you anticipate that there's any issue about the introduction of DS records as causing a qualitative change different from what you've already will have tested by that point with just the signing of the root itself? >>MATT LARSON: I think the short answer is no. What we're most concerned about are the large responses, which we get plenty of testing of, even without DS records. Because in a signed zone, an insecure referral is roughly the same, larger size, as a secure referral. So if one looks at this with an intent to focus on the size aspect, which is our main -- main point that we're exercising, then the DS record testing is -- you know, doesn't provide any incremental value. >>STEVE CROCKER: Certainly not -- I'm in agreement on the size question. It's always a question of whether the difference in the content might cause a response. And I don't have a strong opinion. I just wanted to highlight that. Thank you very much. Any other questions? I see Bill Manning, and any other questions from the audience? >>BILL MANNING: We have one more up here. You first. >>CHRIS WRIGHT: I was under the understanding that the early signing record was actually the DNS record. >>MATT LARSON: That's correct. But in an insecure referral there is an NSEC record that is signed. >>CHRIS WRIGHT: So you are only testing for negative responses. We are actually not testing that people can handle proper referral -- so referrals might be signed. The referral response won't be any bigger. It will be the same size it is now. >>MATT LARSON: No, that's correct. A referral includes an NSEC record. >>CHRIS WRIGHT: A referral includes an NSEC record. >>MATT LARSON: It does. Which is signed. >>CHRIS WRIGHT: Okay. Well, I'll look into that one. >>BILL MANNING: So Bill Manning. I have sort of three questions. In this window of testing, is there going to be a plan to test unsigning the root? Or will we wait until the disaster happens and then clean up the mess afterwards? That's the first one. The second is, will the IANA test bed continue to operate past June or July of next year? And the third has to do with the DS records. How do you pull -- How would a -- How would an entity with a DS record in the ITAR get it out of the ITAR once they make the formal request to put it into the root? >>RICHARD LAMB: Currently we don't have any plans for unsigning the root. The idea here is, correct me if I am wrong, is to see if there is any difficulty. And by having this invalid key in place, it is to make sure that people do not embrace or start using this -- the root in this test period. And so that was deemed to be a reasonable tradeoff here. >>MATT LARSON: Can I add? I just want to add one thing. We do, though, want to see what implementations of RFC 5011 do in a situation where the only KSK is revoked and there's not one to replace it. So we do want to test that in a lab environment to see what RFC 5011 implementations do. And that is a requirement in the requirements document created by DoC, is that they want to know if it is possible to unsign the root. And the most elegant way we have to do that would be with 5011. So in a lab environment, we definitely want to test and understand what current implementations are able to do, if they are able to remove the last and final trust anchor. >>RICHARD LAMB: Definitely. I was talking about the production version but yes, it is part of the requirements we have to do the 5011 testing. As far as the IANA test bed goes, it will probably keep running for a little while afterwards until it withers away, as soon as the interest goes away on it. Right now we get not many but three or four million queries a day on it. So for those people who are still happy to test with it, we are certainly going to do that. As far as removing trust anchors from the ITAR, I'm open to your suggestions. I mean, we certainly have -- we have a wonderful interface that has been written for the ITAR, and I think, you know, it would be trivial for us to put something in there if you wanted to actually remove a key from that. Support from that may actually already be in the ITAR. So hopefully that answers your questions. >>STEVE CROCKER: Mark. >>MARK KOSTERS: Mark Kosters, ARIN. One of the questions that came up as I was thinking about this, is during the test period, what sort of thing would the root server operators be testing for and what would be a acceptable failure rate before they were to go live with DNSSEC? >>MATT LARSON: Well, that's one of the things that we're still developing. I think one of the things for sure is just query load. That's sort of the easiest, largest measure. There are more subtle things that we have thought of looking at. For example, the number of requests with an EDNS buffer size of 512, since we know that Bind falls back to 512 if it's not able to have its initial query with a larger buffer size responded to. So it's possible that an increase in buff size of 512 queries all over among all the root servers could indicate something is amiss. But I will say that this is one of the things that is still under development, which is exactly how are we going to instrument the root servers and exactly what are we going to look at. And even a harder thing to develop is what are the thresholds to decide success or failure. And those are critically important things that are going to be vital to the success of the incremental rollout; namely, to be able to judge success or failure, and that's something we are still developing. >>STEVE CROCKER: Another question from the jabber room. What's the publication process for the public part of the KSK? >>RICHARD LAMB: We're going to have it published a number of different ways. First of all, we will have it in this XML wrapper so that it will be easy for automated systems to actually pull the public key out of that. The XML format of this public key will also be digitally signed to make sure that the user can validate the KSK. It will also be in the form of a certificate signing request, which is a PKI-ish -- something we borrowed from the PKI-ish world which is not quite a certificate but which demonstrates proof of ownership of the private half of the key. And there will also be certificates. One will be signed by ICANN, there may be others signed by, say, some of the external witnesses that would be part of the key ceremony so that they could also attest to our process and procedures and that we did the right thing. These will be on a Web page. That's only one form of publication. I am certain we will use other forms of publications, such as in newspaper or print media. But right now, from the security point of view, we're focusing on making the Web component of this as verifiable by as many different parties as possible. One of the signatures will be, of course, a PGP signature as well. >>STEVE CROCKER: Are you going to test that process ahead of time or only after the root is signed? >>RICHARD LAMB: That's actually very good feedback. Personally, I would like to start checking that -- testing that ahead of time. But what -- There is nothing we could check -- Since we won't have a valid key in the system at that point, not until July 1, it's not clear what could be tested. But nonetheless, I could see some value in at least exposing people to the Web site and having them look at the various mechanisms by which we're publishing it, in the XML, the digital signatures, whether they be SMI, PGP or what have you. So I do see some value to that, but I appreciate that feedback. That actually would be useful to do that ahead of time. >>MATT LARSON: One thing that does occur to me, though, and this has just occurred to me as Rick was answering is, the danger of testing something like that ahead of time is you get someone who earnestly wants to use it and then puts themselves in a situation where they have configured themselves into a corner and things don't validate anymore because they have configured root trust anchor and the root isn't signed with that key. So were we to do this, we would have to figure out a way to do it very carefully. >>STEVE CROCKER: Thank you very much. This is, as I said, a very important step forward, and I appreciate the complete discussion that we have had here. We are pressed for time so I am going to move on, but thank you very much. We now move on to a roundup of the progress in ccTLDs, and starting with our host, South Korea. Aha. Thank you very much. And I apologize for not closing the loop ahead of time. Please introduce yourselves. >>YOUNG-SUN LA: I am Young-Sun La. I work for KRNIC, and I am in charge of KR DS monitoring and DNSSEC. Today I am going to tell you DNSSEC state tests and plan in Korea. I am going to deliver DNSSEC state test with three part. First of all, trial with safedns.kr. What have been done with trial domain safedns.kr since 2006. And before deploy DNSSEC commercially, we needed to determine the policy. So the output from the research in 2008 came after. And the test. There are many tools that help us to deploy DNSSEC easily. And we are using them to make us familiar with DNSSEC, the hard stuff like rollover and key management, things like that. And then we tasked the NSD to look at how different it is, the performance aspect of the signing. So the plans. We are going to sign the go.kr in 2010, and we are going to sign the whole zones of KR in 2011 or later. And we chose go.kr because it's zones used by governments. So as an agency, we are thinking that we can work closely with the governments. That's why we chose the go.kr first. By the way, as you know there are many things we have to look at. Software developing, and new DNS deployment, and hardware upgrades, and traffic controls. So I think it won't be done in a short time. More details with the trial. In 2006, we chose safedns.kr for trial. And we implemented a trial system to verify technically how it works. And in 2007, we started trial service to the public, the part of the public, because the person want to participate in this trial service, they have to give permission from us. But at the time the request for comments of 5155 dealing with NSEC3 was not completed at the time, so it was done with NSEC. In 2008, the NSEC3 was completed, and the Bind, a new Bind was released supporting the NSEC3. And we made a key and signature policy ourselves. So those things was reflected in 2009. So we reformed the trial service to work -- to make it work with NSEC3. So it's worked well with NSEC3. And besides, we registered the key for safedns.kr and (inaudible) registry for the DLV service. This captures a picture showing the DLV configurations have been made properly. By the way, sometimes we have to adjust EDNS UDP size. And that -- 1460 was given from ISC staff. And I don't know exactly how it works, because the firewall sometimes blocks and a fragmentation. So it's hard. It's difficult. Actually, that's one thing I want to ask someone else here, some expert can give me help for that. Okay. The next one. And as I said, we researched about key and signature policy in 2008 to seek the proper value for key and signatures parameters. So basically, we are trying to follow the RFC. So most of them same as the RFC recommend. So to speak briefly, two key signing key double signatures and three zone signing key prepublished and lifetime for. One year for key signing key and one month for zone signing key, and one or 24 bit for zone signing key and double size for key signing key, something like that. And we choose the NSEC3 to prevent the zone working problems, and opt-out to reduce the roles as much as possible. When I was giving a presentation in other meeting in May, one of the audience asked me why NSEC3. So I said because there is a zone working problem. Of course, there are some countries who don't care about zone working issues, but some countries may be concerned about it. It depends on the policies the countries choose, because when you see the situation of Korea, we have no (inaudible), and this particular situation can make us a little bit closed for the protect information. And other things can affect it. For example, the commercial use. We don't want to use the whole domain zones used by someone. Similar about tests. Key management and rollovers, it's tough. Yes, it is. But there are many useful tools. Many experts from the world are giving us help. So I would like to give -- I would like to give thanks to all those developers. I appreciate. So I am using that tools on a Linux and Solaris as well. And we tested DNS software to look at the relations between signing and the resource conceptions. We are going to -- We are planning to do test more with the various software that today I have only with NSD. So the first one, upper left side, vertical is the QPS and horizontal is number of domains, so one million, two million, and three million, respectively. So you can see even the number of domain has increased. The QPS is not impacted with the match with nonsigned zone. On the other hand, the right one with the signed, and you see 3 million domain zones the Q passes, the clients, dramatically. And lower left one shows you CPU possessions. So you can identify that with -- from 2 million domain zones, we signed the zones, the CPUs are struggling, it's almost 100 percent. And the last, the lower right side, there is showing you memory uses. And as the number of domain is going up, memory usage goes up. So, for example, 3 million domain zone after signing looks -- size of the file is 1.9 gigabytes. Before signing it was 109 megabytes. So 20 times bigger after signing, you can see that. Here about more plans -- more about our plans. And I'm not going to go through the whole thing because there is time limit. But one thing I can say definitely is that there's many things we take care of. Zone signing and key managements and deployed in DNSSEC-enabled caching servers and EPP-DV alternation. And one of the most important things is that operating system support for the validating on a user client, end-point user. To make the DNS go (inaudible), there are many things we pay more attention. Education and campaigns. And cooperation with ISP and registrars. And continuous test. And effect analysis at the signings. I think these are the common concerns that other countries have. So if there is someone who can solve this at one time, I call him hero. But I don't worry about that even there is no hero now, because there is a saying in Korean: The drops of water can wear away the stone. So let's keep communicating and let's keep collaborating. Thanks. That's all. >>STEVE CROCKER: Thank you very much. There's a tremendous amount of information there. And I think we want to definitely stay in communication and follow up. Are there any questions? Let me see the jabber room. No. Thank you very much. Appreciate it. Let me move on now to Hiro Hotta from Japan. >>HIRO HOTTA: Hi, yes. Good morning. Let me briefly introduce the high-level overview regarding how JPRS is prepared for DNSSEC on the dot JP. Today, I will talk about service development and deployment plan from the mainly nontechnical point, although we have done technical research for several years. JPRS issued an announcement in September about -- September this year about a schedule of DNSSEC implementation under dot JP. It said we would launch DNS service by the end of next year, 2010. Since operators of authoritative DNS servers, operators of cache DNS servers, such as ISPs and companies, domain name registrars and Internet users, are all language in DNSSEC usage. Cooperation among these various players are necessary. Next, please. Yes. The main players are illustrated here, although I don't go into details. Through our outreaching activity so far, we found that more attention to wider range of players is necessary than we had expected. Next slide, please. We divided our DNSSEC project into three teams to cope with this. The first is technical verification team. In technical verification, two steps were designed in order for us to gradually involve parties such as registry, which is ourselves, and secondary authoritative DNS operators, which are our partners, and registrars, DNS providers, such as ISPs and companies, DNS cache operators, such as ISPs and companies as well, and system integrators, and hardware and software vendors, such as router vendors. The second team is for education and persuasion. Since various players, including users, must be well educated and sometimes persuaded for them to be involved in DNSSEC, education and persuasion targeted to each category of players are essential. The third team is system development team. The registry system needs software development and system enhancement. In addition, registrars and DNS providers have to develop or enhance their system, their own systems, to accommodate registrants' needs for DNSSEC key generation and DNS resource record registration. Page 5. One of the points that needs substantial discussion is our cost recovery for implementation and operation of DNSSEC, especially it must be decided whether it should be a charged service or charge- free service for registrants. Some registrars say that it's easier to explain to their customers why they charge the registrars if the registry charges to the registrars. To make DNSSEC security a commodity, in a sense, charge- free for registrants and Internet users had better be persuaded -- or pursued, of course. There's another aspect in considering the cost recovery; that is, those players other than registry usually use the DNS registry system not just for a single TLD -- for example, JP -- but for all the TLD domain names. More consideration and arrangement of cost sharing are needed for customers to be motivated and for operators to be motivated. We are trying to have this discussion happen by making a so-called DNSSEC forum in Japan. To become DNSSEC ready, registry must implement DNSSEC enabled registry system and operate authoritative DNS Sophie. In addition, registry should help registrars and ISP providers to handle DNSSEC by giving information in their language and technical support, including software kits. Here, "in their language" means using their everyday words in their native language; in this case, Japanese. There are no good manuals or documents in Japanese for DNSSEC at the moment. And last but not least, a registries should solicit influential users, such as banks, to stimulate the registrants and users through cooperation with registrars. As said on the previous page, these activities are not just for a single TLD, but for all the TLDs. Page 7, please. Yes. JPRS is now doing the whole thing. We conduct the technical verification of DNS in cooperation with various players. That test is planned to allow us almost one year. This means until August of next year. So we begin enhancement of our registry system. We will co-test the service with various players, including registrars, in the final stages of development. We are conducting education with registrars, ISPs, users, and we are in the process of creation of an organization for DNSSEC promotion by working mainly with DNS operators, like ISPs, at first. Considering ever since the information sharing among various registries, registrars, are required. Okay, thanks. Thank you. >>STEVE CROCKER: Thanks very much. Any questions? Let me check the -- I don't see any questions from the jabber room. Thank you very much. It looks like you guys are doing a very thorough and careful job and providing great leadership. Thank you. Is Han Chuan Lee -- >>HAN CHUAN LEE: Yes. Hi. >>STEVE CROCKER: Sorry. Thank you. From Singapore. Please go ahead. >>HAN CHUAN LEE: Good morning, everybody. I'm Han Chuan Lee from SGNIC, the technical manager for the dot SG registry and Singapore. So this is an update from the last one that I gave during the DNSSEC workshop in the Sydney meeting earlier this year. So I will give some progress on what we have done since then. All right. Three key, the formation of the working group, the test bed, and the training activities. For the working group, -- yeah, I think -- yeah. Okay. Next slide. This -- okay. We have discussed this with our parent company, the Infocomm Development Authority of Singapore. There is a task force that is looking into the development and promotion of the Internet and telecommunication in Singapore. And we have met on the issue of DNSSEC. And we have agreed that a joint working group be formed to look into the deployment of DNSSEC in Singapore. And we did within IDA identified first divisions, and have invited them to join the working group. And invited based on the roles they perform within the organization and to make sure that we have good representation from the various stakeholders, especially within the government, so that -- as well as to get a certain level of commitment from them to make sure that we have a successful deployment of DNSSEC in Singapore. So for the working group, we have identified five major groups or divisions. So these are the five. Give a description of what each group does in the working group. Okay. Dot SG is the registry for domain names. We will be chairing the working group. Being a registry, so we will be providing the expertise for the DNS policies, the operations and experience- sharing. The -- with the other members of the working group. And as far as international regional (inaudible), such as the ICANN and regional APTLD meetings. So we will be at the meetings and sharing and learning from the various registries. Okay. The other group is the government operations. Now, these people are basically -- look at operation on an organization-wide basis, in particular, the government. Okay. So they will be our liaison, so to speak, to the government operations. Okay. And one of the key functions they do is actually the coordination with the SOE team. That stands for the standard operating environment, which is to standardize the operating environment of the whole government. So since part of the I.T. infrastructure includes domain name as well as DNS, so this is one of the key players that we want to be involved in the DNSSEC discussion. And how you affect them, especially when they talk about DNS operations for the whole government. And this -- mention on the SOE route, so we want to make sure that they are deeply involved to roll out DNSSEC for the government. So these will be the people that will be doing it. Okay. We have a division that looks basically on security. Okay. So these are all the security experts. And we brought them in to look in and give us the expert advice on I.T. security. And these people are also looking after the security master plan for Singapore as a whole. And they also are trying to see how DNSSEC is going to fit into the security master plan, at what point, you know, DNSSEC can come in in the realization of the master plan. And they have a very keen interest on the trial which I will talk about later. So all this is, in a way, falling in very nicely with the master plan. They have a very keen interest in the working group. The other group of people is the domain name and DNS operations. These are different from government operations. These people are -- in a way, you can think of as service provider for the government, specifically, the domain names and DNS. So they are like a central provider. And they are, like, in a way you can think of this as a vendor for the government or operator groups. So these people have been brought in as well. And they manage quite a huge list of domain names and all the operations for the DNS. So they are going to be our coordinator for the end users when we bring into the test bed, so these people will be helping us with that part of the trial. The fifth group comes from the policy. These people look into regulatory policy formulations. And they also give us insight into -- in the aspect of the regulator, what is their position on DNSSEC implementation. And when it comes to legal issues, they also bring us advice on what some of the legal liabilities or even channels that we can use for DNSSEC deployment. So this group of people is also involved in the working group. Okay. Now, for the test bed, the working group has identified three objectives that we're going to shift for the test bed. Namely, experience learning. DNSSEC, and even DNS itself is relatively new for a lot of the stakeholders, especially end users. So we want to make sure that everybody is -- learns from this experience, is able to trial DNSSEC first before committing on a production or commercial launch. Now, this group is also tasked with looking at what are best practices and guidelines for deploying DNSSEC, especially when you look at the standard operating environment. Okay. So these people will be very keen in what is the best way to do DNSSEC under the SOE project. And, of course, the final objective is actually to go for a commercial launch. Okay. The -- to conduct the test bed, this is how -- the guidelines that we have come up with. First of all, there must be no disruptions to normal operations. This is one of the key concerns that the end user group has, is that whatever do you, please do not disrupt my users. And whatever you want to change or whatever -- they are very, very skeptical. They have a very strict SOE that they have to abide to. So any disruptions to things like Web sites or even e-mails, they are very, very worried about it. So this is a key concern. The other thing about the test bed is that the working group will be providing full assistance to all the participants. And we want to have end-to-end kind of test bed. So it won't be simply just signing the zone and no educating on DNS. But we want to show them from end to end what DNSSEC is all about. To address the concern, please don't touch my domain name, please don't touch my -- we will set up a temporary category, DNSSEC.SG, for those who are keen on the trial but don't want to test the existing infrastructure, so we will have to carat to this group of people. And the other objectives or other thing to test out is automation. They want to have a solution that they can implement and they can more or less forget about it, so it might not be the ideal situation. But at least for the key rollover and so on, they would like to automate as much as possible. So we are looking at some of the commercial solutions available out there. We are bringing them in. We are getting them installed and configured, okay. And they will be evaluating at the same time how well this solution works and choose the one that is best. So we have talked with the vendors and we have brought in some of the machines. We can share these results with the community when we have them. In terms of training, we have established a collaboration with APNIC. So the training is confirmed. It will be in January 2010. It will be a three-day hands-on workshop. There will be two three- day hands-on workshops, depending on the interest. Per workshop, we can only take a maximum of 30 participants. So if we have more than 30, we will probably split them into two three-day workshops. It will be on the third week and the fourth week of January. So the registration will be out soon. If you want to come to Singapore to enjoy the food, the culture, and it is also actually very near to Chinese New Year. And I'm sure you all will be able to enjoy the festivities, the celebrations. And of course, the (inaudible) is going on. With that, I'll take any questions from the floor. >>STEVE CROCKER: Thank you very much. Are there any questions? No. And I don't see any in the jabber room, either. Okay. Thank you, again. >>HAN CHUAN LEE: Thank you. >>STEVE CROCKER: Norsuzana Harun? Hi. Hi. From Malaysia. Thank you. >>NORSUZANA HARUN: Good morning, everybody. I'm Suzanna from Dot My, domain registry operator for country code top-level domain name. So the agenda for today's presentation, I would like to update you regarding the current status, what's next, the proposed key management, result of zone signing test, and last, but not least, looking forward in our DNSSEC implementation in Malaysia. Okay. I would like to update you. In Malaysia, we already have the closed test bed for DNSSEC 31st March and it will be closed on 31st October this year. In this particular testing, we only opened two zones, which is dot my and the dot net.my zone. And we joined the IANA test bed 23rd May 2009, this year. This initiative is the first phase of implementation of this project. And it's totally separated from dot my domain name registry system. And only available for invited participants. And then the objective of our test bed is, the first one is to raise awareness on DNSSEC technology in Malaysia. Because at this point, it's very hard to influence the administrator of authoritative or cache (inaudible) in Malaysia in a way to adopt DNSSEC. And the second objective is to anticipate potential deployment issues. Because right now, we are more working into the functionality of DNSSEC in terms of how (inaudible) and something like that. And then the third objective is to form best practice policies, especially with regards to the key management. And then to gather feedback from participants for improvement of our test bed. And then to create and sustain deeper cooperation with operators of authoritative DNS server and also cache DNS server administrator. This is the closed test bed hierarchy for dot my. As you can see, there is -- the cache starts from the IANA DNSSEC test bed root server itself. Next, please. Okay. This is the dig result for our testing domain name, which is B.net.my. As you can see, there is a (inaudible) in that result. Next, please. Okay. For your information, as it is only the closed test bed, until 15 October this year, we have only 24 participants for this test bed. Several of them are from the APTLD members, they are from Korea, Mongolia, China, Singapore, Hong Kong, Sweden, and Austria, joining our test bed. And then with amount only 14 domain name registered for testing. Next, please. Okay. Part of having the DNSSEC closed test bed, we also intend to open this test bed to public. We expect to launch this test bed this December this year, which at this time we are not focusing to the two zone only, but we need to do it for all zones that we have, which right now, we have about eight zones. And for sure, we will continue our participation in IANA DNSSEC test bed. For this second piece of the DNSSEC implementation plan, what we are going to do is, we will review our registry system and also to make an improvement in order to integrate our registry system with DNSSEC. Because at this time, we consider DNSSEC is one of the value-added package for domain names. And then at this time, we will operate for all users in public to test our system. Is not limited to Malaysia only, but it is open to everyone who is interested to join these test beds. Next. This is a very -- right now, this is a very simple architecture for our public trial. In this architecture, we would also automate the retrieval of public key from child, which at this moment, we are writing our own script to write a child public key and store it. And we will use it for the purpose of signing our zone. And we will have our key generated server and also the signer and then parse the zone file to the hidden server and then distribute to the primary and the secondary service. Next. Thanks. As for the proposed key management, for the closed test bed, we use the RSA SHA-1, and we use the key length of KSK with 2048 bits. And then for ASCII is 1024. I'm sorry. Theres a slight typo. That is supposed to be using 1024. And then we use the BIND command also for the signing tool. And for the public trial, we still use the same key algorithm and also the same key size. But this time, we will try to explore ZKT and a few other tools in terms of key generation and signing. Okay? Next. And for the proposed key rollover, for the ZSK, we will use that for the period of three months and for the rollover of four times a year. And KSK for 12 months, one time rollover a year. Next. In our testing actually, in that table, it mentioned that all zones that we have right now, which is, we have .my, .com.my, dot net.my, .org.my, and et cetera. What we did is that we tried to sign our zone, and then we tried to calculate, to measure that if we sign our zone, what is the increased number due to the signing, okay. And according to this testing, we noticed that our plain zone file increased around six times after we signed our zone. Okay? At this -- sorry. Okay. At that testing, we only signed our zone also include six -- five private key from child. So we get a result of six-time increase. Next. Okay. Now, what is our looking forward for these projects? The first thing, we still forecast -- make a further analysis on the size of signed zone file. And then we want to improve our automated process of retrieving child key, because right now, we are using our own script, which we write our crypt to retrieve the child key. And also we want to more explore about the key management in terms of the validity and also the rollover. Also, I'm not quite sure, because I also want to look into zone time to live. Because at this moment, we need to -- we need to know, we need to explore whether there is a change to our TTL setting because of signing of the zone. Okay? And then also to focus on the larger response size, which is more than 512 bytes, and also need to explore about the -- our firewall limitation, whether for this case we need to change our firewall or not before production. Also, we work on the current bandwidth consumption enhancement required, if any. And then impact of signing root zone to .my, which I believe root zone will be signed in this coming 1st July next year. And then the (inaudible) in the DNS hierarchy to all .my child, whether we have to do something, we have to change the firewall or whatever. And number 8 is quite -- I wish I can -- it is quite difficult to do in terms of the awareness and participation of participation of authoritative and cache DNS server administrators. Because write now we are closely working with the Malaysian regulator. But we do not enforce anything yet, because we still are doing training for them in order to elevate their knowledge in terms of DNSSEC configuration. Because we expect and we hope if we do that, that is a way for them to learn and to do the configuration. Okay. Last, but not least, we also plan to put our DNSSEC in production by Q4 next year. With that, thank you. >>STEVE CROCKER: That's fantastic. That's great. Any questions? Thank you. Chris Wright from Australia. >>CHRIS WRIGHT: Thank you. So I'm going to talk about our experiences with DNSSEC where both the parent and child zones reside on the same name server. And I'll talk through some of the issues that that raises. So the structure of .au is a little bit different to most other country codes. There are lots of country codes that do also have two LDs. But we also have third-level registrations as well. So people can't register under .au. People register under two LDs, com.au, net.au, org.au. They're the main areas for registrations. But each of these state-level governments also have their own third-level zones on the gov.au, so they're the initials of the state, gov.au, and they're open for registrations for those local government entities. All three levels of this hierarchy are managed within the .au registry system. Next slide, please. Yeah. So the way that the DNS is actually set up at the moment is that most servers are authoritative for more than one level of that hierarchy. Some of them aren't yet. That's a legacy issue. And most of them serve, for example, the AU zone, the gov.au zone and the state level .gov.au level zone. So all three levels of the hierarchy. The name server records themselves are all in zone and glued at the parent. So I'd say most of the name server records end in AU is, essentially, what we're saying there. All of those zones, there are actual zone cuts between AU, gov.au, and the state levels. There are three independent zone files, all served from the same name servers. Now, why have we done this? Name servers will deliver the most specific response that they can. So if a name server's authoritative for all levels of the hierarchy of a -- for a query that it receives, it will always respond from the most specific level that it can. The zone servers are glued, so the addresses will be included in referrals. So that reduces the amount of queries that we will receive. And the overall goal of all of this is to reduce the overall query load on the system as a whole and to decrease the response time. So, for example, at the moment, when the root refers a query for www.health.vic.gov.au to the .au name servers, because those servers are authoritative for that third-level zone, vic.gov.au, they will return the health referral straightaway. We miss two steps in the process. So how does DNSSEC affect this? Well, it doesn't break it. And DNSSEC doesn't break our ability to do this. But it does potentially reduce the benefit that we get by doing this. So it does mean that we need to plan for a significant increase in number of queries beyond what you normally need to plan for in a DNSSEC deployment. So, normally, you have to account for query size increases, a query count increase for people retrieving the DNSkey record, and any increases or things that come as people switch to TCP or requery because the UDP packets can't get through. But I'll show why you it affects a little bit more than that. So a really quick test system that got set up, that's the structure of it there. Made-up names. Doesn't matter. It's not meant to mean anything. Each of the yellow boxes represents a name server authoritative for those particular zones. So with a non-DNSSEC query for a third-level name, going to the scenario where there are individual name servers authoritative for each zone cut, so no shared name server, if we query for the record there, for example, www.comchild3.com.au, there are four queries required to be served, one to the root, two to .au infrastructure, and one to the registrant. So that's root au com au comchild3 com.au. By combining those together, which is what we've done, having the name servers authoritative for both levels, the same query only results in three queries required to be served: one for the root, one for the .au infrastructure, and one for the registrant. And then if we extend that -- next slide, please -- to a fourth- level one where the .au infrastructure is authoritative for three levels of the hierarchy, we still only require three queries to answer a fourth-level -- sorry, three -- yeah, the recursive server will only need to make three queries or traverse three levels down the tree -- which is not technically correct -- to resolve it. So three queries again, one on the root, one on AU, and one on the restaurant. If it was done with individual name servers authoritative for each level of the zone cut, five queries would be required. So one on the root, three on the .au infrastructure, and one on the registrant. When we add DNSSEC into the list, so no common name servers, so still an individual name server authoritative for each level of the zone cut -- next slide -- the same query for the -- pardon me -- third-level name results in eight queries in total, which is what you would expect in a normal scenario: Two queries to the root, four to AU, one for the referral, one for the DNSkey, one for the com.au referral, one for the com.au DNSkey, and then two for the child or the registrant. The DS records piggyback with the referral responses, as we expect. And the chain of trust between AU, com au, comchild3.com.au (speaking too quickly) is established as the tree's walked by the recursive server. So this is an increase of four queries over the non-signed zones. That's 100% increase. And an increase of two on .au infrastructure or name servers that we're responsible for. Now, when we combine them together, as you can see, the query -- size -- size of the query traces there are starting to get bigger. Next slide. Thank you. What we see now is that it takes nine queries in total for the validating resolver to validate: Three on the root, so it's actually increased the amount of queries that need to go back to the root; four on AU; and two on the registrant. So the DS records piggyback with the referral responses, but there was never any referral from au to com.au, because it wasn't required, because the server answered with the most specific answer that it knew. Now, in order for the resolver to fill that gap, it has to walk the tree again to get the DS records to establish a chain of trust. Now, the root referral there is highlighted in yellow, because that extra root referral there, when it goes to track down the DS record, technically, shouldn't be required. I have some theories on why that's happening. We'll get to that later. So in the worst case, where that extra root referral query is involved, there's nine queries in total. That's an increase of six over a nonsigned zone. So that's a 200% increase, as opposed to a 100% increase when the servers were separate. And an increase of three on the .au infrastructure. So a 300% increase on our infrastructure, as opposed to a 100% increase when the servers are kept separate. And the additional one query is 12 and a half percent above the scenario where servers are kept separate. It's the same number of queries as the no common server scenario on .au infrastructure But overall, it's an increased number of queries for everyone. Now, in the best case, if that caching issue is resolved, it's eight queries in total, which is an increase of five, and three on the .au, as it says up there, this is the same number of queries overall as the no common server scenario. So what it actually says is that the benefit that we got before DNSSEC was being used by combining all of those things together no longer exists. You now get the same number of queries, whether the servers are separate or together. If we go on to the next slide now. However, when we start talking about further down the tree, you'll notice that this packet trace doesn't even fit on this slide and we now need to move on to the next slide. The situation is much worse. Next slide, please. The amount of queries involved in a query for the fourth-level zone where there's a single name server authoritative for the three levels of that hierarchy is 20: Eight on the root, ten on the .au infrastructure, and two on the registrant. Again, the queries highlighted in yellow, I question whether they need to be made. And we'll get to that in a second. So, moving on, please. So the DNSSEC records, again, they piggyback with referrals. But we missed the referral from au to com.au, and we missed the referral to com.au to the third level .com.au. So now we need to walk the tree again multiple times to establish the chain of trust. If the same query was performed to noncommon servers, none of those extra queries would be required, because the DS records would be returned with each step of the hierarchy. So in the worst-case scenario, 20 queries in total, 17 of those -- sorry -- that's an increase of 17 over when the zone is not signed. So that's a 566% increase in the amount of queries. And that's an increase of nine on the .au infrastructure, 900% increase than if we weren't signed. That's a significant number. That's ten queries. So at 100% above, it's double the number of queries required if they were served from individual servers. So a signed zone from individual servers rather than shared servers. And it's four queries above if we have no common -- from just the au perspective. So it's 66% extra queries just for us. In the best case, where the caching problem is resolved, it's 14 queries above, 366.6%, 700%. You can see the number. We're actually no better off, and in some cases, we're worse off, using common servers in a DNSSEC scenario. So why is the cache not being used in lookup? Two theories. Or the other question, why is there a best-case and worst-case scenario? Why are the results inconsistent? The first one is, perhaps BIND won't use data that it hasn't been able to validate yet because that's what it's in the process of doing. That's unlikely, though, because the results are inconsistent. Sometimes those yellow -- queries highlighted in yellow aren't made. Sometimes they are. So more than likely what it is is BIND is trying to speed things up and doing lots of things in parallel. So it's a timing issue as to whether the answers from the previous queries have been received or put into its cache yet. So I think that's really just a temporal one, but we need to do more investigation into that. Why is it actually not that bad, though? Well, the query counts referred to are for the first time a recursive server attempts to resolve the name. Of course, the DS and DNSkeys are eventually going to be cached for lookups. The real impact will depend on the TTL of these records and how many recursive servers there are out there on the Internet. And if anyone knows that answer, that would be great. So what this means is, the real impact of these side effects are very hard to quantify in a testing environment. They look scary in a testing environment, but they might not be. But they might be. We don't know. Initially, they will be in a small amount of DNSSEC validating clients. So, again, that's going to be interesting. So the conclusion is, searching for missing DS record is required to form the chain of trust. So these queries are unavoidable. There's no question about that. If the recursive server didn't get the DS records in the referral, it has to hunt them down some way. Otherwise, it can't establish it. What it's showing, though, is that, at the moment, this can result in queries going all the way back to the root and starting again multiple times, over and over. So when deploying DNSSEC, how you design your DNS infrastructure, how you choose your NS records, your A records, how you choose if you're going to have multiple authoritative servers or put multiple zones together and so forth is very important and can have huge impacts on the volume of queries that you will receive. DNSSEC, you can be worse off having multiple levels of the hierarchy on the same server. And it also shows that recursive server implementations are still relatively young with respect to DNSSEC and they need time to improve. There are efficiencies that can be gained. If BIND changes the way that it does things, perhaps putting those queries into some sort of order and waiting for responses from other things and using those before it starts going off trying to solve all these things at once, the query load that it's placing on the iterative servers can be significantly reduced. And just a note there. The tests were all conducted using BIND 9.7.0 alpha 1. That's it. Sped through that so we can all get to our break. >>STEVE CROCKER: Very, very interesting. Now we're getting to the interesting stuff in this whole deployment process. Questions? Thanks. Dr. Lisse. >>EBERHARD LISSE: Good morning. I'm going to do this from a slightly different angle, from the angle of a small ccTLD. Most of you probably don't know me. I registered dot NA in 1991, and I have a day job. I'm a gynecologist by profession. I also have a night job. I'm an obstetrician. So I do this in my free time, which is getting a little bit more since my first child has gotten out of school. This -- we can go relatively quickly -- I used this when I made a presentation to parliament a month ago. And I wanted to include that we have joined the club. You can see on the 1st of September, we started to sign our zone. Why do we do this? The answer is very simple. Because! I think everybody here agrees, it should be done. Otherwise, the group wouldn't exist. Also, financial institutions, government institutions want it -- this is not the last version of my slide, actually. It doesn't matter. It's not the last version of my presentation, so it's a little different from what I wanted to say, but that's not a problem. It can be done. And the DNS tools are available, and clients seem to ask this, and the main reason is I wanted to do it. I had surgery in February -- in March, and I had to lie at home for four weeks with my foot elevated to let it heal nicely and I got bored fairly quickly from watching the telenovellas that my wife wants to watch, so I started to look for something and I started to read up on DNSSEC. How do we do this? We run Ubuntu. We run the latest server edition. It's 8.4. It's not the latest edition, but it is long-term support. We are next to South Africa where Ubuntu was developed. We have played with different versions. We just like that one, and we think it's stable. We have a system running, a very sophisticated firewall config file, we think. We have had it audited with some other knowledgeable colleagues. We feel it's quite secure. We have a system that checks about once a day whether we are up-to- date and informs if packages updates need to be made. And we have a seriously redundant backup program. At the most, we can lose one registration if our hardware fails. It's not we don't lose a thousand. We can lose at the most one registration. We have about -- We use the CoCCATools because they are of the automated zone generation and because of the ease of install and operation. They are also now commercializing that, calling it Espresso, going to -- marketing it towards gTLDs, and there DNSSEC will come in much earlier. So the registrar side will be included how to register keys and so on. We have a small ccTLD. We have 1,928 names. We have got 155 in the top level and about 1500 in the COM.NA and a few others that are not really relevant. We, at the moment, we do not use NSEC3 yet. We are worried about zone walking, so we will only start with the big dot com/dot NA zone when we can do NSEC3. For the 155 top levels, that is not the problem. There is one single zone signed which is listed dot NA. If you want to query it, you will find it validates. And I forgot that I had to re- it once a month, so I did that yesterday when I figured that one out. We run a provisioning script which ties this all together. We had done this already for a long while, and it unzips CoCCATools zone files, which get generated an hour. We keep them to have a history in case we need to roll back. And then we split it up into two different versions. We take the dot NA zone file, we sign it using the Bind 9 tools. We SCP the zone files, zipped to the primary, which is an ISC. And they pick it up and reload it regularly. When we started to sign it, we did it six months ago, but we didn't put it into the name server because we wanted to see whether they were happy with the outcome. And eventually we moved it into production and it went without many hitches. The second levels, as I said, we don't want to sign them just yet. We copy them in our Bind directory of the same server, which is a hidden primary for the stop zones, and signal Bind to reload and that works. What did we learn from this? Yeah, well, we have to read the manual. These abbreviations for the end user, for a simple gynecologist who is not a big boy like sitting around the table here, are really different. ZSK, KSK, SCP, ZKT, RRSIG. It makes reading the documents for the noncurrent or deeply involved person very difficult. The lesson from this is you want smaller ccTLDs who can implement it with less investment in hardware, software and so on. If you want them to do that, you must sort of make a cookbook that makes it a little bit easier how to actually do this. I happen to be the chair of the ccNSO Technical Working Group, so we do this tech day on Monday so we are pushing this from that angle a little bit. But this is what I noticed from subscribing to DNS op and DNSSEC deployment, and sitting here. This is a level of discourse that is well beyond the casual observer like me. But many of us run small ccTLDs, so that's something that one might want to look at if you want to propagate usage. If you want to get more ccTLDs. And I saw today TM signed, and someone said, "Welcome Turkmenistan." Well, that is a really commercial ccTLD marketing to trademark holders. So the impetus there is different from if it was just serving Turkmenistan with 7500 or something users using the DNS. But like us, smaller ones, the problem is not so much that we don't have the know how. It's difficult to get it started, and it's difficult to find the time to read it. If you don't read the document for a week, you have to start doing it from the beginning because you have forgotten what these things mean. Okay. Then we come to Lawrie's Law. Mike Lawrie is the person who did South Africa and is probably responsible for two-thirds of SubSaharan Africa being connected. We followed Amin Iminhill (phonetic). He learned a lesson, and one was this one: If it works on the first attempt, there is something seriously wrong. We had a few small issues like this. One, for example, was we -- it took us a week or so to get our keys into ITAR until we figured out we had switched the number of the keys wrong. We submitted the zone signing key as the key signing key. The software didn't answer. As Kim has realized this, that this is not a single occurrence, so this is going to be sort of implemented that we get informed in the future. But be wary on what you are doing. And then you must hide the key. That means we haven't really started yet seriously worrying about key management, where do we do it in hardware. Hardware is very expensive, but recently I found we had -- there is a cheaper hardware coming out, so we can use that. We wanted to start it so that we can show it can be done. And then there's only one zone signed, it's my own, it's not commercial. So we are not really too much worried about whether somebody compromises the key now. Before we ever go and market this or sell this, tell the banks they can basically do it, that means we would first have to have NSEC3, and by that time we will have probably even hardware in place. Okay. The other lesson which isn't in this version of the thing is you don't need to hire an expensive consultant. A friend on the other end of the line is good enough. And here I must single out Jeremy Hitchcock, who helped us quite a lot. And he didn't spoon feed it to me. Whenever I had a big question, he did extreme measures. He copied a chapter out of an advanced DNS book, sent it to me, and made me read it, actually. So he never really told me, "You do it like this," but he gave me a few pointers, so I had to figure this out. And that's the only way this should be done. I come from a developing country. We often get projects where things get done. They leave; the projects fail, invariably. But if you can try to get the people to do something on their own and provide some assistance, that usually works. We run our primary zone at ISC, and as I said, we copied our SCP over there, and we keep a huge number of versions on there. Unsigned, there are 22 kilobytes, and signed, there are 60 kilobytes, so that's not an issue. We were worried about having the problem which another large earlier adopter of DNSSEC had by forgetting a dot or something, so we wondered if something like that happened, our infrastructure failed, that they could shut the firewall and take the last working zone, put it up, and keep the thing stable until we have recovered from whatever happened. It hasn't yet happened, and we don't think it will. We run this in the first world infrastructure setting with, as I said, redundant backup inside, outside. But we felt if we provide the service we should be robust and resilient according to RFC 1591. Then dot NU provides one of our secondaries, and they encouraged us. They came, they are much bigger than we are, so it took them a week longer to come up with it, but they had the name server ready. And they actually encouraged us from the secondaries most to go with this. That's it. >>STEVE CROCKER: Excellent. Thank you. Any questions? Let me check the jabber room here. Roy Arends from Nominet. >>ROY ARENDS: And good morning. I will keep this really, really short. I only have one slide. Actually, two, so please go to the second slide. Thank you. I will give a brief background on what we are doing, what we have been done on DNSSEC. We have been pushing the DNSSEC effort for year. We have been heavily involved in DNSSEC in the IETF. We have developed significant experience on using HSMs, pushed software development in that direction. We have invested heavily in DNSSEC deployments by funding Bind 9, Bind 10, the unbound validator in our latest project, open DNSSEC. Additionally, we have tested the DNSSEC compliance of SO/HO and CPE routers, and now it's actually time that we eat our own dog food. So we have decided to deploy DNSSEC in dot UK, first quarter next year. What does it mean? We are going to use NSEC3 and opt-out on a very small zone with very -- with well-known content. As you know, we have a similar like COM.AU and AU. We have CO.AU and UK. We are going to deploy on UK first, later we are going to deploy on CO.UK. We will use SHA-2-based signatures. The KSK will be 2K, lifetime will be at least three years. The ZSK will be 1K and roll every six months. Signatures will last for two weeks and will be generated daily. And there will be only one signature for the DNSkey set. And one thing I really want to point out strongly, is we will have no support for 5011, trust anchor management. We will not announce key rollovers to the general public, not via Web sites. We will not participate in ITAR or any DLV scheme because we believe it's very, very essential for stability of the UK zone to resolve the chain of trust via the root zone. So as for deployment, we will use a similar track action the signed root deployment plan. We will use dummy keys while we roll out. We will roll out in two steps. Half of our names -- about half of our name servers will serve a signed UK zone during the first step and the rest will come in a second step. And if there are no issues, we roll the dummy key to a normal DNSkey. Thank you. That's it. >>STEVE CROCKER: You get the prize for the most condensed, compact presentation. Quite excellent. Any questions? >>ROY ARENDS: The prize is lunch? >>STEVE CROCKER: The prize is, and here is the prize, we are going to take a break. >>ROY ARENDS: That's what I meant. Coffee break. >>STEVE CROCKER: Yeah. In the usual fashion, we have run a bit over. Let's make this break very, very short, 7 minutes. Please come back at five minutes after 11:00. (break) >>STEVE CROCKER: In the interest of time, I'm going to skip the presentation on the results from the DNSSEC industry coalition issues and recommendations. We'll include that in the material that's posted online. And there will be more that emerges or the next couple months on that. And it will fit into a lot of the things that are already being incorporated into the signing of the root that is folded into Rick and Matt's presentation. I want to start, pick up with Jeremy Hitchcock on notes and lessons of implementing DNSSEC at the registrar level. >>JEREMY HITCHCOCK: Good morning. My name is Jeremy Hitchcock. So one of the things in the implementation of DNSSEC, there's been a number of RFCs that have been around. This is the third iteration. And now we're starting to come into some of the implementation practicalities of what actually happens. And one of the things that we have noticed as something gets brought from an RFC to -- in our particular case we are working with the PIR test bed. Just as implementation decisions get made, there are different things that have to operationally be considered when things are put into practice. Next. So one of the things that we noticed in our turning on of support for registrants to be able to specify DS records and have that be published in the test bed, and ultimately what will be before the production registry, is that error checking is something that, from a user standpoint, hasn't really been talked about or socialized as a practice. So right now, domain holders have basically two different things that they need to specify. They need to specify a set of contacts, which is WHOIS is a contested item as far as what kind of things get put in there, but there is really no error checking that goes on there, other than the syntactical things that a registrant -- putting a valid phone number in. The other component is name servers, and different registrants require to put in different information. But for DNSSEC, the DS record is something where it actually can break. And this type of implementation or any implementation, really, it makes it more brittle. So one of the things that we think is important is that DNSSEC has to be validated in some form, and some sort of corrective tool or reporting mechanism or error messaging has to be given to the actual registrant when they are setting this up. Next. So one of the things that we thought of was that things just need to be turned on. For probably the people in this room, the algorithm choice and the key length is -- those items are actually important. They are chosen with some reasons of desire for particular parameters, either for testing or for implementation testing. But most users, I am guess, they just want to turn it on. So errors and how they are handled, because DS records are in different places, DNSkeys, RRSIG and NS records are in different places and people have to look in different areas that they are used to, it is going to be something for users and registrants, complete new learning of how this works. And for many users, at least on the very novice scale, they really don't have a compelling reason for DNSSEC, but for e-commerce companies and for merchants, that's something that they will care about. So for the idea that DNSSEC is mandatory for all domains, I'm not sure that that's something that -- certainly in the next year is going to be -- a point that is going to be easy to convince on. But at least for the people who want to test and see these things implemented like we do, we are certainly excited about it. Next. So for a registrar, it's actually just another field. It's actually kind of easy to pass a single record back and forth. But the important thing is DS records actually have some sort of time bounds. So one of the things we are still exploring is how transfers particularly work. And this also brings up the question which has never come up before is how do DNS and registries interact? Right now it's just the registrar and the registry that communicate with each other, but the DS record has some sort of indirect communication with the actual end DNS operator. So the things that we're doing in terms of operational experiences, we have an authoritative signing that we will do for zones, second- level zones, where we'll do the managed key rollover and have got some interesting experience with that, some interesting lessons from that, and also in managing DS records for registrants and being able to and pass that up to a registry. So a couple of very interesting things, and it's certainly an exciting time for DNS operators and registrars. And I just included this for the sake of completeness but just kind of an interface of these are all the things that are necessary -- not necessary, but that can be specified. Obviously the most important one is just the actual text part of the DS record. But you can also derive a lot of the DNS -- or derive a lot of the content from the DNSkey. But that takes away some of the security value, so you go from easy to secure and you sacrifice user convenience. And I think that's it. Thank you. >>STEVE CROCKER: Excellent. Thank you. Any questions? Good. The next presentation is from Names Beyond. Uma Murali runs Names Beyond. We have been working with both -- "we" in this case is my group at Shinkuro and our colleagues at Sparta, led by Russ Mundy, have been working both with Jeremy at DynDNS and Uma Murali at Names Beyond. And she has sent these slides and I am going to attempt to give a quick presentation on her behalf. Names Beyond is an accredited registrar operating in the U.S., in India and Canada, and they are aggressively moving forward with DNSSEC, both serving customers that are going to be forwarding their own DS records and also signing zones that they -- for the ones that they operate for and on behalf of customers. They have to cover all of the standard things of signed zone management, key generation, key maintenance, automatic resigning of the records, and provisioning up to the registry. Next slide, please. Here is a screen shot from what -- for the interface to the customer. Next slide. And here is a description of what's in the panel, the DNS zone management, key management, key rollover process, and various utility functions, with some work to be done with domain name transfer. I should mention that one of the very detailed technical areas that we have been focused on is how to do what I call ripple-free transfers between registrars. Transfer between two registrars, particularly if those registrars are also providing the DNS service, is a bit complicated because it involves, in essence, a key rollover as well as a change of operation. And Names Beyond and DynDNS have both agreed to participate in some detailed testing of that. And I expect that we will be able to report on that relatively shortly. Both are now approximately in the position where they are ready to go, and after this ICANN meeting will begin some tests. Next slide. So here is the summary of the picture where you have a customer -- some customers represented on the left are running their own name service, and they are passing the DS data up to the registry. And the path on the right represents the customers for whom Names Beyond will be generating the key and running the name service. Any questions? Super. Thank you. Let me check the jabber room. No. Let's see. We are now at the place for Jim Galvin to talk about lessons from a generic TLD. Jim Galvin from Afilias. >>JIM GALVIN: Thank you, Steve. Most people in this room probably know that Afilias is the back-end registry services provider for PIR serving dot org, so the generic TLD reference here is to dot org. I am going to talk about four things, and we have learn a lot over the last few years and being involved in this involved and tried to distill it down into a set of things that we thought would be most helpful to the broadest set of people. And the first thing, of course, up here is know the material. And at some level this sounds like stating the obvious, but if you have been following these DNSSEC workshops for years, and we -- they have been held for many years, many people have passed through these doors, so to speak, and talked about their experiences and their plans, there is a lot of material and there is a lot to know. Security, whenever it's added or included, always changes things, if not everything. And DNSSEC is not specific in that case. That applies generically to security. And so DNSSEC just inherits that. There are more working parts. We have heard references, several today, to the resolvers that are used by end users. And once you add security and you start validating resolvers, those are parts that are not under your control. And yet the things that you do will affect that end-user experience. And there are issues. The most common of which we hear about is the larger packet sizes and how that affects a users' ability to validate DNSSEC. And even after you know the material and you have researched and you have learned and you have asked and you have created your plan, one of the things that's really, really important is staying current. Next slide, please. So one of the most important places to stay current is with algorithms and parameters. A lot of what we hear in these workshops, and we have heard several today, is people offering their options for what they have done or planning to do with their TLDs. You have algorithm choices. You have key length choices. Specific to DNSSEC, you have NSEC versus NSEC3. You have to consider what works best for you based on your environment, your circumstances. There's clearly a lot of advice out there, and there's a certain commonality. So the choices are not necessarily difficult or challenging, but you do have to think about them. And in the staying current category, algorithms change. The current mandatory implement algorithms are RSA and SHA-1 in the specifications, but as we even heard earlier today from the root, they are looking at proposing using SHA-2 and that set of family of algorithms, SHA-256 in particular. These things change with time, necessarily. That's just the nature of cryptography, so you have to be paying attention. As a TLD, you will make your own choices for all of these things. Your registry will have to make choices or perhaps will permit your registrants or registrars, if you use them, to make their own set of choices. Your registrars, if you give them choices, they will make choices, too. They may or may not offer everything to registrants. And registrants may or may not want to make choices, which may drive which registrars they go to if that's an option in your particular TLD. So all of these things are considerations. Next slide. In addition, a very common theme which we have heard over the years is key management. Key management is a new process. We have heard a lot about it even today. And the Australian presentation earlier was really quite interesting. One of the effects of having to deal with validation and where the keys are and the effect that it has on their services. Conventional wisdom suggests that you will have multiple keys in your zone at a time even though one will be active so for your KSKs and ZSKs. And as a result of that one of the things we have done in our internal planning and procedures is to identify three categories of key rollovers. There are the planned rollovers which we typically here a lot about in these meetings. People talk about their procedures, length expiration on signatures, how often they are going to resign, when they are going to change their keys. Those are very common discussions. We see two categories of key rollovers to be considered. Insofar as you have multiple keys in your zone, you can distinguish between unplanned rollovers and emergency rollovers. An unplanned rollover is one where you simply take advantage of the next key available in your zone. You simply, instead of an ordinary rollover, you simply start using the next key early. Canonical example of when one might do this is perhaps you have had a staff change. In theory, one person leaving or moving on shouldn't really affect your overall security, but as a matter of principle, you may choose to want to roll forward anyway. In addition, if you are using hardware devices, perhaps you have had a hardware device failure and you need to roll over to another one. Of course this presumes that you are keeping your keys in separate devices if you have got multiple keys. So these are in some sense ordinary but provide a particular type of category. The distinction that drives an emergency rollover is that none of the keys that you currently have deployed, whether active or inactive, are available for use. So you have had some sort of catastrophic failure that has resulted in your needing to recreate a complete set of keys that you then have to promote. You have to promote into your parent, and you also have to get deployed out into the rest of the system for validating resolvers. And these are characteristically different than an unplanned rollover because they very clearly involve some significant third parties. So we offer that up as a particular specific bit of advice for people to consider. Next slide. In the past, people who have been listening to our discussions about what we've seen, the fourth time of advice is to notice that your operations will change. Your operational behaviors will change. And, previously, we've noted about the percentage of TCP replies versus total queries to our DNS servers. In the early days, we were seeing a 10 to 15% of all queries became TCP replies in the system. Next slide, please. And now we're in a state, after a couple of months of tuning and various other changes that we've made in what we've done, to where the number of TCP responses that we see is in the range of one to two and three-quarter percent. It's still a bit larger than what we're aware that other TLDs have seen. But it's just a data point. It's just an observation that you will have operational changes, some of which you'll know and expect. And there may be things that will happen that you won't know and you'll need to plan for unexpected changes, things which you weren't anticipating. And you'll need to, you know, plan accordingly. I believe that's it. Yes? >>STEVE CROCKER: Thank you. Questions? Good. Mark Kosters, from ARIN, or reverse tree. >>MARK KOSTERS: So I -- Okay. Thank you. So I'm Mark Kosters. I'm the CTO of ARIN. And I would like to talk about DNSSEC in the reverse tree. And DNSSEC is kind of like building a city in some ways. And what kind of impressed me as I was coming in last night is, the amount of infrastructure it must have taken to build this city. It took forever. I'm not sure for the rest of you, but it took me forever to get here, it seemed like. And all the bridges that are required to sustain this city over the HAN river, all the infrastructure that's required to power it up and so on. Same thing goes on with DNSSEC. What's kind of nice about this, if you're kind of a late-comer to the game, or a later-comer, a lot of this infrastructure is already set in place for you. So if you want to set up a new building, a new TLD, and have DNSSEC, all you have to do is look at the lessons of what others have gone through, and you will see how easy it is for yourself. Next slide. ARIN's board actually asked ARIN to implement DNSSEC. This wasn't a technology-introduced measure. But this is the ARIN board saying, "Hey, we want to make sure that the reverse tree is secure." And the technology part of ARIN went and looked at this. And it actually turned out to be very easy to actually implement. There's a lot of work that is out there already, especially for us, having RIPE running this for three years has helped us a lot in terms of actually being able to feel confident in deploying DNSSEC. And we also have -- as we looked at their code, one of the things that we looked at, saying, "Well, this is -- I don't think we need some of these tweaks that they've put in. So let's go ahead and back these out to make it less operationally impactful." Next slide. So as I said before, there's many TLDs that have already turned on DNSSEC. And I commend them for doing so. They've done the hard work. And now it's our job to actually go ahead and emulate that. What we did is, when we went through process, we had three phases, the first phase being making sure that us and our DNS providers, VeriSign in this case, were able to actually handle DNSSEC. And we also looked at the various keying policies as part of this phase as well and making sure what we wanted to do and how to put it in place. In doing so, we looked at the dot SE project and the number of public domain tools that they have available as well, especially with key management. Next slide. So as I said before, there's a lot of -- there's a lot of prior work to learn and emulate. One of the things that we found very, very useful is RIPE's keying procedures. And we modified them a little bit on timing. They have a zone signing -- no, I'm sorry -- key-signing key rollover every six months. And we thought that was a little bit aggressive. So we turned it out to make it a year. Hopefully, within a year, we'll have in-ADR.ARPA signed, so this won't be much of a problem. We also surveyed the various key management tools, both public domain and commercial, out there OpenDNSSEC, which looks interesting. At that point when we were looking at it, it was in alpha state. Now it's in beta. Secure64, which is a commercial provider out of the United States. The DISI project, which RIPE helped support. DNSSEC zone key tool, and others. So, again, we also wanted to make sure that there's a principle of no surprise. And putting this together, we made sure that we have some very clear documentation. Most of it was actually taken from RIPE. And we had what's called a consultation with our members to let them know, hey, this is coming. And do you have any -- any comments that you would like to make with this proposed plan? And it also commenced with a slow rollout that was multiphased. And the URL there describes that phase. Next slide, please. All right. We had some complications, like many of you will have until the root is signed. Our parents aren't signed, either, at the root, ARPA, in-ADR.ARPA aren't signed. Hopefully, they will be at some point in the future. So they need to have trust anchors. And these trust anchors are available at those various URLs below. Or through aggregated trust anchor service like DLV. Now, what our membership did that was a little bit different than what I heard Roy talk about earlier is that they would like to see some of this deployment experience sooner rather than later, before the root is signed. So we actually received some directives to actually propagate this as far and wide as we can and to as many of these repositories such as ITAR as we can. So it's a little bit different sort of directive than what I've heard before. But, you know, the more the merrier. Next slide, please. So the phase 1, as I was talking about earlier, is DNSSEC capability, making sure that we can -- our authoritative name servers were able to handle DNSSEC as well as VeriSign. We got a green light for NSEC, but not NSEC3, which is fine for now. Because we don't have to worry about zone walking. If you want to, there's 255 queries -- no, 256 queries, you go ahead and you're welcome to do so. The second part of this is actually signing the zones. We did this on July 1st, 2009. We did a lot of internal testing before we turned it on. Both VeriSign and our NOC was on high alert. When we turned it on, before we saw about four and a half meg per site. After we turned on DNSSEC, it immediately turned up to ten and a half meg. So it was basically doubled in size. And now it's at 15 to 17 meg. So we're continually seeing increase in the amount of traffic. And here's the sample of a traffic pattern off of one node of a three-node cluster that VeriSign -- or, excuse me, that ARIN runs. And you can see that the inbound traffic is roughly a third of the outbound traffic. So it gives you some sort of expectations what you can see if you run a delegation-only service like what ARIN does. The third phase of this is what ARIN is working on now. Our backend schema wasn't sufficient to actually handle DNSSEC. So we're actually going through a large, large reengineering effort to make this happen. We're about 50% there. And once this is done, we're going to have a provisioning service that's going to be built into our online service. And it's going to give consistent and better security than our existing templates, and it's going to be integrated within our managed DNS service. We expect this to roll out in 2010. So that is it. >>STEVE CROCKER: Fantastic. Roy. >>ROY ARENDS: I saw the statistics that you had in phase 2 up there. It was traffic; right? >>MARK KOSTERS: That was -- actually, the query rates did not change. But the bandwidth rates did change. >>ROY ARENDS: Okay. And can you can you say anything about the rates here? If the rates here changed between UDP and TC. >>MARK KOSTERS: I actually have not looked at that yet. >>ROY ARENDS: Okay. Thank you. >>STEVE CROCKER: Anybody else? Thank you. This is really -- Can you say anything else about what's happening with your colleagues around in the other regions? >>MARK KOSTERS: Yeah. So as I indicated a little bit earlier, RIPE has actually been doing this for a long period of time. And there's five regional registries. North America, which is actually handled by ARIN. RIPE, which handles most part of Europe. AfriNIC, which handles Africa. Africa is looking at this. They haven't -- they have not put any commitments into place yet. LACNIC, where it serves South America, they are looking at rolling this out in 2010. And same with APNIC is looking at rolling this out in 2010 as well. So everyone's jumping on the bandwagon now. >>STEVE CROCKER: Fantastic. Okay. Matt, it's your turn again. And this time, com, net, and EDU. >>MATT LARSON: Thank you. Good morning again, everyone. As Steve said, I would like to give you an update on where we are with DNSSEC in dot com, dot net, and dot edu. The plan here is a methodical and incremental rollout. We want to keep the risk as low as we can. And what you may not be aware of is that dot com, dot net, and dot edu are all in the same registry system. So this made these three zones an obvious choice to link together when it came to DNSSEC deployment. And, indeed, they are as I'll explain going forward. We're planning on giving as much as assistance to registrars as we can, various tools and support to allow them to more easily add DNSSEC support to their systems. One of the other things we're going to do is have a DNSSEC-capable operational test environment for OTE. And. We provide OT&E today to every registrar. It's a copy of the production environment so that they can come in and test their systems. This is -- it's a EPP environment. And the EPP DNSSEC extensions will be deployed so that registrars will have plenty of time ahead of deployment to test their EPP applications. We're also doing an interoperability lab for hardware vendors, ISPs, registries, and registrars, basically, anybody who wants to. We're going to have a small network and have holes in it where there could be different pieces of equipment tested, and you could see in the DNSSEC context how the equipment performs. Let me first talk about DNSSEC and dot edu. That's going to be of the three zones the one that's going first. Just a little bit about the players here. EDUCAUSE is the business -- they have a cooperative agreement with the U.S. Department of Commerce to do that. They are also, however, the sole registrar for dot edu names. So educational institutions have a relationship with dot edu, and dot edu as a registrar then communicates with VeriSign, which is the registry operator from a technical perspective for dot edu. We run the backend systems. So in that regard, we are a subcontractor to EDUCAUSE. Next slide, please. So the DNSSEC project in dot edu is a partnership between EDUCAUSE and VeriSign. On the EDUCAUSE side, they have DNSSEC-enabled their registrar systems. And this means they will be able to accept key material from their dot edu registrants and be able to submit that key material to VeriSign using the EPP DNSSEC extensions in RFC 4310. And they have also started a test bed. Well, really, EDUCAUSE and VeriSign have jointly started a test bed. And as you'll see, it's end-to-end. So EDUCAUSE is involving selected institutional partners. On the VeriSign side, we have, indeed, DNSSEC-enabled our registry system. And what we need to do is accept that key material from dot edu, the dot edu registrar, namely EDUCAUSE, and publish the signed dot edu zone. And we're also participating in the test bed. The test bed, as I said, has a small number of institutions that have been invited by EDUCAUSE at this point. The goal is an end-to- end test where educational institutions can try out EDUCAUSE's new Web interface to allow them to provision DNSSEC material. EDUCAUSE in turn is trying out their new EPP application to communicate with Saudi Arabia. We have deployed a dedicated instance of the registry system that now supports DNSSEC for just this test bed purpose, and when we first deployed that system, we copied the contents of dot edu at that time into the test system. And we are on an ongoing basis generating dot edu zone file from the test bed. And the idea is, then -- oh, and I should also say that that is resolving on two name servers. So an institution that's involved in the test can submit a change through EDUCAUSE's Web site and watch it come out the other end in a zone file and actually send queries to those name servers to verify that everything behaved as expected. And the benefits from this, I think, are fairly obvious, as stated. It's allowing both EDUCAUSE and VeriSign to exercise our new DNSSEC systems. It's also allowing institutions to gain experience, and as I described, watch the changes from end to end. And, indeed, based on this, I know that EDUCAUSE has made some changes to their systems based on the feedback. User interface changes, business policy changes, and things like that. And the test bed is not tracking the production dot edu contents. That copy only happened once. And, indeed, the contents of the test bed version of dot edu are diverging. We really didn't want to create a system that could in any way be mistaken for a production signed dot edu zone. So all three zones are going to share the same DNSSEC parameters. We're doing NSEC3 with opt out. Not surprisingly. VeriSign spent a lot of time on the NSEC3 protocol development. And particularly to get the opt-out support that we need for the large zone is dot com. And it was easier to just have all three zones in the same registry system use the same parameters. So dot net and dot edu will also be NSEC3, without doubt. And this fits with EDUCAUSE's desire in that dot edu is not made public today. We're going to be using RSA with SHA-1 to begin. We'll be transitioning to -- we're going to use 2048- bit RSA KSK, which will be rolled infrequently. The plan is to evaluate on a roughly an annual basis -- excuse me, what we think the state of the art is with regard to the safety of that particular key length. And, you know, if we think that we're still okay, we'll leave it for another year. So that key could conceivably live a relatively long time, you know, large single digit number of years, conceivably. The ZSK is going to be a 1024-bit. We're going to roll that quarterly. And as I said, when I gave the root presentation, we're rolling it quarterly not so much from a security perspective, but more from an institutional/operational perspective. We don't want to roll it so infrequently that it is a surprise. Even though we do simulate things, changes like this ahead of time in a test environment, we'd like to keep rolling it in the production environment so that we keep all those processes up to date and everyone knows how to do it. The DS changes will be provisioned over EPP, RFC 4310 documents, the EPP extensions for that. And that really just leaves the time line. As of the early part of this year, an SDK for EPP that supports DNSSEC, that is, it supports the RFC 4310 extensions, that was released. So registrars could conceivably be developing against that today. And, in fact, EDUCAUSE used that SDK for their systems. Just recently, the dot edu test bed opened. It's been running for approximately a month, I guess a little bit more than that. Also, more recently, in fact, just last week, the RSEP submission to add DNSSEC to dot com and dot net was submitted. And it's actually available right now. It's been published on the ICANN Web site. Going forward, then, we will have the dot com, dot net OT&E environment available in Q1 of 2010. In Q1 of 2010, perhaps a little later, dot edu will be signed. So this is the smallest zone. It has a single registrar. Then in Q4 of 2010, we're going to sign dot net. This will be a larger zone. And it's going to be opened immediately to the full registrar base. Anyone who is coded for DNSSEC is able to participate and register DNSSEC names -- or I should say submit key material. And then, finally, the big one, in the first quarter of 2011, we're going to sign dot com. By this point, we'll have had a lot of experience running DNSSEC in the two smaller zones. This is going to be on the same registry system, so we'll know how things behave. We'll have been able to observe traffic and what happened. And by then, we should be fairly confident that everything's going to go fine. Next slide, please. And that's all I have. And I'd be happy to take questions. >>STEVE CROCKER: Any questions? I've got one. In the dot edu, you said there are a few who are participating so far, a few universities. >>MATT LARSON: Yes. >>STEVE CROCKER: Is there an anticipation of what the uptake is going to be? Or do you have any sense of that? >>MATT LARSON: I don't know, only because that's really an EDUCAUSE thing, and they haven't -- they haven't said. Or -- Yes. That's basically it. I don't know. I do -- I can say, my impression from talking to EDUCAUSE is that they perceive a significant demand. They've been asked about this by their registrars for some time. I do know that. Or excuse me, by their -- by their registrants, namely, educational institutions. >>STEVE CROCKER: Right. So I've been interacting with them, but less so recently. And it had been kind of tepid. And so it's interesting and heartwarming, actually, to see that it's taking off, which I had kind of expected. I'm trying to remember how big that -- how many are in the zone. It's single-digit thousands is my recollection. >>MATT LARSON: Yeah, that's correct. >>STEVE CROCKER: 4-, 5-, 6,000, somewhere in there was my -- I just don't remember. I think it's a known quantity. >>MATT LARSON: It's not public, but my colleague here is telling me it is single-digit thousands. >>STEVE CROCKER: All right. Let's -- >>MATT LARSON: I.... I won't editorialize as to why it's not public. >>STEVE CROCKER: Never mind. I -- I don't think it was -- I didn't have an impression it was confidential. Great. And we're going to wrap up this session with a presentation from NeuStar from Eric Brown. Oh, oh, Oh. I screwed up. My good, great friends at dot org. Lance first. Lance Wolak. >>LANCE WOLAK: Thank you, Steve. Good morning, everybody. In my material, I'd like to go through the program-level milestones for our DNSSEC effort. In this particular slide, this information has been shared at past DNSSEC workshops. But just to take a quick look back, we were -- got our approval from ICANN to proceed with DNSSEC in June 2008. We signed our zone in June of this year. And at that time, we were the largest gTLD to sign. And we felt this was a good signal to the industry to move from R & D to implementation. And it's -- very pleased to see a number of registries continue to push forward with their DNSSEC plans. So as of now, we have over 30 domains signed to date. We have manually inserted the DS records at the registry level. We started first with some test domains. And upon successful completion of our testing of those domains, we moved out to more public-facing domains. The list up there is just some examples of those domains. So the news for this session today is that we're in our final phase of our beta test program. And in this phase, registrars are conducting tests with us. Two registrars have passed their certification as of the time this presentation was submitted. DynDNS has jumped in early, provided some very helpful leadership and strong effort in the testing. Names Beyond has also jumped in very early with the testing. Go Daddy has completed their OT&E. We have a total of ten registrar connections that have passed OT&E. We are conducting registrar education program via a webinar series in cooperation with the DNSSEC Coalition. We had our first webinar for the registrar community a couple weeks ago that went very well. Very positive feedback. They liked the format, the webinar format. We went through some decision-making as to what would be the best method to educate the registrars. And the webinar format worked very, very well. Shinkuro and Sparta are testing and documenting the domain transfers of DNSSEC signed domains. So that's the effort that's going under way right now with the registrars, is to not only get through the OT&E, but to also test transfers from one DNSSEC-ready registrar to another. We're also getting good operational practice with key rollovers. We expect to complete our internal testing approximately by the end of this year. Our production launch is targeted for the first half of 2010. As we get closer to the December time frame of 2009, we'll be able to zero in on a more specific date for our production launch. We're going through some pass/fail criteria right now. We'll have a third party continue to participate in our phase gate review. We've done that at every major mile post in our program. Back up a slide. And then with this production launch, of course, we'll be shifting from us manually pushing the DS records at the registry level to the registrar submitting live delegations. As we've moved along in our DNSSEC effort, we've had the opportunity and privilege to benefit from the long-standing work of Steve Crocker and his team. Additionally, the DNSSEC workshops at these ICANN meetings have brought us all together, under Steve's leadership. Steve's been a real catalyst to this whole DNSSEC effort. So dot org, the public-interest registry, would like to recognize Steve's many contributions. We have an item here for Steve to display in his office as a reminder of our tremendous appreciation of his effort. We've benefited greatly from his guidance and his insights. Thank you, Steve. [ Applause ] >>STEVE CROCKER: This was unplanned, and I definitely did not arrange for this. Thank you very much, Lance. >> Well, you have to open it. >>STEVE CROCKER: So I'm now holding the world. This is great. Thank you. >>LANCE WOLAK: Thank you, Steve. >>STEVE CROCKER: Nice box as well. I like the box. Okay. Very good. And you said something that caught my attention. Did you say ten registrars have gone through OT&E with DNSSEC? >>LANCE WOLAK: Ten registrar connections. The Go Daddy group of registrars makes up a quantity of those. >>STEVE CROCKER: I see. Okay. Thank you. Question. >> Yeah. I have a question, considering your registrars. You mentioned you have some selection program right now. When you go in prediction, will you have something like accreditation kind of stuff for DNSSEC that those registrars that are ready can do it? Or can any registrar use the DNSSEC at that moment? >>LANCE WOLAK: The OT&E process specifically to prepare them for DNSSEC will be the process for which they will enable themselves. And it's a self-selection process. >> Yeah, but they won't get something like a DNSSEC-accredited logo or something from you? There's no marketing program? >>LANCE WOLAK: We have no plans for such a logo or a stamp. As you know, those are hard to police and so forth. So we're just moving forward very aggressively with the registrars and looking forward to that. >>STEVE CROCKER: Question? >>ERIC BRUNNER-WILLIAMS: Thank you, Steve. I'm sorry, I didn't catch the number of registrars which is independent of the number of threads. >>LANCE WOLAK: We have three that have completed, and we have a number of more registrars in the queue. >>ERIC BRUNNER-WILLIAMS: Three. Thank you very much. >>LANCE WOLAK: The Go Daddy group consists of a number of registrar connections. >>ERIC BRUNNER-WILLIAMS: Obviously, some number greater than one. Thanks. >>STEVE CROCKER: Other questions? >> I wondered, do you have some specific technical requirements for the registrars who would like to deploy the DNSSEC for their system from dot org? >>JIM GALVIN: Did you mean something more than the OT&E environment? I mean, if you're a registrar, you can certainly have access to the manual and the test requirements. And, you know, then you would have everything that you need as a registrar. And once you -- you can prepare, and then you complete the OT&E process, then you're certified to offer DNSSEC-enabled domains to your registrants. >>STEVE CROCKER: Any other questions? Thank you. And now, Eric. >>ERIC BROWN: Thank you, Steve. So I'll just give a very high-level overview of what NeuStar is doing with dot biz and dot US. Those are the two primary registries we operate. For dot US, we received permission from the Department of Commerce to proceed with DNSSEC in September 2009. And we will be signing dot US before the end of the year, probably in the next month or so. For dot biz, we submitted an RSEP application this month, a couple of weeks ago. We anticipate approval probably late this year, before the end of this year. Tentatively we are planning to sign in Q1 2010. We do operate the registry for several other TLDs, and at this time there is no DNSSEC plan for those TLDs, at least as far as we know, but we are building and planning for future TLDs, anticipating DNSSEC. In the latest version of the DAG there is a requirement for DNSSEC for all TLDs. Some of our implementation highlights. The implementation we have chosen maintenance the dynamic nature of the zones. We are going to use NSEC. Today, both the dot US and dot biz zones can be downloaded by the public so there is no need for NSEC3. We have chosen key algorithms and sizes that are consistent with other signed TLD zones, taking into account that stronger is a disadvantage in speed but faster is a disadvantage in security. Our KSK rollover will happen annually and our ZSK rollover will happen monthly. Our capabilities are not limited to NSEC, and the cryptographic choices we have chosen for biz and US. We can do NSEC3, and we typically build to the requirements of each TLD, and we can also modify the key management process with the requirements of that TLD. Next slide. And here is the overall timeline of what we are planning to do. We're planning to sign dot US this quarter, and we will have a burn- in period, which will monitor the traffic and make sure everything is operating okay. In Q1 of next year, we will have limited access, sort of a friends and family approach, similar to what dot org has done, where we will insert DS records manually, do some testing, and in Q2 we will likely open it up to all registrars. And I should comment these are tentative schedules. They may push out to the right depending on what we see in our testing. For dot biz, it's a quarter later, same process. Signing and burning in in Q1 2010, limited access in Q2, and then opening it up to all registrars in Q3. And that's it. >>STEVE CROCKER: Very good. Questions. Yes, Matt. >>MATT LARSON: May I ask how you are doing the incremental signing? And just let me offer first that VeriSign is doing something similar and it's been a significant design and engineering effort to implement the incremental signing. And I just would be interested in how another registry is doing it. >>ERIC BROWN: I am not the right person to ask that question to. I would have to get back to you with an answer from someone from our engineering staff. I am not an engineer, and I would probably misstate something and get myself in trouble, but I can get you that answer, Matt. >>MATT LARSON: Okay, thank you. >>STEVE CROCKER: The operative people probably are across the road from each other and could go have lunch; right? [ Laughter ] >>STEVE CROCKER: Inside joke. This brings this session to a close. We crammed a tremendous amount into this session, and I appreciate everybody's attention. I think we covered some very, very important and new developments. The measurement and other details that are emerging from these implementations are a signal that we are in a new phase of this whole process. Some of the slides were posted because we got them in advance. The rest of the slides came in, as you might understand, sort of in a crush at the end. We will re-post the slides. There will be a little bit of additional information. I understand that we got the wrong version from Dr. Lisse and we will fix those up. So this will be a very nice package. Again, thank you, everybody. And appreciate your attendance here. And if you have any feedback -- I got one very helpful suggestion about how we ought to modify these sessions in the future -- quite open to all of that. Quite a lot of work goes into all this and anything we can do to make these sessions more useful and more applicable to your needs, absolutely interested in learning how to do that. Thank you very much.