6 May '09 ‑ Side Hall The DNS session commenced at 2 p.m..

CHAIR: Good afternoon ladies and gentlemen. Welcome to the first session of the domain name system Working Group at RIPE 57. If you are looking for something to talk about with regard to Internet exchanges, this is the last chance to leave the room, because our friendly door bouncer, Jim, is trying to close the gates.

So, my name is Peter, I am one of the co‑chairs of this Working Group. The other one is Jim in the back and we have yap finding his seat over there. We have two sessions. One right now. And the other one tomorrow morning, and we have some administrative stuff to go through.

First of all, this Working Group has a Rome page ‑‑ surprise ‑‑ on the RIPE website. Dot cz have a mailing list. It's on the slide there. We do have Jabber, a Jabber session active and probably remote participation. The Jabber room is given here, I hope I copied that correctly.

We have Wolfgang doing the Jabber scribe and Adrian doing the minutes. Wolfgang do we actually have remote participation. Okay. So welcome also to the remote audience and I'd appreciate slide audio feedback to the Jabber room so that we could adjust if there would be any problems.

Remote participation also means that I'd like to ask anybody raising their voice or speaking or contributing, please go to one of the microphones, state your name and if you wish your a/TPEULGS so that both the minute takers, the on line scribe, and the remote participants know who you are and the minutes can be, or your deeds can be appropriately minuted.

I guess the first kind of official action is approving the previous Working Group session's minutes. We sent around the minutes, I guess last week, mostly due to a delay cost by your friendly chairs. Actually we had some minutes to discuss and then found out that oh it's RIPE 58 around the door, let's get these things out. Nonetheless, are there any comments to these minutes sent to the mailing list? Any objections? Anybody interested? Okay, I guess we can declare the minutes approved.

Thank you.

So, next action probably is to have a look at the agenda. This is today's agenda, we will also have a speak prevue of tomorrow's items. We are in midst agenda bashing and administrative trivia. We will have a very short action walk through and then a couple of different reports as /HRO*ESly a short report from the IETF meetings or what would happen in the IETF in general. We will have a contribution given by rack lamb from ICANN /IANA with regard to the ITAR and other issues, DNS related issues that might be of interest to this forum.

We will probably not really have a report from the DNS taskforce but I will come back to that later.

John crane will give a short report of the global DNS security stability and resilience symposium that took place earlier this year and Shane Kerr from ISC will give a sneak preview of bind 10. After that we will have the regular update from the RIPE NCC given by Anand Budhev, who is sitting over there, thank you. And we will have a DNSSEC update for the top level domain of the Czech Republic and he apologise for mispronouncing the name.

Okay, tomorrow, there will be another report by the RIPE NCC. Those of you on the mailing list ‑‑ and by the way, doing some gymnastics here, how many of you are not on this Working Group's mailing list? Okay. That is like 20‑ish people. Those of you not on that mailing list missed the important discussion about the reverse triangulation reports /‑BGS you can look them up in the archives of course.

Seriously speaking there was some issues or questions raised and it's going to be addressed in tomorrow's report and giving some background on this project and informing the Working Group which is okay, because the Working Group at some point back in time tasked the NCC or gave an action item to the NCC to actually do this.

We will have a couple of presentations about DNSSEC. DNSSEC software so to speak. There will be a talk about their auto trust software and I have no idea how action item 8 made it on the agenda. This is copy and paste. We will have Jew awith a survey of pre‑delegation cheques. There will be thoughts presented by route zone scaling and we have two presentations in the Plenary regarding ‑‑ sorry, related to DNS and we will have roughly ten minutes to talk about these in tomorrow's session and then any other business and if you look it the agenda there is zero minutes for that but we still have somebody signed up so we'll sneak that in somehow.

Any change requests or additions or deletions, except item 8, for the agenda? Nothing, everybody happy so far? Great.

Okay, agenda accepted as proposed.

The action item walk through: So, we try to behave as a Working Group, so do some work or at least assign work, items to certain people. There is a list of these open and closed and proposed action items given under that URL, which is accessible also from our home page and if you go there you will find two action items that are currently hope: 51.4 and not 49.something that I falsely submitted to the agenda, is the action item on myself. On continuing work on RIPE203bis, recommendations for SOA values for a particular type of zones. Again, the dog ate my homework. I got some interesting feedback between, but that is still waiting for incorporation in the next version. Has anybody read that document by the way or even remembers what that was about? Cool...

Actually, there was nobody for the minutes. (That was)

Okay. As I said, it's about a recommendation for how to choose all the values in the DNS SOA records for small and stable zones is what we called it at that time. Anyway, work is ongoing there and unless anybody objects violently, I would propose to keep that action item just to not let me get away with not doing the work. Any comments on that? Thanks.

The next one is a rather fresh action item. 57.1, which was assigned in Dubai, and actually was given to the RIPE NCC and Anand in particular, to find out about the key signing keys for those zones maintained by the RIPE NCC and pros and cons regarding their application ‑‑ sorry, their entry into A or the DLV repository. This will be postponed to the later report and he will address that probably.

Okay. Any questions so far?

Okay. So then let me just very quickly continue giving a short report on what happened in the IETF. I'll just give some bullet items here because we had to sneak in some more presentations and I have already wasted too much time already.

So in the IETF, there are basically two Working Groups dealing with the domaining system. The one is the DNS extendings Working Group, which is mandated to take care of everything that (extenses) that has to do with the protocol immediately. The other one is the DNS operations Working Group. Oliver, are you in the room? One of the co‑chairs of the DNS Extensions Working Group is around. And the DNS Operations Working Group, I am a co‑chair, so if you have any particular questions afterwards, you are welcome to approach either of us.

I will list the agenda, some of the agenda items of these working groups in a second. So these are the two working groups: Protocol, operations and then there is of course the IAB, the Internet Architecture Board that from time to time has some ideas about what happens or should happen with a DNS and there is another RFC published by the Internet Architecture Board about the so‑called design choices when expanding the DNS, which is more a list of guidances for protocol developers and only partly to operators how new protocols or new protocol proposals should optimaley use the domaining system. Basically it is about not using TXT records but come up with good /PROELTS for your own new record time and this is in 5507. (Proposals)

Okay. DNS Extensions Working Group. The IETF also has lots of websites but the tools website is very convenient vehicle to get access to the Working Group materials at a glance. All of the active Internet drafts are listed there and their links to tools that provide /TKEUFS between different versions and stuff. That's the way to go when you are interested in what the IETF is doing in these areas.

There are a couple of open issues for this Working Group. Actually, the state of the Working Group, and that's why I was looking for Oliver, the Working Group is kind in a zombie state. It was sent to sleep I guess two or three /T*EUF's ago but then lots of new items popped up an the agenda and yeah, stuff is ongoing. So the Working Group did not meet the last time, but still tries to get work done. So, zone transfer clarifications has been on the agenda for quite a /KHAOEUL. DNAME clarification, so you see this is protocol maintenance mostly. Of course DNSSEC is important (sec) you may or may not have heard that the somehow one hashing /AL Gore item has lost a bit of faith in certain circles, so people have come up with a proposal to use, replace Shaw 1 with Shaw 256 and this is addressing this, making use of Shaw 256 in DNSSEC signatures. The document is I guess offered by ‑‑ sorry, /KWREL at that yen son, sitting over, there it is in Working Group last call or has passed it somehow.

AUDIENCE SPEAKER: It's almost in last call.

CHAIR: Okay. It's almost in last call. It was short of being last call. Anyway this is a very actively maintained document.

Another one, DNSSEC business in RFC 42 through to 35 has been published quite a while ago and it turned out that during implementation and deployment, several people actually had life experience with that and some, fed back some of the experience noose an update document which is tasked to collect ambiguity and maybe even errors in the specification to do better next time.

Probably important or very interesting for this audience is the document that is both aimed at operators as well as implementers of DNS resolver software, RC 54‑52, making DNS more resilient against forged answers. It was actually the response to the could called Kominskey attack before the attack was publicly made available. The Working Group started on this ahead of time without even knowing what was going on, so this is the ‑‑ one of the IETF's responses to the Kominskey problem. The really answer is of course as mentioned two bullets BoF DNSSEC.

Another document right on the DNSSEC agenda and I guess that is in last call is the CPE, customer promise equipment, DNS promptey implementation guidelines. Also work that was triggered by operational experience from DNSSEC deployment were people found out that, oh, some of the packets aren't really passing through our home routers and something should be done about this. And this is both aiming, or mostly aiming at implementers again but is also very important and interesting for Internet operators, especially if you have loads of broadband customers.

Newly appeared stuff: Additional CRYPT owe algorithms for DNSSEC, the ghost suit of algorithms from I guess the, the correct statement is the ‑‑ the Common Wealth of International States Organisation that standardised public cryptography as herbing algorithms and there is lots of discussions going on right now how to incorporate this in the DNSSEC suite.

Then DNS 64, that is about IPv4 /‑PB IPv6 migration and coexistence. Actually a proposal coming out of the so‑called behaved Working Group. That deals with Internet translation, also in the context of v4 and v6 coexistence and since there is much of DNS going on there, both the DNS Extensions and the DNS Operations Working Group are cooperating and reviewing that document.

DNS Operations. Okay, same here, tool site. Another RFC that has come out during the last couple of months. 5358, preventing use of recursive name servers and reflecters attacks. That was basically the one that was recommending against open recursives. We have talk about that a couple of times in this forum I guess.

We have on our agenda, a document about DNS trust anchor prefers, so if I publish a trust anchor like the NCC does, and who signs a zone and doesn't have a signed parents /WHAFPLT format should that be in and what format should it be incorporate /TPHAOD your resolver software. Also interesting for operators.

DNS resolver priming, I guess I mentioned that the last time in the context of IPv4 ‑‑

CHAIR: It's falling into sleep on behalf of you /TKPWEU he is.

CHAIR: I will accelerate. Point taken.

RFC 4641 bis, 4641 is the RFC that describes DNSSEC practices, so what key sizes to choose, how to do key rollover at which, and what frequent tee to key rollover and so on and so forth. Practical experience and the valuation of the dot organise proposal to sign that top level domain has led to a plethora of feedback, so to speak, that has found its way into proposals for an update to that document, which is fine because as you can see from the number, the RFC itself is, I wouldn't say aged, but a couple of months old so to speak, and feeding back practical experience is a good thing. Again, probably very interesting for this audience, something that could arise from this action item, a document that is in last call in DNS op, requirements for named server control protocol. The idea is that many people have /HET Jean use firms of name service using different ‑‑ bind NSD, bah, bah, bah, you name it. And would very much appreciate to be able to have a unified interface to those when it comes to reloading, adding, removing zones and awful these tasks. So the groups, a design team set together ‑‑ and this is what the group came up with and the subsequent work will be the one that is then probably influential for this audience, which is actually the specification working on the actual name /SROFR control protocol, bounded or guided by this set of requirements. (Service)

This that is just been a discussion so far. RFC 1123, that is a cast in stone old RFC, actually a walk through, through all of these Internet protocols back then. There is a reading that says, okay, top level domains must only be alphabetic, and some people read it the way that there are no dashes allowed which would probably be in conflict with IDN domains because they start with XN‑‑ and strictly adhering to the protocol or to the text there would bring some people in trouble. So, there is some discussion going on on how to make this change, how to apply this change with the least changes possible.

And then again, in relation to RFC 4641bis, we have a proposed document on DNSSEC key rollovers and a very exact time line how how to work which is /TRAEUGSly interesting for DNSSEC operators.

And that's probably it. Questions?

AUDIENCE SPEAKER: Stefan AFNIC. Maybe I didn't his /EPB enough but about DNS extension, did you (AFNIC) mention the possible future walk on the forgery residence plus plus ‑‑ /SKWREUPing or the Z OX20 which raised a lot of talk?

SPEAKER: Of course I was intentionally trying to avoid this very controversial topic. No, just that dropped off the slide. So thank you for that addition. There is currently actually ongoing discussion, whether or not to do something besides DNSSEC and which of these various ‑‑ sorry, which of these many proposals to follow and the Working Group hasn't made up their mind yet. Thanks Stefan. Any more questions?

If not, then I guess, who is next on the agenda? .



SPEAKER: Hi, I am risk lamb. I work at ICANN I am. I am going to talk a little bit about some of the Interim Trust Achor Repository stuff that we have been doing. A lot of this work, most of this work is done by, and including most of the slide deck has been done by Kim Davies, my office mate. And so a lot of credit should go to him. I take all the blame though.

The first time I have used a Mac for this.

All right, so the interim trust /A*PBG rerepository we have in place now. I don't know how many of you have played with it. It's still in beta. People are using it consistant. It's a mechanism for the top level domains to register their keys. Right now we are taking DS records. There has been some talk about maybe taking some other records instead. Once the route is signed, the idea is that this would go away. It is currently considered a stopgap measure. However, if there is interest in keeping it around longer, I think it's important for people in the community to voice that.

So, that's the current plan. Demission it once the root is signed.

Here is a picture actually of what we have in place. It's actually very close to what we have in place right now including the signed root test bed we have had running for almost two years. So in fact, the formal NS records get processed the way they always have. There is no change there. We take that database directly from either an L root field or whatever, and we take, feed that directly into a system that validates the DS records. The ITAR, actually has is fully functional in the sense that all the processes and procedures are being followed. When we get a request for a DS record or a key, a TLD key to be inserted, we go through the process of sending out e‑mail to the contacts. We do technical checks. It's really just like the rest of the IANA process for many other functions. The only thing that doesn't happen as you notice in this picture is, once the, once the record is passed all these tech checks and the administrative or the tech contacts have been notified, we publish directly. So there is no step through the Department of Commerce object anything else.

So, we follow the recommendations that were provide bid RIPE and I have to, I'll be thanking him a number of times, I have to thank Daniel Karrenberg for the whole idea of Trust Anchor Repository. At first I was a little /SKEPD am but I think it's a very useful tool. (Sceptical) it's designed. If you have looked at the interface, it's simple. It allows for just a pure web based interface and even though it's simple, you will find out there are some problems that we have been having. User education problems.

It's set up to work on any one of a number of the DNS packages out there. In fact, Kim has written some scripts to make this all as easy as possible. Almost fully automated to the extent that the processes that we normally have to devalue date these keys are still, have human components in them as I think they should. And of course it's going to help the whole deployment process.

Here is some just short screen shots of what we have. You will notice that the web page itself actually has an E V cert associated with it. One of the ideas here is, this does form a chain of trust. So, what we put on this web page should be somehow verifiable and validatable and so, instead of ‑‑ we spent the extra time and effort to actually get an A Vcert which requires all kinds of things like CFOs to sign off on things and prove we are who we are. So we got one of those for this. It's also PGP signs, so if there were /PHEUR sites that wanted to take copies of this, there is also a PGP signature on this.

There is the page, you guys can go to it as easy as anything else. We are still looking for comments. But any feedback would really be helpful on the way this things works.

Experiences we have been having so far. There have been about a lot of user errors at this point. People put in the keys with too many spaces or enter into the wrong keys, wrong algorithm types, we have had this a number of times going around, so in response, we have added more checks, more technical checks in the system, so they get immediate response back instead of waiting a few days before they get feedback.

It's actually working pretty good at this point. We have a lot of keys. We got all the popular ones.

So, here is some requests we have gotten from the community. Is there a way to suppress come things, the NSEC3 records? We do have support for those key types as well if you look at the pull down menu. SHA1, should we prohibit it (SH A) DNS keys might be better than DNS records.

I am going to switch a bit to the update. An general update of where we are. He have been asked to sign the root by a number of TLDs as well as other companies as well. There was a Notice of Inquiry that happened back in November of last year and the response pretty much was 20: 1 in favour of ICANN signing the root. Your mileage may /SREUR.

I want to get to this next point. I have been going to a lot of conferences outside this group. Like the RSA conference in San Francisco and these aren't new revelation to say any of you, there are a number of revelations in that community regarding DNSSEC. There is this whole idea that you can do a lot of other things with T I know RFCs and things have come out for DKim as well as SSH to hang other systems that need a source of trust in DNSSEC. I am going to try ‑‑ I spent a lot of time talking to Dan Kominskey and he is one of the guys pushing this hard. He sees this as being what do people already trust? Well the world also trusts DNS to a certain extent. If we add seasons desk to that thing, now we actually have a cryptographically traceable chain of trust and this is extremely valuable for a lot of things, security problems, not just spam and the usual things. I know people have different views this. DNSSEC should never be used for this, maybe it should be. I am just reporting what I hear and the crescendo that I think this is building up to.

That's one, just one of his slides, but it does, this cross organisational authentication is can go that is a fundamental problem for being able to trust someone that you haven't actually established a trust relationship with previously. So...

This is our test. This is our test bed where we have a signed root. It's been around for almost two years now. We have wash dog sites looking at T we have great Anycast services that's been provided by PCH and others that covers the world. It's cool stuff I really appreciate PCH and DYN, TLD folk.

Better to fail now than later. There is some Masters there, you can connect to, there are Anycast. There is some recursive resolvers out there. Bang on it and try to make it break as quickly as possible. As soon as possible,

This slide is trying to point out what I think the larger security community out there is starting to see. Like at the RSA conference. This could be something that actually could be really useful to a broad set of problems and an international group of people that are starting cyber security right now.

A lot of buzz words.

There is an upcoming event in June and if you are not on the DNSSEC deployment list you wouldn't have seen this, but I am sure a lot of you are and if you are not, just ask me and I'll send you the invitation. But there is going to be this event in the middle of June on you know, how to deploy a signed root, and in fact they are going to talk about some critical issues here. Distribution, rollover, etc.. I encourage ‑‑ it is limited, the number of people, but if this is something that is near and dear to your heart, I encourage to you try and get invited to this thing. The choice of location wasn't mine, but there it is.

That's pretty much my talk. I just want to make sure I didn't miss anything here. I mean, one of the things again about having this extra, being able to use DNSSEC as this other source of trust is that it does provide some resilience to the network. That was that MD5 crack that happened back in December of last year, it would be great just to have another source of trust that we could all check again. Are you sure? Is there somebody else I can check with? I think there is a lot of opportunity there and so that's something to keep in mind as we go forward to try and get the root signed and how that process and procedures actually get determined.

That's it. I am going to leave it open to questions at this point. Does anyone have any questions?

AUDIENCE SPEAKER: You said that the ITAR file is signed with PGP but the last time I checked the BGP was not signed by anyone, not only anyone I knew but anyone. Isn't it a problem?

SPEAKER: It is a problem and that's why one of the reasons it's still bait eye. What I am working on personally is to actually port some of the BG B code to secure the whole thing and then also have that key signed by other people as well. I mean there are two parts to this. We need to get some more, create a larger web of trust but also, you don't want the private key or something like that just to be sitting there. This ITAR is a signed root, so it should have the same level of protection and so we are working at building both increasing ‑‑ making that pour public so we can increase the web of trust but also to be able to use something like an HSM, some hardware module to actually store the private key material.

AUDIENCE SPEAKER: In the meantime the BGP signature should be ignored because it doesn't have the same level of security?

SPEAKER: I don't know if it should be ignored, it is still in beta. I am working on it as quickly as I can.

AUDIENCE SPEAKER: Jim Reid. Not wearing any hats. I want to thank you very much to you and your colleagues for all the work you have done with the ITAR. I think it's a great piece of work and great benefit to everybody.

SPEAKER: I have to thank you guys for coming up with the idea.

AUDIENCE SPEAKER: Now comes my question: As we all know, the NTI run a consultation exercise last year and a number of proposals and potential mechanisms for signing the roots. There has been a deathly silence since then. Okay, there has been a change of administration and maybe things have taking longer to sort out in the Department of Commerce. But I wondered if you have got anything to say about any protective plans or prospective plans or insights into what the steps are like lie to be? Are we going to get a root signed soon fanned so when? What do you think the next steps are likely to be in this exercise?

SPEAKER: Well, I think at this point, we are still in a holding pattern with regard to commerce. We are not just sitting around idly there are discussions with them. I am not allowed to speak about some of the discussions, I would love to but I am not allowed to.

AUDIENCE SPEAKER: Can I ask you about those over a beer?

SPEAKER: It was not over beer, if it was over beer, I think we wouldn't have had a problem. But I'll repeat what I said earlier in the year at the APRICOT meeting, not depending on any information, any special information at all, just looking at the general, because this is what I do day in and day out and I see the buzz, just based on public information and personally, when someone asks me at the APRICOT meeting how long before the root is signed? End of the year. So, I stick by that guess and that's not based on anything other than just public information of what I just see the efforts behind some of the efforts in the DNSSEC deployment group which have been really good, some of the efforts that have been going on in other places. It's clear that there is a lot of pressure, commerce is listening to that pressure. We are listening to that pressure. Get the root signed, we hear you. So that's why I say ‑‑

AUDIENCE SPEAKER: Just for my own benefit and maybe for those that didn't quite pick up on that, when you say it's signed by the end of the year, I tack you mean 2009?

SPEAKER: That's my personal view, yes.

AUDIENCE SPEAKER: I actually heard Paul Twomey say two weeks ago it will be December 2009 at the latest.

SPEAKER: Great. So watch out. Get what you want. So...

AUDIENCE SPEAKER: I am glad Jim asked that because I was going to. I have another question:

In the ITAR, the way you had that phrased was: DNSKEY records instead of DS records, do you really mean both?

SPEAKER: Yeah, I think we mean both. It's a question of whether we want to support both or not. Right now we are just doing DS records but Kim has got some scripts up there.

AUDIENCE SPEAKER: Richard Barnes: I had a couple of questions. I have a couple of comments and one question.

The first comment is just to thank you you guys for being so proactive on this. I think the ITAR is a good step to getting a lot of deployment experience as a step to the signed root and that's my second comment is to please, demission this thing and stick to that plan when the root is signed. Because it's important for the overall integrity of the DNSSEC system to have that hierarchy in place. The PKI system is the other major experience ‑‑

SPEAKER: Let me understand you would like it decommissioned?

AUDIENCE SPEAKER: Yeah, I would like to, for people to rely on the root instead on this Trust Anchor Repository because it creates a consolidated model that's not fractured T creates a single hierarchy.

The question I had was: When I first got the e‑mail announcing that the ITAR was out in beta, I went and downloaded the Trust Anchor list and I clicked on the little icon to look at the certificate that was being used to support TLS for this and I noticed it was issued under the GoDaddy CA, and so the entire DNSSEC system now chains up to GoDaddy CA and so I was curious why you chose to go to an outside vendor, as much as I have love to have Dan /KA Patrick associated with the DNS ‑‑ but you know, especially if you are looking at deploying HSMs and really level 4 crypto. Why not have ICANN act as a CA to certify all this data?

SPEAKER: I have to be absolutely ‑‑ have who be the CA?

AUDIENCE SPEAKER: Or whoever is running the ITAR.

SPEAKER: Well it had to be a CA that everyone would recognise, so we are really talking about a small handful and /T‑P wasn't a conscious decision. It wasn't specifically chosen, GoDaddy, it wasn't specifically chosen. This was just let's find something that meets all the requirements of an EVcert and GoDaddy has a certain reputation, let's find something ‑‑ and it met all the requirements. And in fact we were also hearing from some people is that the PGP signing would be the more important part and that we should spend more time focusing on that because there might be mirror sites and they are going to have different web page signatures as well. But yes, sure...

Thank you very much.

CHAIR: Thank you. (Applause)

CHAIR: And I guess next on the agenda is right on time, the reports from the DNSSEC Trust Anchor Repository taskforce, right?

SPEAKER: There are no slides for this. My apologies, but this is just a very quick update.

You will remember a while back that we set up a small taskforce to look at the attributes of what we think were necessary for a Trust Anchor Repository and we then sent that for for consideration to ICANN at the point where ICANN was considering putting together a Trust Anchor repository and I think the input we gave was valuable to Rick Lamb and others that did that work. Once we had done that we decided that at that point the taskforce wouldn't necessarily be disbanded with you be put into a zombie state with we could reactivate this if we felt it was necessary to bring it back from the dead.

At the moment we think there is a small action item that is of left dangling for this taskforce to look at and that would be to consider how well the ICANN Trust Anchor Repository reflects the attributes and the considerations that the Trust Anchor Repository came up with that was then endorsed by this Working Group. We tried to get the tar taskforce together to do that during the RIPE meeting so for a variety of logistical reasons we couldn't get enough of these people to be in the same place at the same time this week. So, the tar taskforce will try and do that piece of work over its mailing list and report back on this again to the DNS Working Group and perhaps we will close this item out at the next RIPE meeting with some sort of presentation to this Working Group. But of course, everything will be done in a mailing list and we can see what's going on there. But I think you know, we will see, make a judgement for the TAR taskforce to say whether the Trust Anchor Repository at IANA meets all the things we ask for and has all the attributes we felt and we could pretty much say declare victory and dispanned this TAR taskforce for once and for all. Hopefully by the time we do that, the root should be signed. So then it will go away completely.

Okay. Are /THREU any questions? Do we think that's a reasonable way forward? Do we need coffee? Do we need beer? I see more heads nodding. Okay. Thank you. Next item. John Crain (C RA I N)

CHAIR: John, the floor is yours.

SPEAKER: I think we actually need whiskey, but that's a whole different matter. I am not going to show you my slides, mainly because they are not very good. But I through them together with some notes.

So, who is aware of something called the global DNS security stability and resiliencey symposium? A few people, a few of you were actually there.

Late last year some people came to me from our staff and our executives and said Mmm we know there is a lot of risk involved with the DNS, but it's not actually really documented very well anywhere. So what we decided we would do, myself and a couple of others was to try and get a group of people together to try and basically document what are the risks associated with the operation of the DNS and using the DNS. We got together with an organisation called Georgia tech, a gentleman called David Dagen, who, together with myself, chaired the symposium and we invited about 100 people that we considered to be knowledgeable over the area of DNS, be that operating, writing, /SROFR software, writing clients or in the area of security. We formed a small Working Group, four or five people from around the globe, many names that you would know and tried to put together a good group of people that were fairly spread across representation. So for example we had people from the main operating systems, the main browser, writers, obviously the people who wrote a lot of DNS software, but we also had people from security firms, Internet service providers, TLD operators, quite a wide spectrum.

So the main purpose was really to try and document some of the risks that we knew and to do a gap analysis, to try and figure out if there were things we hadn't thought of. And there is a report that came out of this and I have actually just sent it to the Working Group list, apologies for that being so late.

And we didn't really know how to go about doing this. Nobody has really tried to do this before, so what we did is we chose three areas that we would focus on, and then we picked out three Working Group chairs or victims as we like to call them, and made them basically try and run these sessions. So we picked out the use of the DNS in the event price, so how do enterprises use the DNS? How is the DNS provisioning etc. Affected in resource constrained environments? That could be from a developing economy or it could be a small organisation, you know, what's the difference? Because just sometimes you have different effects and the other one was combatting malicious use of the DNS, that was interesting, unfortunately I didn't get to go to all three of them.

One of the first things we realised when we started putting together the report ‑‑ so we did this symposium under the rules which basically your names doesn't get associated with what you said, so the first thing we noticed when going through all the notes, and there was a lot of notes, was that generally speaking, people aren't really aware of the risks associated with the DNS. None of this is going to come as a surprise to people in this room because we all work with the DNS and we are all very familiar with T but you have to remember that we also had a lot of other types of people in this room. So, the awareness level was extremely low.

One of the things that was very clear was that we need to figure out how those of us who operate and those of us who use the DNS, specifically the highest scale such as ISPs, can coordinate when bad things happen. As a community, we are not very good at that. A lot of us don't have really clear associations with certs, a lot of certs don't have knowledge of who operates what, and the same can be said for ISPs.

We had a recent event, something called Conficker, aassume a lot of people have heard of that. Come to the meeting on Saturday where we are going to talk a little bit more about that, but that made use of a lot of names spread across more than 100 zones in the DNS, most of them being country code /TOPT level domains and that required some coordination and we really as an industry are not set up to do that. ICANN is not a cert, we are not an incident response body so we are not set up to do that. And really, you know, as an industry, we didn't seem to be.

So in February we said we don't seem to have this and then in also February, in April some bad guys went and proved the fact for us. So that was interesting. So awareness of a big issue. As was knowledge. The other side of that, so you know, there is a clear need to spread more knowledge and do more training around operating systems.

This issue came up in all three of the sub groups.

The other thing that came up that goes along with that is a lack of tools. There really isn't that much out there. Hardly a surprise, there isn't a lot of monitoring tools that are specifically designed for use with DNS, for DNS operators. Thanks to the folks who have been writing some of this such as DSE etc., but a couple of years ago there was almost nothing. That was another big issue. I am being told I have time here so I am running out.

I guess the main thing was that it was the first time we tried doing this. It was really interesting. I think one of the best outcomes was, as always with these kinds of things, it was the corridor work. A lot of people got to meet people who they normally wouldn't, and had a lot of interesting discussions because of that.

The report is about 30 pages long. I just posted a link to the DNS Working Group. I don't know whether there will be a second one of these. It was one of the questions at the end. Everybody who bothered filling out the questionnaire, which is always a small percentage, said yes. But we have got to figure out what the purpose is.

I sent out the link to the report and I have a request: Please go and read it, but read it with with a mindset where you look at what it raises as the problems and try and think how you or your organisation can help with solutions. I mentioned two or three things about awareness, but there is a lot of other things that were raiseed in this report. So read it with the idea of do I know a solution for this? Can I be part of the solution? Rather than just reading it as a set of problems.

I suspect if we dodo another symposium next year, that that's what we'll be looking at you know, have we moved forward? Have we found any solutions? With that, I won't waste any more of your time and sit between you and the whiskey. For those of you who are thinking that they might want to come next time. We didn't invite Dana Patrick but we could do for guy that likes GoDaddy. Thank you, I'll take questions.



CHAIR: Thanks very much John. We have two minutes or so for questions. Anyone volunteers?

AUDIENCE SPEAKER: Wolfgang RIPE NCC with a question from Jabber from Edward Luas, affiliated with new star. "Since the meeting in February, some people have asked for any reports or evidence that the DNS is attacked in a way that DNSSEC addresses. We have skin ski's work to document the vulnerable but folks want evidence of the match. Do you know of any way to find documented incidents such as that? Is it the certs?

SPEAKER: Hi he'd. I have not seen anything document that had DNSSEC would specifically have solved, no. But, you know, this wasn't just about DNSSEC. We deliberately designed or tried to design the symposium not to go down the DNSSEC road because there are 50,000 place to say talk about that. We wanted to talk about other risks. Naturally everybody did, because DNSSEC is apparently sexy. Apparently...

AUDIENCE SPEAKER: Keith Mitchell, ISC and RIRC. Actually just to respond to Wolfgang's question. One of the things we have done or I think we have been to some extent trying to find solutions to some of the questions that John is posing for some years now, is we did experiment with a security incident ticketing system. It's still there, but it doesn't really get used, so we are having some thoughts about better ways to do that. So we are certainly open to input into terms of how do we share incident share incident notification and you know when did bad stuff happen? And how do we coordinate response to that.

SPEAKER: I want top point out this was not an ICANN symposium. Georgia Tech and also Georgia maze /EPB university was really an attempt to get the community together. And I am really grateful for their support, otherwise we'd have never pulled it off.

AUDIENCE SPEAKER: Moss answer /SWAOESey. Thank you John for that initiative. For instance I'd like to have some feedback, maybe, it may be useful for next edition of this symposium. The term symposium was, I think was strong so maybe people, when they learned about that event happening, they expected maybe there would be a great declaration DNSSEC is to be deployed by everybody there. So my comment is: We lacked for a long time from some agenda who are the community targeted? Should it be the CTU? Should it be the CEU to go there? Should it be two or three persons or only one? So actually I think there are, for the next time, it should be clearly specified who are the communities, if it is similar communities to be targeted and what is the outcome expected of it? Is it a big declaration? Or is it something more concrete and I am not judging the value of either, just...

SPEAKER: Yes, for this first one of the answer to what would come out of it is: We didn't know. It was in many ways an experiment. And we tried to avoid the politics of what kind of organisations etc.. Maybe the next one will be different. Maybe we'll put you on the steering committee and then you can get on the five o'clock in the morning calls and help us. Be careful what you ask for, just like DNSSEC.

CHAIR: I guess that's it. Thanks very much John for that report.

(Applause)

CHAIR: And with that I would like to invite Shane to the floor for giving us an update on BIND 10 and the BIND 10 Project.

SPEAKER: Shane: Unlike our last speaker, I did put my crappy slides up. So...

My name is Shane Kerr, I am the BIND 10 programme manager at ISC and I am kind of here to discuss the BIND 10 development effort.

What happened to date right now is that Joao Damas has spent a lot of time defining the problem for BIND 10 and I am going to talk more about that shortly. And this presentation is mostly based on a white paper that was put together by Joao and Paul v6ey, so it's based largely on that kind of defining the problem and how it's going to be involved. This will look very, very, very similar to people who saw this at the centre workshop, but hopefully, it won't be too boring.

So, BIND 9 is a very large piece of software. A recent survey found that it ran on about 80 percent of the DNS servers in the world. It's also a very old piece of software. It's approaching its 10th anniversary. What happens to software as it gets old, the environment that it was designed for changes out from under it. That's basically what's happened to BIND 9 is the way that we use computers today, the way that DNS works today and all of that is significantly different than it was a decade ago.

So, based on this real identification, at some point you have to look at your self and decide whether you are going to continue to try to hack it to keep it working with the current environment or we write it from the ground up. So the decision has been made to rewrite it from the ground up. And this decision is based on a number of observed problems with BIND 9, which you see on this slide here. So the first problem that we see with BIND 9 is that it's a monolithic and what that means is that there is a single programme which does everything. And it's a pretty good at everything that it does. We can debate that over coffee. Will you it is pretty good as everything it does. But it does a lot of things and if you don't need most of the features, then you have a lot of from code below T you have a /HROD of extra memory B, you have a lot of configuration ‑‑ it requires a lot of training to understand configuration option that is you probably won't need. So that's the first thing on there.

The second thing is a bad process model which is a fancy way of saying that BIND 9 is a little bit slow. It's ‑‑ it was originally funded by a bunch will union I can spenders that they were kind of at the time at the end of 1990s it was fashionable to do everything in multi‑threaded single processes, shared memory and it turns out that that's a very good model for writing database front ends and things like that but it's a very bad model for writing UN‑IX applications do a lot of package problemses which is what bind is. (UN‑IX)

Next thing it BIND 9 is hard to administer. This comes from back round ago being into big union ex vendors. It's a standard UN‑IX process which means is has its nice cryptic configuration and hard to understand log files and if you don't understand DNS deeply then you don't understand what bind is doing. Even if you do substance DNS very well then you still probably don't understand what bind is doing.

The final thing on my list is BIND 9 is hard to hack. I mean this from a software developer point of view. Also from the point of view of the system administrative level, a lot of time the system administrator you like to get little tweaks for you are system to do what it needs to do. With BIND 9 if you want to make a small change, it's almost impossible. You have to understand the entire application in order to do the smallest thing by has, over time, led to BIND 9 being more and more only modified and adapted by the core ISU development team, which is not to say they don't do a good job, but it's a, there is only so much a small team can do and they are not likely to solve your very specific problems, which is if it it's software you can change, then you are going to solve them.

So, what is BIND 10 going to be? This slide has been presented before these bullets so none of this should be too new for people but I'll go through it very quickly. These are mostly, if you see the first list, these are the answers to that first list. It will be modular, meaning that you only have the run the parts that you need for it to run. You will have a small footprint. It should be faster in most circumstances. Our goal of course is to beat NSD in all realms and I am bound on the recursive side.

BIND 10 well defined APIs and libraries. I'll do my best to make sure we keep ourselves honest. We won't cheat F it works for us, it should work for you.

Customisation, again, part of this modularity.

Cluster support, this is an area which is especially important as your DNS becomes bigger and bigger. It's starting to get to the point where more and more people need more than one machine for reliability and also for performance. Right now that's all done with custom shell scripts and routing protocols and very hard to understand things. We intend to make it possible to couple this closer to the actual application.

Integration with existing work flows. I didn't write this but I think it means that we want to run well with Windows. So... Or other existing environments that do address management and name space management, things like that.

Resilience: If you have ever had BIND 9, say assertion filled or insist filled then you know what this means. Part of BIND 9's design was to avoid any possible security problems, if at any time the code discovered that there was something that it didn't understand, it would end. Which is a very safe way to operate but it's not very satisfying as a user when your name server restarts and you have customers losing queries.

And better run time control. This is another effect of being modular, is that the system ‑‑ right now a lot of things require configuration changes and restarts and things like that. Everything will be done through some sort of messaging communication between the different parts of the application. So if a new interface becomes available on /KWRURP named server, it might a.m. /KHRAOE detect it and start answering on that if we can configure it that way. That's the idea there.

So, what is going on with the BIND 10 project. That's the white paper stuff. So what is this actually going to look like? It's a five year mission. I won't say anything else beyond that. The first official deliverable is going to be within one year as of April 1. So if you are looking for something you can download ‑‑ really ‑‑ if you are looking for something that you can download and run and have it do something, and that's going to be an authoritative only server, the main point that have is not to actually have a product that you can use, although I am hoping that some people will be able to use it to solve their problems. The /PHAEUP point is we want to put this glue and framework together and have something that we can build from that point on. The authoritative name server is to make it something that's useful.

We have a /SPET of sponsors right now. Thank you very much for their support. They are really great. We are still working out exactly how we are going to work together. Some of them are giving money ‑‑ well everyone is giving money on that list. Some people are also giving staff and other ‑‑ I am hoping technical expertise as well, that would be very nice and requirements of course and things like that.

The sponsor list is not fixed. I expect there to be more work in year two than one. You will notice that awful those sponsors are top level domains which I personally hope will expand out. I'd like to see big ISPs people running recursive resolvers, also being sponsors, to make sure that requirements don't get forgotten and how they do business works well with the software. I'd also like to see perhaps some embedded vendors involved in the list. I don't know, maybe I can convince the end red project to participate and things like that.

So, so it's an ISC project, which means that IV C is the one that's going to be hiring the codeers, we'll be needing more. We'll be doing all the project management and communication and things like that. All the sponsors are on the steering committee to keep us honest. You don't have to worry about us being hijacked by some crazy idea that I have to turn this noose a whois server or something like that.

Right, so that's kind of the big picture. We sent out a press release two weeks ago which was the official announcement and that's kind of the kickoff from my point of view. You have possibly heard about this project before and you are wondering where this sounds like another kickoff presentation. But this is the real one. This is it. We are really getting started and that's it.

CHAIR: Thank you Shane. I guess we have time for one or two questions. Anyone? Please use the microphone.

AUDIENCE SPEAKER: I have one very simple question: It's to discuss sponsor ship ‑‑ with whom do I discuss sponsorship?

SPEAKER: With me.

AUDIENCE SPEAKER: Jim Reid: Shane, I think it's a great idea, and I have a little bit of a concern. Are we ‑‑ is the intention here for BIND 9's broad requirements lastly going to based around what the sponsor believe the requirements are, or a piece of software that meets their specific needs? And second following question after that: Is there a way for people who are not in a position to contribute resources whether that's financial or programming expertise to give some input into the general guidance about things like requirements and comment on them? I mean if I am a random member of the public that has some degree of interest in DNS software, how can I give information about the IFC about my shopping list of requirements and features that would like to see in BIND 10 if I am not a sponsor?

SPEAKER: Your first question is I think the answer is pretty straightforward, is that BIND 10 is going to be DNS for we ever one, so one of the goals of BIND 9 was to be a reference to implementation for all the RFCs. My personal belief is that it does a very bad job at that. It does implement the RFCs but it's very bad reference implementation because you can't road the code and understand how it's supposed to work. Certainly we'll meet all the RFC standards. My own personal preference is that we ‑‑ IFC is a public benefit cooperation, we are there to do good for the Internet. We are not there just to do good for the sponsors. For instance, right now, people did some surveys I believe last year looking at home routers and the DNS that they provide and discovered a lot of problems. I think a lot of that is because people writing embedded systems have no alternatives. They have to download small software written by a student over a weekend and it doesn't implement the standards very well. If BIND 10 scales down which I very much want it to do. That will help address that area. That's an area that none of our sponsors have any direct interest in. It will help them because as the quality of DNS on the Internet improves, everyone benefits.

AUDIENCE SPEAKER: Are you doing something and thinking about having a set of open mailing lists where people can contribute comments and invite that kind of thing even though not directly involved in this project?

SPEAKER: This goes into your next question which is how you can participate? One of the problems also with BIND 9 is that it is done by this kind of small closed group of developers and even /KROBD code has to be vetted and audit and either adopted or it suffers almost Meath bit rod. One of my goals for BIND 10 is that not to be the /KA case. There will be a lot of proactive communication, I am going to set up a blog, there is already an announced mailing list. We are actually a technical writer on staff now, he is going to be producing articles about the design decision that is we make. That's from the out bound side. On the inbound side there will be a public bind 10 developer mailing list that you can participate on we are going to be publishing our ideas about design and our decisions along with our rationales as we make them so. That documentation will be, as much as I can make happen, available on the Internet. You can look at it and then of course I'll be very interested in having discussions about whether it fits your environment, whether you think it's going to work in the future and so on. So, yes, it will be much more open and community driven than current bind development.

AUDIENCE SPEAKER: Thank you very much Shane.

CHAIR: Thanks Shane.

(Applause)

CHAIR: With that, we are lacking a bit in time and running into the coffee break I guess. /AL and is next with the report from the RIPE NCC and while he is going to find his slides on the laptop, I'd like to do another show of hands here. How many of you, this is the first DNS Working Group session that you visit?

Lucky enough you are sitting in the front. That is like 35 people. Okay. The one thing that we have been having on the agenda for a couple of meetings or actually a couple of years now I guess is this list of reports, and as chairs are lacking a bit of feedback as to the length or depth of these reports, so I am not going to do a survey right now in here, but if you have any opinion on that, whether positive or negative, please try to catch one of us in the hallway and give us feedback, whether you want to see more or less of that or have other ideas or contribution or would like to see someone else contribute something, so we can immove and make this valuable sessions for all of us. Thank you. Anand, it's yours.

SPEAKER: Thanks. Good afternoon ladies and gentlemen, I am Anand butt delve, I manage the DNS services department at the RIPE NCC and this is a quick update on what we have been doing so far.

Before I start my actual presentation, I'd like to cover the action point 57.1 which was an action on the NCC, and that was to do with the RIPE NCC's trust anchors in the ISC DLV.

We did go away and look at it and one of the things that we, as the NCC, you know, are strongly in favour of is of course for the root to be signed. And the ISC DLV was also in testing, so we hadn't actually taken any action to upload our trust anchors into the DLV. However, we discovered a few days ago that the trust anchors have been imported into ISC's D V, and that came as a little bit of a surprise to us. We have contacted ISC about this and we have the facts now about when it was added and at whose, and whose decision it was, but that's the current status. The RIPE NCC Trust Achors are in the ISC DLV at the moment, but we did not put them there. So, that's the situation.

I suppose we could have a discussion about that after the presentation.

Introduction. It's a small team at RIPE NCC that does the DNS services. Wolfgang and /SOERD /KAOS stack, and myself.

We provide a number of services, among them K‑root, we operate one of the 13 root servers on the Internet. We do reverse DNS for all the address space that is allocated out of RIPE NCC.

We provide secondary DNS services for some ccTLDs.

We also do the operations of the ENUM zone.

And we also operate an SA 112 node at AMS‑IX.

We are also involved in DNSSEC, DNS security. We sign all our forward and reverse zones.

And finally, we provide internal services for the RIPE NCC. We manage the ripe.net zone and all its associated children.

A little bit about K‑root. Our operations are quite stable. We still have 17 instances. There has been no change since then, since the last RIPE meeting I mean.

We see peaks of up to about 25 thousand queries per second. This is not normal. The average is about 17 to 18,000, but we do sometimes get query storms and that's the peak that we see.

We are now providing IPv6 service from nine of our 17 instances, since RIPE 57 we have added London and raining /SREUBG. Rekvik sees something like maybe one query a second or something like that over IPv6, but hey, it's IPv6...

The total query rate over IPv6 is approximately 200 per second, and you can see that in this snapshot which is taken with DSC. This graph would also be available on the k.root.server.net site if you wanted to take a look.

We have several things planned for K‑root this year and next. We are in the process of replacing hardware at several of the instances as it reaches the end of its life. We also want to do IPv6 in two more instances, that's Tokyo and Poznan. Tokyo should be done very soon after RIPE 58. We are also in the process of promoting the instance in Frankfurt to that of global, so in other words, we will be we will be announcing our prefix globally.

We are also going to be doing a number of updates to the server operating system and we are also updating to NSD 3, because NSD 2 which we currently use is at the end of life now.

One of the other things is that we are going to expand K roots network. We are going to cooperate with AfriNIC and introduce more K‑root instances in their service region, which is Africa. We hope to get a memorandum of understanding signed between ourselves and AfriNIC very soon at their meeting in Cairo.

And the initial deployments are likely to be in Tanzania and Mozambique. Others are still under review.

And what we are trying to do with these deployments is keep the cost down. And so we are developing a different model of deployment. We are calling it K‑root light and the idea is to make it affordable for our hosts in Africa to be able to operate an instance of K‑root.

Our other service, reverse DNS: All our servers combined see a total query rate of about 50,000 per second. One of our servers, ns.ripe.net which does secondary service for several /16 and IPv4 and IPv6 zones is now a cluster. It's doing load balancing and that makes it more resilient and internally we are working on a new provisioning system. This is to convert domain objects in the RIPE database into actual DNS delegation. Our current software is a little bit old and has a few, well features missing which we'd like to add, so we are working on that.

One of the issues I'd like to bring up in this presentation is that of child zone delegations in reverse DNS. The RIPE database at the moment allows creation of /24 domain objects even when the parent /16 object exists. And what the provisioning system does is that it ignores these /24 domain objects because the DNS doesn't allow us to delegate /24 if we are already delegating at the /16 boundary. Here is an example: If 192.94.in‑AD D R dot arpa is in the database we do this. In the existence of one below it, this would be completely ignored.

And this leads to some problems. We get questions from DNS operators. Yes, but I create add domain object and why isn't my delegation working?

There is also sometimes questions from end users, they say, yeah, but the RIPE database doesn't quite agree with what we see in the DNS.

And there is stale data in the RIPE database. All these /24 domain objects which exist but are of no use perhaps besides for documentation purposes, many of them are actually not maintained because they have no operational impact and therefore, may be stale.

We'd like to propose a solution for this, is to tighten the RIPE database rules to disallow creation of /24 domain objects if the parent exists. And at some point in the future, inform maintainers of /24 domain objects and then actually delete them. The deletion would have no operational impact because these objects are completely ignored by the provisioning system. So there would be no change, no impact in the DNS. Just some numbers: At the moment there are 431 /16 domain objects, which have all these, which have unnecessary child objects. And there is a total of 15433 child objects which are ignored by the provisioning system and have no effect.

Moving on to DNSSEC. We track numbers of DS records in all the reverse zones and here you can see a graph of the numbers from RIPE 54 up to RIPE 58. As you can see, it's growing very slowly. So that means there is a few more DS records every time, at every new RIPE meeting. But it's still very small. We have approximately 400,000 NS sets and out of that we only have about just under 180 DS records.

Our DNSSEC plans for the future: We would like to review our current policies and procedures. We'd like to do that after RIPE 58. Our DNS signer is due for a replacement, both the hardware is going to reach the end of its life and we'd like to replace that, and the actual signing function, we use a software based sign at the moment and we'd like to improve upon that and replace it with possibly an HSM based solution.

Coming to ENUM: There is a separate presentation about this tomorrow, so I won't go into too many details there.

Operations are stable. There has been one new delegation since RIPE 57 and that's Taiwan. The zone has been signed since November 2007 and currently two of the delegations are secure.

The RIPE NCC also provides secondary service for some of the ccTLDs. We do this on a best effort basis. We don't charge for this. But of course, this puts us in the position of being at competition with some of our members. And so we have been phasing out the service especially for some of the large and well developed ccTLDs. We have had three iterations and we have phased 16 of the ccTLDs out.

Of the remaining ones, we have no plans, no planned iterations but we will phase them out as and when they mature and have the resources to operate their own services.

And then a quick word on DNSMON. This is not a service that we operate. This is operated by our colleagues in the information services but there have been some interesting enhancements.

DNSMON now has support for Anycast reporting. Unfortunately for you, this is currently only enabled for the root servers, so most of you will not be able to see this. Only the root servers are able to use and see this feature at the moment. There are two types of reports available in here. There is a report by root server instance and there is also a report that you can see by TTM probe, examples of these coming up:

Here is a graph of a per instance report. So on this graph, on the X axis you can see time. On the Y axis is an indication of the number of probes that see a particular instance of K‑root. So this gives you an idea of how many probes see a particular instance.

CHAIR: Could that probably be also mentioned in the NCC services Working Group for people interested?

SPEAKER: There will be more details about this.

CHAIR: /AO*EULT I'd like to ask you to skip this then, I am sorry.

SPEAKER: My presentation is actually done.

CHAIR: Fine. I guess we have time for one or two questions.

AUDIENCE SPEAKER: Wilfred Vienna university and wearing two separate hats at the same time, one hat being local registry manager and the other one being the database Working Group chair around I'd like to follow up on this set of slides regarding the overhaul of the provisioning mechanisms. Because I think there are quite a few rough edges in different places. And I'd really like to get first of all, to get the problem statement or the draft solution proposal or whatever it looks like, also distributed to the database Working Group as you were talking about changes to the object syntax, which I am not really conveyanced that it's going to be a syntax change, it's probably a change of internal consistency double checks or whatever, but still, I'd really would ask you here publicly sort of to share your information base and to share your plans and to share sort of your problem statement, because I do have a few items from my end and I think that could be very useful to actually enter on a more formal basis into this discussion and try to come up with a good solution.

SPEAKER: Indeed. We have no plans to make any changes before we consult with the community first.

CHAIR: Let me ‑‑ there is an action item hanging off the roof here on which will freed Anand, probably me as the chair to coordinate, sit together to get this sorted out and we won't sort this here now and here. The queues are close and George wanted to respond immediately to which will freed and then most is an ‑‑

AUDIENCE SPEAKER: George Michael skin from APNIC's. Sister RIR never tell each other what to do so please do not misunderstand me. I will try not to over reach but I wanted to observe that ARIN had a very strong in‑depth /*F depth discussion about the management input provisioning something they are reconsidering and it was observed that LACNIC have adopted modified EPP and that APNIC has adopted a rest mechanism using XML and I would plead with you in that sense on behalf of the members who have responsibilities in multiple regions to please think about member internal provisions systems and the likelihood that there is a separation between public representation, which is whois and management upload which is not the same thing and that you have an opportunity here to consider some convergence options. But I am not trying to tell you what to do. I am just observation discussions have gone on in other regions.

SPEAKER: Appreciate it.

CHAIR: You would probably be available to give some more detail input into this.

AUDIENCE SPEAKER: Mohsen Souissi. Very short question: The 180 DS records, is it an aggregate before v6 reverse?

SPEAKER: Yes.

AUDIENCE SPEAKER: Okay, so by curiosity, how much is the proportion of IPv6 in it just to know whether people care of a combination of v6 and DNSSEC that's explosive or just don't care.

SPEAKER: I wouldn't want to venture a guess because I don't know that off the top of my head but I am happy to tell you that later on.

CHAIR: You can follow up on the mailing list.

AUDIENCE SPEAKER: Sort of the invitation and sort of the plea for the community here, as soon as we go ahead with this sort of discussion, I would ask you really to review your expectations about any new version of this provisioning system. Because my feeling is that the machinery which is out there is slightly out of sync with the current operational practices, and we may be lacking one or two things which might be easy to bring in right from the beginning rather than to taking them on from the side.

CHAIR: Once again we have action item 58.1 to deal with this issue. We can figure out the wording later.

After consulting with Jim, would like to propose that we postpone the discussion on 57.1 to tomorrow's session. We are A) we have another report from you which we could steel sometime from and we have a TAR discussion anyway so somewhere in between we'll fit that and you are of course invited to be there again and with that I would like to end with apologies, I'd like to ask jar /PHEUR to give us the update on DNSSEC in ‑‑ and this will run into the coffee break.

SPEAKER: Hello everybody, I'll try to be as quick as possible. I'll give you a very brief overview of deployment of DNSSEC in C Z.

I will start with deployment schedule. DNSSEC was our 2008 project and we started in January and after some community comment period, we signed both our zones, ENUM zones and .cz zone and actual deployment into production was done in September 30, at the end of September.

Four slides about our DNSSEC solution. Slightly modified our registry to accept keys by creating a new primary object called KeySet, which is actually a container for a DNSKEY records and this new object can be attached to the domain. So we don't accept DNS records, we accept DNSKEY records. So we are not APP compliant, but we think that this is much better solution for us, because it's support sharing of keys between domains, which is used quite often in .cz and such a type of container also enables to have multiple keys,

Registration of such KeySet is free.

We didn't make any change in the zone generation, a period still, it's done each 30 minutes and these records are generated from the DNSKEY records using SHA‑1 algorithm.

Our DNSSEC keys, we have two: We have just recently where our own signing key because we are, half of the year after DNSKEY deployment. /*F /*F for signing we use DNSSEC sign zone tool. We face a huge increase in zone size from 40 mb to 180. And because we are transferring zone to 19 secondary locations, we had to find some solution together where a memory bandwidth problems. So we created some scripts for requeuesing signatures during the signing process and right now we don't have any problems with size of our zone.

We use incremental transfer of course.

We wanted to use HSM machine but there was some problems with sign zone tool which we tried to resolve with coordination with ISC.

Currently, we offer four ways of publishing of our public keys. We have public keys on our pages, sign net SBGP keys. We have mailing list where where he notify about changes in our keys. And of course, we put our keys in DLV registry and ITAR.

Right now we are six months in production and we have almost 800 signed domains. Distributed among 10 registrars, but actually just two of them offer a bigger support for DNSSEC, and what's interesting is that all of these domains from these two registrars share 1 key.

Also, several, but not too much ISPs enabled validation on their resolvers.

You can see that number of signed domains is growing quite smoothly.

What we are doing now is, we are trying to do some evangilisation about DNSSEC so we chose some important domains and tried to contact them and explained what DNSSEC case and trying to convince them to sign their domains. We had a few successes like some portals, IT portals and our biggest online bookstore. What's going to be promising, one government department, one bank, maybe our presidency domain we hope will be signed before our presidency will expire, which is soon. But we also have some failures. We are trying to convince Google to sign its domain. But we have got a response that there are some technical problems and I think it's a pity because a lot of portals in our country do what Google does, so...

Hopefully it will change.

We also, the second project for 2008 was some sort of academy, which is training centre for about 20 people, and we made DNS and DNSSEC courses which will allow about 70 people coming from our association members, registrars, ISPs, come governmental stuff, now we are opening it to the public.

We created DNSSEC home page with DNSSEC set up wizard, what to do, how to sign zone, how to set up resolvers to do validation, and on the web page, there is also a simple check whether you are local resolver enables the initial validation, which looks like this. On the right side there is a red key if your resolver doesn't support validation and a green key if it's supports validation. Interestingly, this snapshot, our screen shot was done about an hour ago, in grand ballroom, so it looks like local DNS resolvers doesn't support DNSSEC validation, so this is probably where we can start.

So this is all.

CHAIR: Thank you. Questions. One or two. Jim are you...

AUDIENCE SPEAKER: Yes, I have a question. Jim Reid. Again I think you have done some great work. The training material and other things you are talking about, are those documents in English or in check or would this be made available if they were in English to a wider audience than just people in the Czech Republic who were doing DNSSEC.

SPEAKER: If you mean the work on ‑‑

AUDIENCE SPEAKER: I was talking about your training courses and other material like that.

SPEAKER: Our training course /R‑S for local people, they are in check and also until now all material is in cheque, but it's not (Czech) it's possible to make a translation and we already prepare some documents about our success. And re wants something to add.

AUDIENCE SPEAKER: And re /SWAOES. I am the one doing the courses /‑RBGTS I have no problem in doing them in English as well, but right now all material is only in /KH‑Z.

AUDIENCE SPEAKER: Okay. Thank you.

AUDIENCE SPEAKER: Lars Forsberg, loop yeah. What's the basic response from your registrars? What problems do they have with DNSSEC mostly?

SPEAKER: Well, we don't face any large problems. We had some problems that probably in one case the registrar published a DNSKEY into .cz but forgot to sign his zone, so the domain was unaccessible, but generally, there are no problems. They just have to update their systems to accept this key and to probably just take sometime.

AUDIENCE SPEAKER: Okay. One further question: Do your registrars have any problems with the main names moving between registrars, one supporting DNSSEC and the new one does not?

SPEAKER: Well, until now, I think they didn't have any problems because there are some situations where domain is transferred and DNS keys stay the same. So, I think if they support DNSSEC, they already solve this.

AUDIENCE SPEAKER: Okay. Thank you.

CHAIR: One last sentence.

AUDIENCE SPEAKER: It's just a comment. That we also face some problem that some registrars are also DNS hosting providers then they do have any DNSSEC demons, they have sometimes problem they need to switch the platform. That's one thing.

Regarding the transfer, we have separate objects for keys and for domains, they can transfer domains without transferring the key so they can keep the DNSSEC records by the old registrars.

CHAIR: Okay. Thank you: Thanks everyone for your patients. Thanks to your on line scribes and the minute takers, for your support staff. See you tomorrow morning, nine o'clock, hopefully unless you enjoy too much of the AMS‑IX party tonight. Thank you.

See you tomorrow.