The session commenced on the 28th October 2008, at 2 p.m. (local time).
CHAIRMAN: Good afternoon everybody. Before we get started ?? can I have your attention please? Thank you. We are going to be a couple of minutes late starting the working group because of some audio visual problems. As you can hear, I don't have a microphone. The microphones don't work.
We have two audio visual problems. The first one is the microphones aren't working so people at the pack of the room are trying to figure out what's gone wrong and reboot whatever needs to be rebooted. And the second problem is we don't have a video signal going from the laptop to the projector in the room. So until we can get these problems resolved we are not going to be starting the working group and I apologise to those in the room who rushed from their coffee breaks and lunch to be here and also to the people out there in web land, especially those who got up extra specially early to /TH?RPBG to follow the series. You have probably enough time to go and grab yourself another cup of coffee before we get things going. So apologies and I'll get things going as soon as possible.
CHAIRMAN: Now, we have sound, all we need now is pictures.
Well, I am glad to say we have resolved the audio problems and the video problems so I hope you can all hear me. Thank you.
Welcome to the first session of the DNS working group at RIPE 57 in Dubai and a special hole owe to all those out in web land who are following proceedings.
Before we get started I want to make one or two obvious announcements. First of all please switch your phones to silent mode. Mobiles to stun and if you are going to use the microphones, to make comments, could you please say who you are and who you represent before you actually ask your question or make your comment. This is primarily for the benefit of the people out there in web land and also for the minute takers and the stenographers who are trying to capture a record of what's actually being said and what's actually taking place.
I am happy to say that an afill camp is going taking the Minutes this time around. Adrian Beford isn't here in Dubai who normally does this job. So thank you to Arnold for doing the minutes of the mark has kindly volunteered to monitor the Jabber room and let us know of any comments of people who are jabbering as we follow proceedings.
Without any further ado I think we are ready just to get going and the first thing up there is a review of the action items.
Now before we actually get on to that, one apology is the minutes of the last working group meeting. Your working group chair, that's my co?chairs, my accept, yap and Peter who are sitting next to me, we have all collectively dropped the balance on actually getting the working group minutes circulated. We do have a definitive set of minutes we think. We just didn't get them out to you on time. My apologies for that and we will circulate them as soon as possible, probably by the end of this session. If anyone has any specific comments on the working group minutes such as they are, or anything matters that arose from the last working group session, I suggest what you do is raise these under any other business on tomorrow's sessions once the minutes have been circulated and I hope you are happy to go along with that approach. Silence implies consent, so I guess you are.
Next thing up Peter's going to give a quick run through of the current status of all the open action items for the working group and get some feel about what we do next on that.
SPEAKER: So, good afternoon everyone. My name is Peter Koch I am one of the could he chairs of the DNS working group and I now drive you through the remaining observe action items and of course I am the stuckey because two are the three are on me. This time the dog didn't eat my homework. Actually the dog got killed, but we'll see a little progress at least on the oldest one of these which is 48.1. Can you read that in the back? So for those of you, on line the list of action items is available from the RIPE DNS working group. Home page. On the left side the /A*BS list and you can see exactly what's here on the screen. 48.1 was the description ?? I'll read it because some you might not be able to read it from the front.
"Collect experiences are lameness problems due to vanished customers or AXFR sources. Initiate document on best current practice and wish list to tore TLD and. This was a problem that was brought up bay colleague from MCI and the action item is that old that the company of named MCI at that time.
Who suffered from lame delegations to his name service and couldn't get rid of them because usually registries do not, do only talk to the registrar or maybe to the registrant but never to third parties when it comes to deleting domain registrations, which is usually a good thing.
So, there was little progress for quite sometime and it popped up over and over again but this time I can report a bit of progress. With the kind help of the centre secretariat and as most of you probably know. Centre the is Council of the European top level national domain registries, including some associate members from overseas, and the secretariats did a survey that I initiate today get this action item done. A couple of the C, TLDs responded and one obvious question in that survey was, okay, here is the problem description, people operating name service and they would like to have the delegation to their name server deleted, would you take to this operator? Most of them responded no, there is no way we can do that by our term policies.
Second question was has this problem ever occurred to you? And the overwhelming response was: No. So, it turns out that we might have a kind of a non problem hereof really not a perceived problem. There is also no or very little procedures in place within the registries right now to deal with it. During the research I could only get to one actual ccTLD registry that remotely had a service that would aim at this that was in South Africa, I guess. In South Africa for a co.za you can go to a website, name your name service name and initiate a list of the delegations being sent to you on some or another way.
So, from the real world perspective, this seems to be a non issue mostly. What remains on me is to write a short summary of this centre survey for reasons of nondisclosure, the survey can't be made public completely in its rough form but a survey was actually ?? a summary was actually asked for and agreed upon by the participating parties. So that will be sent to the RIPE DNS working group list. My proposal would be to close that action item because experience shows that the problem does not appear in practice or at least appears in a far lesser way than we perceived it when the action item was accepted. And my proposal would then be to close the action item after the report has been sent to the mailing list.
I'd appreciate any comments on that, any objections, support, new thoughts, anyone not sleeping? And that was yes to which question?
So that's probably mostly done.
The next one ?? we had a fairly long discussion about the document on name server migration and changing delegations on the side of operators. The conclusion last time was that yeah, there were different topics popping up and people in the room agreed that it might be useful to come up with a document, mixing, or I should say, coordinating and compiling the different view angles. A number of volunteers showed up or people were volunteered by I guess Jim. In essence, there was no progress made. So our conclusion was, so far, that if there is lack of interest, we should probably declare this item dead as well.
Any objections to that? Anyone ?? would anyone like to continue working on this document?
AUDIENCE SPEAKER: I remember I sent some comments to the last version which was submitted on the mailing list, and I hope there will be an update just to be shared ?? whether the document is validated or not by the working group recollect I think it is useful. At least for the energy which has been put in it, I think it's useful to be shared.
Jim: Thank you Mosan for those comments. My recollection of what was discussed in RIPE 56 was that there was a suggestion of meriting this particular action point with the other action point about the reverse delegation stuff and various people suggested the two things could be combined into a single document. Nobody has come forward to either pick up that work or do anything with it so I think we can reasonably say there is not much in the way of interest from the working group in taking this any much further. But what I will do is, go back, take your comments and incorporate them into the master copy of that document and circulate it and publish it to the mailing list. Mosan, be careful what you stay for the night because you might become a stuckey for an action item here.
AUDIENCE SPEAKER: No, if there is no interest in working further on the combined document, I believe, for myself, the first document which others only one thing is okay and I think with those comments integrate it had may be shared as is. That's my comment and I am not asking for further actions on my back.
SPEAKER: Okay. So I received different signals now. Quite seriously, we have been keeping this alive for probably ?? well a handful of years now. Every now and then people agree that this is a useful thing to have, but then we can't reach consensus on the text. Every other meeting we get a new group of volunteers to work on this and we all have our time commitments, we all think, or most of us think this is something to usefully work on, but we can't, somehow can't meet the milestone and can't fulfil the action item. So, I have a different proposal, and let me hear what you think about that.
I'd like to propose we declare this effort closed. If somebody really thinks, and there is no pressure on this and I think if somebody really thinks the current text with some modifications is ready for publication, I I suggest they gather some people together to form an editing team, do the necessary work there and then come back to the working group with an overhauled document, and we can start from there. Other than that, me personally doesn't see any benefit in carrying this on over and over again and I apologise for being less diplomatic than I should be. Comments on that? Daniel? Okay. So...
So we declare this dead and done. Thank you.
It's okay that I only have a minute left for the last one because ?? all my attention was drawn to by the other document of course. So, unfortunately again the document here is still living. No progress since last meeting. I'll leave it up to the working group to declare this dead since I am the stuckey here, I won't make any proposal. I think it's still useful to do. We had a draft out that was commented on and all that is, that needs to be done here is incorporate the comments. So, you can either relieve me here ?? no, I am not asking for that ?? for bookkeeping reasons I am declaring this done or keep this open and Jim and yap will bash me to get this done before the next meeting. That's up to the working group.
Jim: Okay. Thank you Peter. There were various feelings about what we should do with this particular action item? Should we leave it on for another working group meeting and make a decision at the end of it to kill it or do we kill it now? Does anybody care?
What I suggest then is that since there is, there have been one or two comments that Peter has still to incorporate into the draft document, I am going to volunteer Peter for some work and so, if Peter would be so good as to incorporate those comments into the last draft of the document, circulate it on the mailing list and then hopefully have a final resolution of this action item at the next RIPE meeting. I think that probably is the reasonable way forward and I hope I can count on your support for that position.
Silence implies consent. So speak up if you strongly disagree with this approach or even mildly disagree with it. Okay. Thank you for that.
Our next item on the agenda is Kim Davis from IANA who is going to have an update on IANA's work on various matters including the Trust Anchor Repository. I'd ask you to try and listen to some things and save some of your questions which might be more appropriate we have discussions about the NTIA, that he is nab an appropriate forum four general discussion. If you have got specific questions to Kim, by all means make them from the floor.
SPEAKER: So, I was asked to come primarily to speak about the interim Trust Anchor Repository that we have been working on. That's directly an outcome of this working group I believe at the last RIPE meeting. But also touch on some other things we are doing at ICANN and IANA, and I won't talk too much about the DNS sec proposal because I know that's coming up further in the agenda, but I certainly entertain any questions that you have.
The first thing I want to talk about the interim Trust Anchor Repository. I think what was discussed at RIPE was just called a Trust Anchor Repository. We felt it was quite important to highlight that it's interim. We didn't want any misconceptions that this service would be existing eternaley. It's definitely an interim measure, so that was added. It also makes for a cheeky acronym for those that are following things.
So what is the interim Trust Anchor Repository? Well, it's a mechanism to publish the keys or the trust anchors for the top level domains that currently implement DNS sec. If the route zone is signed this wouldn't be necessary, but as we all know the DNS route zone is not signed. So, this is considered (zone) a useful measure for those that wish to experiment or deploy at some level DNS secretary to get access to those top level domain keys without having the route zone signed.
As it's lonely designed to be in existence until the route is signed, it's definitely a stopgap measure and our aim is to demission the service once the route is signed. (DNS sec) just a quick primer on how DNS sec is meant to work and how it works with a Trust Anchor Repository. If you have an unbroken chain of trust down from the route, if you wish to validate a domain such as this one here, you can validate it up through the chain right up to the route and to validate this all you need is the trust anchor for the truth itself. So the computer performing this validation just needs needs to have the trust anger for the route zone. Doesn't need the trust anchor for the subsidiary zones below that.
That's not what we have. As you know the route zone is not signed. We can't form that end to end validation from the route down. Effectively what we have is a situation where to validate some these domains you need the trust anchor for the top level domain and the way the that would populate those is the provide a list of all those trust anchors and implement that in client computers.
So RIPE came up with a number of recommendations that were transmitted to ICANN in terms of implementing a Trust Anchor Repository. I believe in that implementation will meet every single one of those. None of those was we didn't agree with, it was all very common sense, so we have developed this system in mind to implement all of RIPE's recommendations.
We support the different keys that we know about. We are certainly trying to make the system as extensible as possible so it can be developed with any future requirements.
The Trust Anchor Repository has a few publication form as that were launched on day one. If there is a need to deploy additional publication form as we can certainly do that. I think it's relatively easy to add additional form as. Initially we will just provide firstly a website list so you can go to the website, you can browse all the trust anchors in the repository. Secondly thereto XML format so it's easily machine readable. Those that wish to venture into writing software to implement that can do so. Thirdly there will ab master file format, something that be quite easily imported into domain name software.
Like I said the form as are plain text, readable. Implementers can use those form as in their software as they desire F there is some other format that would be useful, we can /EUFRPL implement. Our aim is not to have implementers form /K*US anchor tools that use this data. Really, we development want this kind of solution to be built into the systems worldwide on an ongoing basis. It really is an interim solution that should go away and having software relying on it existing is a bit concerning to us.
So the acceptance model. How do we get those trust anchors actually into the repository? TLD operators who we already have an existing relationship with will submit the DNS key to us via a new web form. We will take those keys, we'll validate them against DNS key data in the DNS. We'll make sure that the DS key matches the DNS key data prior to publication. Does it need to be in a DNS at the time that the form is submitted but it won't be listed until it's visible in the DNS.
And the way that we verify that a submitted trust anchor is appropriate and agreed upon by the TLD is we ask the administrative and technical contacts for that domain to approve T we won't list a key until both of those authorise the listing. (TLD) the revocation (TLD) we would ask the administrative and technical contacts to athat they want that key revoked.
We provide a field for reason, it's optional but if the TLD that's revoking a key which is to put some kind of memo as to why it's being revoked, they can do so there.
We will provide a list of not only the active trust anchors but the aspired trust anchors and the revoked trust anchors.
So give a demo at this particular juncture but the system is not fully deployed. It will be next week and I have a little trouble getting to our development server from the network here.
Instead I have got some representative screen shops which capture almost all of the functionality.
Firstly, when you go to it it presents you with a different file form as you can download it. Those of you with you add to trust anchor, the links there. It's all relatively straightforward. It's not a complicated registry by any means.
I think a trust anchor relatively simple as well. I won't go through the details.
It's in the slides and I am happy to take questions. You can view the list on website, but this is predominantly not the way people will use the Trust Anchor Repository. This is just there for browsing purposes. Primarily the key form as getting a faster file format or an XML format of the Trust Anchor Repository.
So the availability: This will be open to top level domain operators this week. We are just in the final stages of launching the deployment of this service. /S?L certainly be ready in time for the ICANN meeting next week and what we'll do then is ask top level domain operators play with the system, submit their keys, perhaps their revoke their keys and then once they have played with that we will reset the system down to production data and then implement any recommendations we receive from the top level domain operators. Once that's done, we will make it public.
So the next topic I am being told to hurry on ?? joined root zone. ICANN's strategic plan here sob operationly ready. We have been /SAOEUPG a root test bed for over a year. We have built the system with advice from many different DNS sec operators. Other experts in the field. In fact we already signed the eleven test top level domains in the root today with DNS sec.
I'll skip this slide. It's in the next presentation. But, as you know, there is a call for comments to the US Government about signing the root zone.
Next topic: Internationalised country /TK* we have country code top level domains, they are derived from the ISS 3166 standard, they are two letter codes. This is good for us. We have a very simple standard, very easy for us to implement to work out what's a country, what's not a country. But it's not so useful for people that don't use Latin scripts. There is definitely a demand out there are to internationalised country code. Those not written in Latin scripts and the /THAEFRT we are working on now is to try and implement those.
Unfortunately there is no equivalent of ISO 3144 in other scripts. We don't have an international standard we can point to for the names of countries in other scripts. Another problem we have is the formal policy development process within ICANN would be very slow. Will take several years. And the third problem that we face is that because there is such a demand for these kind of domains, we are seeing different solutions implemented in different countries that aren't universally available. So we want to avoid this kind of fragmentation of the DNS.
Our solution tost to implement a Fastrack where countries with a definite demand for these kind of domains can apply for internationalised country codes. The country must exist in the ISO standard but not necessarily the name. They must show that they have a need for this kind of domain. It must be a representation of the country in one of the official languages of that country and it must be a non contentious proposal. We will basically follow the same procedure for country code domains we have today inasmuch as the string selection, the choice of the label will be different but everything will be the same otherwise.
So the way it's being rolled out is we have released a draft implementation plan this week for comment. We have contacted governments, Curran utility operators and asking them if they will applying the Fastrack and ultimately the ICANN board will be approving this process at some point, presumably.
Finally just very quickly, generic top level domains. Historically, during a/TPHAPB's existence there is two rounds of adding top level domains, there is 2000 round which added top level domains. 2004 there was sponsored top level domains,. Both of these events have had the character that they are one?off events. They have never been repeated. What we are moving forward to now is a system where there will be sort of a perennial application where an ongoing system allowing applications move into the future where you won't have single one?off events but an ongoing process for applying for new gTLDs.
The aim therefore is to make the rules clear, acceptance criteria clear right from the very beginning. So there is no real surprises at the end when the board of ICANN either approves or rejects a request.
So, the time line for that, basically it's over the next year. There is a draft RFP available now. The final RFP will come out early next year and initial applications will be allowed later next year.
So that's it. That's my summary.
CHAIRMAN: Are there any questions for Kim?
AUDIENCE SPEAKER: Peter, you're /OT registry, maybe you said this but I stepped out for a second so maybe you'll have to repeat yourself for my sake. About the ccTLDs and the extensions in the other languages, would that be just one that a country has to pick or what would the Fastrack actually entail? I am specifically referring to .eu which we would have in 23 official languages of the European Union and even then I mean, would it be just an association of a full name or what would be possible?
SPEAKER: I think the proposal right now, and I am feeling a bit rusty, I think it will allow for any official languages in the country, so there can are more than one from a particular country if it's official. And the key one here is India where there is no pro dominant one.
AUDIENCE SPEAKER: It can the full name.
SPEAKER: No, it can be abbreviations.
AUDIENCE SPEAKER: Full name is possible as well.
AUDIENCE SPEAKER: This is still all in draft form.
SPEAKER: With the caveat that this is that draft implementation proposal. It hasn't been agreed by the ICANN board, some languages, I think Arabic is one, there is no logical abbreviation, so it must allow full names. At the same time, it other languages in other scripts, abbreviations make sense. There needs to be a logical abbreviation of the domain. There is a whole string selection sort of pathway to choosing these that annum can't needs to put in a proposal that needs to be approved by linguistic experts to make sure it matches some reasonable resemblance of the country name that the detailed in the plan.
AUDIENCE SPEAKER: Barbara Roseman, the phrase that's used in the current documentation is a meaningful representation of the country or territory involved, and so we have set up a whole structure for how people can evaluate before they submit it to us whether what they are proposing is a meaningful representation of their country name in the other language. This, as Kim says, this is to accommodate the fact that there is no ISO 3166 recognised list of IDNs and we are trying to ensure the greatest flexibility here without you know imposing severe restrictions while at the same time making sure that there is little conflict or overlap with other countries that might share similar designations.
AUDIENCE SPEAKER: Second part ?? a.m. I still allowed to speak? Second part of my question then? Will that be the same zone or will that be different zones which is important to a registry?
SPEAKER: They can be both. Floss natural tie between the CCT utility operator today and any new ccTLDs. There could be, let's take Belgium as an example F you met the same guidelines for a Belgium written in another script, in your community and your Government approved and your local Internet community agreed that DNS B should run that new domain, you can run is as well and you can run it as the same zone as .be. That's really your decision. Equally in a country that might decide this new ccTLD should go to a different entity and have different eligibility rules. That's an incountry decision.
AUDIENCE SPEAKER: Just for my better understanding, dot Belgique, which is French for Belgium, would be allowed? But even it is a Latin one.
AUDIENCE SPEAKER: These are intended for not Latin scripts.
AUDIENCE SPEAKER: But general bell gee, which is the Dutch version which umlaut on the E would be allowed?
AUDIENCE SPEAKER: Possibly. To be honest, I just don't know.
SPEAKER: That's explicitly ruled out for the Fastrack. The Fastrack is just countries that have problems using Latin letters which I don't think you can argue for. But ultimately there will be a proper ccTLD policy for these, the non Fastrack but their PDP policy which could very well have those available.
AUDIENCE SPEAKER: Question from the Jabber room. When can I download the keys for my resolve a.
SPEAKER: That will depend on the response from TLD operators in the first few weeks, but I fully expect that will be fully public within a few weeks. That's my personal view. Whether there is some last minute political hurdles to getting new I NS services deployed is another question. But we are ready to put into test and give it to TLD operators to submit their keys this week and once any issues are settled and we are satisfied it works, then we'll make it public. That's the plan.
CHAIRMAN: Thank you very much, Kim. Sorry.
AUDIENCE SPEAKER: Last question. I just did the guideline for the ?? and I is that you it says that it's not possible to have a confusingly similar character in the top level that, that want to put in their root service. The point for example, for Iran, we have a character in the top level that confusingly similar within the script with the other character. So what happens to that name? I just want to make sure that we don't have any problem later than you propose.
SPEAKER: The confusingly same means if someone else registered a domain that had that character swapped with the one that's easily confusable that, wouldn't be allowed to be registered, sort of like first come first searched and then future applications couldn't apply for ?? I mean it's kind of like someone, just to use as key example. We have dotcom right now and confusingly similar might be dot CON for example. So that's the kind of confusingly similar in that it will disaplough registrations that map very closely to existing TLDs.
AUDIENCE SPEAKER: Thank you.
CHAIRMAN: Any more questions? Thank you very much Kim.
(Applause)
Next item on the agenda is a discussion of the NTIA notice of intent about proposals for signing (NTIA) signing the route zone.
Now, I think we have a duty to respond to that as the DNS working group as I think since personally we have had (NTIA) a fair degree of influence in allowing this thing to happen by coming out with a signed statement back to ICANN back in the meeting and then following up with the some work of recommendations, suggestions about what should be the characteristics and attributes of a trust eye /KAEU repository. I would very much like this community could come out with some kind of statement which offers some kind of support to what the NTI is proposing. My personal opinion is it's likely to be something on the lines of we welcome this fact that we can consult, you are consulting the community on this and we look forward ?? a part of a progress towards getting the root signed. Whether we can actually reach consensus on any one of the proposals that the NTIS puts up for suggestion is an entirely different matter. If we can do that, great. Although my personal take is we probably can't do that and certainly not in the time that's available to us. However that doesn't mean to say we shouldn't try.
Now, before we start the suggestion, I have taken the liberty of asking Jacob to give us a very quick overview of the six proposals that NTI has put forward just so that he can put discussion in some kind of context and we understand what it is we are talking about since I suspect some of us have not yet had a chance to fully read and digest the NTI proposals. So I am going to hand over to Jacob to do a quick five minute overview and then open the floor for discussion.
(NTI is NTI)
SPEAKER: This is just a short summary to actually of the two proposals, or actually six, but these are the two main proposals. From VERISIGN and ICANN.
(V E RIS I G N)
So, executive summary eye van versus VERISIGN, it is not a staple, /STA* statement, it's just a summary. The two proposals have a couple of similarities and a couple of differences.
What is similar is that the root zone maintainer, the one that actually compiles the is one that signs the zone and that entity is also the one who can create and use the zone signing key.
The main differences here is of course who is the root zone maintainers? And who should control the key signing key?
So, background: You all know this, a couple of definitions, TLD manager, zone authenticate err, current zone editor and compiler, we don't just have a zone signer of course and we have a zone auditor, which is the US Department of Commerce. I'll get back to that.
So, the current process which you are aware of is that the TLD manager submits the request to ICANN. ICANN processes the change request. Sends the request further on to the US Department of Commerce and VERISIGN. After authorisation and out it goes.
If we are looking at the key signing key usage and control. ICANN suggests that a couple of parties, or defined by the community, will participate in what you call a key ceremony. At that ceremony, the key will be generated and published. The key signing key will be stored in a HSM CRYPT module at ICANN, but the expect use of that key during operations is yet to be defined by the community.
Versus see sign, on the other hand, has been a little bit more specific in the proposal suggesting that the roots server operators participates in the key signing generation and publication. They define and N of M mechanism to be the root server operators to be able to have shared control of the key signing key and that they gather at least M of N there is something like 5 out of 13 or 12, once a year to actually sign the keys for the following year.
Look at the signing: Everything is, works as today with the submission and authorisation by the US Department of Commerce. The difference here is that in the ICANN proposal, ICANN edits and signs the zone file and then transfers the signed zone data to VERISIGN for publication. Whereas ?? this is just a simple diagram for your reference. Whereas VERISIGN will take the unsigned zone file from ICANN and edit it, sign it and off it goes. It's just a matter of where the signing is taking place.
So, the next step, as Jim said, the US Department of Commerce and NTIA has issued a Notice of Inquiry. They want comments to this e?mail address. The comments are due on the 24 November and the comments are posted on this web page.
Important here is to that you as the community send comments. It's not only for US citizens, it's you're, we immediate the comments the without the comment, I'm not sure how they will continue.
Thank you.
CHAIRMAN: Okay then. Just one other comment I would make, again speaking in a personal capacity is I want to reinforce this, that the fact that the NTIA is having this public consultation is something that I think we should all welcome and I think we all have a duty one way or another to respond either as a community or as individuals representing companies or organisations, have got some kind of involvement in in domain name system. I think if there is not broad community support for E signing proposal, the chances are the NTIA may say this whole thing is not worth worrying about, let's just leave it alone and there may also be dissenting voices from people who are not very keen for whatever reason to go ahead with signing the root for perhaps political problems or political issues rather than technical ones and again, if there is ?? if there doesn't appear to be a strong consensus around this particular proposals, the chances are we might not be able to get DNS sec signed for sometime because then the political problems could take a long time to resolve.
So, I would urge you all to think very carefully about responding to this document but now, please have your comments from the floor about what you think about the pro proposals that are being put forward or any other comments in general and also if you think this working group should make some kind of response.
AUDIENCE SPEAKER: Olaf, wearing a confusing number of hats on this issue. But now, speaking on a personal title, you seem to suggest that there is a choice only between these two proposals. There are a number of other proposals and I'd like to clarify that NTIA specifically also asks back other options to the table. So, I don't know if you want to limit this as chair, but the proposal is, the request is much wiser.
CHAIRMAN: No, absolutely not. This is for this working group to decide what they want to discuss here. Absolutely not. I mean, I think we probably have essentially broadly speaking two proposals that are the most likely candidates to choose from, but that certainly should not preclude the other four.
AUDIENCE SPEAKER: /HRARSly man. And to reinforce what Olaf said recollect it's not the other four. It's the rest of the possible alternatives of which four are listed on the web page.
CHAIRMAN: Indeed, yes.
AUDIENCE SPEAKER: But that was not my comment, my comment was really that I think it would be good with the statement from this working group, I do not expect this working group to be able to converge towards any alternative be that listed or not, but I think that there are a couple of things regarding the process that one could reinforce such as again, stating the importance having of root signed. Possibly conveying a message that there may be differences of opinion on exactly which way to go, but that speed may be more important than the actual result. Maybe stress that selecting a solution soon is important if ?? and you can add to that ?? how shall I put it? Stress that a system doesn't have to be cast in stone. If you write your agreements the right way, you can open up for changes to the system in the future. So, having it signed soon is more important than having it signed by exactly the appropriate process from day one, get something going early is my message. But if the work can group can't agree on that, so be it.
So, in the discussion, let's look for things that we can agree on rather than dividing into various ??
AUDIENCE SPEAKER: Daniel ?? I agree withly man and I'd like to rephrase it a make a little bit more clear what we should be doing. I think we shouldn't fall into the trap of discussing concrete proposals because we cannot ?? I don't see that we can agree and we should agree and back a specific proposals. So the process should rather be to list properties of a solution that we would like to see. Like we have done before. Like we have done with the Trust Anchor Repository. Like we have done with get the root signed kind of things.
We should try to see what kind of properties of a proposal ?? of an implementation we want to see.
I'd like to offer a view, sincely man already offered a view. One is timely but not hastily, so we want to see something happen quickly. We already said that, so you know we would be inconsistent if we wouldn't repeat that.
The other is, thatly man said that I agree with is like, not inflexible, changeable, do not cast things in stone, do not go somewhere where it will be difficult to change things. Because we might not have the good optimal solution in the beginning.
And the one I would like to add, which is almost like a broken record when talking to NTIA, is one to be acceptable to the (NTIA) international community, to other nation states, because ?? not because we do not like the US politics or the intention of the US Government ?? we question the intention of the US Government, but we want to see it succeed. So if there is any geopolitical contention, it will not serve our purpose of getting the thing through. And then we can think about other things.
CHAIRMAN: Thank you Daniel. Mark, you have got some comments from Jabber land.
AUDIENCE SPEAKER: One question from will you tell us done hack: Is the KSK possession the real problem? I do fear mortgage operators would have added ZSK which would be able to disturb the root zone contact any time.
CHAIRMAN: This again takes us back ?? to answer the question, this starts to have discussion about the implementations and strategies for that which is perhaps not what I think we really can realistically discuss here. Yes, there are potential concerns about who has the key and what they can do with it, but then let's be reminded if we are talking about changes to the root zone, broadly speaking the actors that could be involved in signing are already involved in some way another in changes that are made to the root zone either by doing the editing of the root zone, or by having some kind of approval or check over the changes that are made. So, yes we can recognise that there are potential issues about who has the key signing key and the zone signing key and how they are used. But I think we are to back up a little bit from that and look more at the broader issue here as Daniel Leeman had said. If we start going down this whole line of discusses where proposal one is better than proposal two or there are aspects of proposal three that could be met with proposal four to come up with proposal seven that is slightly better than proposal circumstances we'll be here forever. I think we can't realistically go down that path. The clock is ticking. We have got over three weeks to get a response to NTIA if that's what we want to do. I think we should try and concentrate on a higher level along the lines of whatly man and Daniel from saying, I'd like to get a feeling from the working group if you agree that's the kind of approach we should take or do you want to have a discussion or argument about the fine points of each of the discussions put forward. Any comments on that?
How many people have read the proposals? (NTIA is NTIA) the proposals total. All six, of course?
AUDIENCE SPEAKER: The NOI does not call?out proposals, they have six process flows. I think it's a mistake to talk about proposals. I'll leave it to others to decide about whether they want to get into those particular process flows. But, the NOI is structured to have 13, maybe it's 15 questions which appears to be what they want answered. I am curious whether this group sees it as useful to answer those questions or to, instead, deal with the broader picture?
CHAIRMAN: Okay. Demitri.
AUDIENCE SPEAKER: But he is still with his own head. I want to slightly enforce what Daniel said, but for me, Jim, sorry, I have spent only one minute not on technical issues, exactly on political, because the logic of all events during the last few months starting when in Paris, I can raise strategic strategy issues regarding IANA contract with a signed contract, in one month we have a response that says don't plan, I don't want to discuss all these issues. Now, yes, it's some gift to technical communities that they are not discuss the at this level and discuss the signing but it's unilateral action of one Government. And all other ten years discussion on Internet governers as a whole is now broken. Sorry, I gist want to mark this point. Thank you.
AUDIENCE SPEAKER: Mosan ?? I am speaking for my person as a European citizen. If /*U asked me whether I drink red wine or white wine, I would answer none. And I would prefer you ask me: What drink I would prefer? In that case I would think about it and maybe I would say water or soft drink or whatever. So I fully support the idea of not answering those questions and just speaking on our service what the properties of the roots signature infrastructure we do want. And by the way, if we answer directly, that may be a trap of endorsing directly the political process at layer 9 and I don't want the RIPE community to be really involved in that unless we have a common consensus on an alternative political process that's completely beyond this forum, I think.
CHAIRMAN: That's a very valid and and again I make a point here not as either a working group coach or as somebody who is chairing this particular session but faking off all my hats, I think we want to try and steer away from the politics as much as we possibly can and if we try to go down that path. We could try and solve world hunger and world peace while we are at it and we'd probably take just as long. I think we try and do something that is fairly simple along the lines that Daniel Leeman have proposed and I hope there is a sentiment within the working group for that and I'd still like to hear more voices either for support for that position or against it. Does anyone feel strongly that this is a good approach or a bad approach to take?
AUDIENCE SPEAKER: Shane ?? I think it is it's a good approach to come up with a list of attributes and just present those.
CHAIRMAN: Thank you. Any other views? Nobody.
Okay. Well, what I think we should try to do here rather than do wordsmithing by working group meeting or by sort of a committee, it doesn't tend to work that well. Could I ask for two or three volunteers, in fact maybe I'll just volunteer a couple of people, who could help us draft a short statement similar to the kind of efforts we have done in the past for the Trust Anchor Repository and for signing the root. We'll try on work that sometime later today and then we'll come back to the working group tomorrow with some form of words which we think expresses a reasonable view that the community can support about the attributes that we think a signing process should have, without going into the specifics of any of them and then have that endorsed and hopefully sent on to acan as if you like, a community statement a the NOI from NTIA F people feel that pea want to answer particular questions directly themselves, they are happy to do that either in their own personal capacity or the capacity of their employer or the organisation they do. Perhaps the statement from the RIPE community is just a general endorsement of support in some broad sense for what the NTIA is proposing. Does that sound like a reasonable thing to do. Again, silence implies consent.
AUDIENCE SPEAKER: Patrick ?? if it is the case that they want to create this list tomorrow morning, in that case I am happy to help writing that, because I am already doing it for other reasons.
CHAIRMAN: Thank you Patrick. I was also going to suggest thatly man and Daniel, myself and maybe Peter could help in drafting some little piece of text on that, does that sound like a reasonable group of volunteers or stuckeys. Would anybody else like to join this effort or oppose the myself appointed list? It Jew aare you opposing or volunteering?
AUDIENCE SPEAKER: Volunteering.
CHAIRMAN: For the benefits of the minutes, Jew awe, Daniel,ly man myself, Patrick and Peter will get together, thrash out some form of words. We'll circulate it to the list and also have a little bit of discussion about it in the agenda tomorrow, with a view to try to have some sort of community endorsement of a statement that could go to NTIA. If we can get (NTIA) I have suggest that we'll do is put that on the mailing list for further comment and give people let's say a week or two weeks to consider that and then have it go as a statement from this working group. Daniel is coming up to make some wise words.
AUDIENCE SPEAKER: I don't resent being volunteered. I'd like to make a full disclosure before we get into the agreement of the working group here is that I also wear other hats. And the RIPE NCC also wears a hat as a operator here which I think that everybody knows. But I am also the Chairman of the board of trustees of the Internet society who is also going to be comment on this, use ago totally different process and while I don't expect that they make a different statement, or conflicting statement, I want to make a full disclosure that I am going to be either responsible tore involved in other efforts to answer. I just want to point out that I am ?? I might not be ?? I might be forced to be inconsistent because I am in different processes.
CHAIRMAN: Thank you. I appreciate that Daniel. Again, the object here is to get a small group of people together to come up with a form of words. The actual individuals that produce those words we assume are speaking in a personal capacity and not representing their employer or organisations they're working for and in any case, this is just to try and facilitate the working group to come up with a form words that the working group as a whole is happy with. Is Marcus coming to the mike? No, he is not.
Okay. Thank you for that. Next item on the agenda, we have a presentation, a I am happy to say that we have had, for this particular RIPE meeting, a fair degree of interest from companies and organisations in this part of the world and it's great to see participation of these companies and countries in the RIPE community and as part of this effort we have go a couple of presentation from the DNS from Etisalat, the incumbent, Telco and major ISP for Dubai and the UAE and the first of those is Abdullah /PWURB /HRA /AOEBey, I hope I pronounced his surname correctly. He is going to tell us about the operational experiences at Etisalat DNS.
SPEAKER: Thank you very much Jim, this presentation is not mine. Good afternoon, ladies and gentlemen, my name is Abdullah. I am an engineer, a hosting engineer in Etisalat, the Internet operations partner. And today I'll be explaining about the Etisalat DNS operation experience. So let's move on.
During the presentation I'll first introduce, give a brief introduction about Etisalat and the services provided.
The second thing I'll be explaining about the network convergence and the role of DNS.
After that I'll explain about the what the Etisalat DNS in the past, present and the future plans.
After that, I will explain ?? ill show you some current statistics of the request that we are handling.
And then I'll explain about the good things to monitor when maintaining DNS servers.
Finally, I will be showing you a tool that we are using to maintain and operate DNS servers and the point we have learned throughout the evolution.
So, let's start. As you can see, Etisalat, which is called communications company, the number one service provider of UAE, and it's providing IP services such as narrow band access like dial up or ISDN, broadband access like DSL, also leased line circuits, VPN and all these kinds of IP services.
Currently Etisalat has established its current state in 17 different countries.
As you can see here, the network, our network is converging into one core network which will be called N G N, which is next generation network. It will contain the servers, the services in the data centres, the Internet gate ways and will also have voice and video access sites which will all be based on IP. So, the key ?? I mean, it's important for DNS to maintain a high availability and perform ance in order to handle more customers than just Internet customers.
Moving onto the next slide. As you can see in 1996, DNS started at one server which contained all the .ae country top level domains, the customer zones and it contain also the caching enabled DNS. They were all together on one server.
Two years down the line, we convert to having 2 master and 1 slave. Because at that time we were not used to the concept of master and slave.
Then in 1999 we had 1 hidden master and 3 slaves. This concept was accepted.
Then in 2001 we separated the ccTLD and we also gave one master and 2 slaves. This gave a high availability of the .ae top level domain and it became independent in terms of resources and performance from the public ISP caching service.
Then in 2002, we had agreements .ae and ISC and RIPE and APNIC would give like a geographic distribution and better availability for .ae domain around the globe.
Then in 2003 we got the E 164 RIPE delegation.
After that in 2004 we separated the public DNS services from the authority I have server. So now at that time we had like caching services as caching servers and authoritative servers all separated and this increased the availability of authoritative service and increased the security because we were able to control the traffic that is coming to the caching services. At that time we had a small issue in which of these services we had to move either of the authoritative or DNS caching. We decided with the DNS caching as authoritative had like slaves and Masters and from other companies,. If we moved it to another server, it will, maybe it would take time until the zones come up again.
Moving on, in 2004, we Anycasted the top level country domain in two separate networks with 2 AS numbers. And then in 2005 we separated the public caching servers. We put them in two separate groups, one for internal, the other for the public. And this is getting like to have different resources for each of these services.
In the same year we had the IDN trial, this is for the Arabic root. This is to DNS root in different language and the two roots from first serviced in the UAE and Saudi Arabia.
After that in 2006, we started that GPRS slave route. It became slave root for the GPRS service of the in 2007 we moved to intell red hat architecture because it had good performance.
In 2008 we had the calm inski upgrade which had a major performance in our resources and we are still waiting for ISC to release an optimized release.
Moving on: As you can see this is the current setup of the DNS infrastructure in Etisalat. As you can see on the bottom right (caching with C) ?? as you can see on the bottom right group are the public caching name servers. These are for Internet users and for the public users and we also have here the internal caching services. This group is for the the internal servers and the data centre. Here we have the ENUM for the telephone to Internet services. Also here we have the authoritative name server which hand handles the customer zones. We have here also the GRX route which is for the GRX customers and also we have here the IPv6 name server, which is still under test ?? we are testing it to enable IPv6 resolution. As you can see here, this is the ?? it used to be the dot AE country top level domain, but now it's moved to TRL, so it's only handling the reverse zone and we are like master to RIPE.
As you can see, these two items become a group, this is the F route and this is the K route. These are just root servers and we are just only providing colocation services to these two servers.
Now, moving on. As for the future plans: We have three future plans. First of all, as the distributed cashing name server. Where we distribute the cashing name to different locations.
Secondly, the distributed authoritative name service and we largely distribute, where we largely distribute the authority name server to different geographic locations.
Thirdly, the IPv6 Ankabut project. This is for the DNS service for IPv6 project which is called Ankabut.
First, we distributed the cashing name server. As of today we have like two setups of load balanceers. One in Abu Dhabi and the other in Dubai and they are using the layer 47 with virtual IP addresses and behind /THAOETS there are a couple of cashing name servers that are handling customer requests.
What we first thought is that we make like a cluster of Anycasting name services in different areas. We move to Anycasting because it's easy to handle and it's easy to read out if there is a problem in one of the locations. But when we first thought about this cluster, we thought okay, if we had an attack or there was like a big load of traffic in one of the locations, we have a script there that would check the DNS if it's running or not. This script will respond if the DNS is not responding, it will just reroute the traffic to the nearest POP or the yearest location. So, for example, if we have an attack on this location, for example, the script will just take the DNS down and reroute the traffic on to the nearest POP. After that, this POP ?? this location might not even handle the traffic, so it might go down and the same thing happens again. At that time, maybe the first location will come back up, but it won't be long because still the source of traffic is still there.
Also, we moved on to a combination of core and the cluster. Now, the small cluster will be handled by the core network the the core network will have a layer, will have a load band instead of Anycasting. So in this set up, if any attack happened to one location, the DNS would go down but the traffic would be rerouted to the core network. This core network is bigger than these either networks so it can handle higher traffic and even if the traffic is very high, we can even add more servers to handle this traffic.
Now, as for distributed DNS. Distributed authoritative naming service. We have four authoritative named service in the UAE. What we are thinking is to distribute all these name serviced throughout the world. Until now, for this project, until now we have only one in sue Dan, and it's handling the Internet domain.
As for the IPv6 in /KAEU canning abut. This network of IPv6 between universities and will be handling the domain named service for these, for this network. There will be two cashing named service, one in Dubai and one in Abu Dhabi.
Moving on, this is the traffic numbers that we are having. First of all I'd like to say that we have like 45 bind instances running in all the different groups of the DNS. And since last month, the traffic increased for about 33% from 600 here you can see to 900 and we have like maximum 17.8,000 requests per second, an average of 11.2 requests per second. As you can see in this graph it is not linear any more. So the traffic is going high and we have to get prepared for such traffic.
Moving on things to monitor. It's a good idea to monitor the CPU memory utilisation of the servers to see if they are under stress when handling customer request. It is also better to see the number of requests you are getting so you can have an idea of how the traffic is increasing.
Also, it's a very good idea to monitor the recursive queue in case of an attack or the main server is down. It can give you an idea of how the queue is or if they are like bogus domains.
It's also better to monitor the top IP or black hole, so you can see if there is someone spamming the cashing main server so you can identify him and black hole him. This is just enable more resources. It's also better to see the top domains in case if there is a virus that is, that's more than one location and it's attacking the named servers so you can just bogus this domain in case if that domain is bogus or not available you can just bogus it and this will just increase the resources.
Tools we are using. We are using three tools. One of them is pH open view. This is like a commercial tool that gives alert (HP) monitors the network. We are using it because it can integrate with other services. We are also using the MRTG, now we have a new version, it's called the RRD and it can give you like statistics on how the CPO or any of these points that I was explaining in the previous slide. Also net saint, we have a new version called Naigos, this is also open source and it can monitor the servers and can give you like an idea if the servers are up and running or not.
Finally, the points we learned.
It's better to separate the name servers geographically if case they are like a geographical issue or some location issue, it won't bring your services down.
It's better also to separate the functionality in case if different servers had ?? because each different server has its own functionality so it's better to give it separate resource, so it won't affect the other service.
It's also better to separate access in case if you don't want everyone to use, for example, the cashing name server, you can like separate the access of each. I mean, when you separate the functionality you can separate also the access because for example the caching name /SERB err will only accept local, you can say, dis/RART customers and the authoritative U or you can say the top level domain servers will accept requests from anywhere. It's also better to keep the latest software versions in case if there is like someone or a hole has been identified, so it can like cover this vulnerability holes.
It's also better to use a well defined SOA and TTL. This is in case if someone wants to be master of his own, it won't give you issues later on when he is trying to convert his domain to, when he is trying to be master, if for example, if a master of some particular domain and the user or the owner of this domain wants to be a master, so, when he tries to get the zone to him, he won't ?? and we have a well defined SOA, it won't like, it won't let his domain disappear.
It's also better to keep consistent and up to date NS records between the child and the parent named servers.
It's also better to restrict zone transfers. This can be done through the configuration of the named server. As I explained before it's better to monitor and log the requests, to identify issues that are troubling your main server.
Finally, it's better to plan well in advance, so you don't like reach some point where you find that there are lots of, there is lots of traffic and then you start to become, then these servers start to become under stress and then it might affect the servers for the public customers, maybe the DNS would go down or maybe DNS would go down or it will just affect the public customer.
So, that's it. That's what I wanted to explain. Thank you all for listening. If you have any questions you are, you feel free to ask.
CHAIRMAN: Does anyone have any questions for ab dull a? No. Okay. Thank you very much.
Applause)
CHAIRMAN: We are running a little bit behind time, but that's normal for the DNS working group so we have a final presentation in this session which is from Stefan /PWORTS we're who is going to tell us about some new tools that are part of a big project that AfriNIC has for doing all sorts of DNS metrics and stuff. Have you got a name for this tool yet?
SPEAKER: Hello everyone. So, for those of who you were at the central meeting before the RIPE meeting, I warn you that that is more or less the same presentation. So you can spend your time watching U Tube, you won't lose anything.
For the people who were not at the centre meeting, the purpose of the talk is to present a tool, a project that we have at AFNIC on at that tool that we organised in the context of this project and which we released this evening. (AFNIC)
(AFNIC is A F N I C)
So, AFNIC is a registry for the top level dot F4. As with any TLD registry, we have a lot of information that we may not always use. We have of course information which is in the database, everyone knows that but also a lot of information that is really close from us and that we could use. On our marketing team but also our technical team are always asking questions such as, for instance, how the domains we delegate are used. As are used for web only, e?mail only, XPP only. It would be nice to be able to reply to this sort of question.
Also the technical people wanted to have information about the deployment of new techniques like the DNSSEC is. IPv6, etc.. again, information we may help to have you know, IPv6 if you have /SROLD the talk in the Plenary, you have a lot of ways to get information about the deployment of IPv6, the DNS is one of them.
Also, the possible surveys SPF etc.. also we wanted for the tools to be multipurpose, to be able to do different surveys for instance IPv6, DNS, etc.. we want to be able to run unattend sod we can run it every week, every month, every three months and to get information in the long?term.
We want also to have as much as possible walk /RUTS, not aggregates, bus very often statistics you have to come back six months or twelve months later on to question your data to see if it was really what you thought to analyse with better tools etc..
Also we wanted the tool to be distributed to everyone.
What we can learn from the DNS? We can learn things in two ways: What we send out to the rest of the world, active DNS queries that you send in the main server. You can also observe what comes in the authority I have named server of the registry, the questions that are asked and the answers you send, give you a lot of information about what's going on.
We will work on both ways, but at this time, we worked mostly on the first one, active queries.
For the passive queries, as I said we did not start it really yet. The idea is to up serve while the traffic coming in the from the name server, not just a quick glance that you can ample the two like DSC which is useful for the knock because it idea to NOC to know if there is an attack, if there is a mass I can because of spam etc., but to have information more detailed on a longer term, for instance F you want to study the person take of queries done over IPv6 transport, DSC already gives you this information, but not for a very long distance, if you want to study it over a range of several years, DSC is not the better tool to do so.
While, we are also plan to do surveys like, for instance, what our Austrian colleagues did after the calm inst key patch, weak every /S?RS E /AFRS on the possession. Etc., etc..
As I said this is not started yet. So ill talk mostly of what has been done. The development of a tool DNS witness.
Well, actually it was announced at the centre meeting, but ??
Publicly announced here for the first time. Of course DNS witness is not the only tool in its category, I have listed some here.
How does it work?
The idea is to load a list of the zone that you delegated. Okay the 1.2 million delegated in the dot I 4 and then to ask the zone about various records that can give you interesting information. DNS witness is not purely a DNS tool. It can also send XTTP or SMTP request or run external programmes by zone check, we talk in the action item discussion, we talked about checking the lameness of delegation in ?? this could be done with a tool like DNS witness. If you want.
So, for those who work in a registry, you certainly, at least once, wrote one script like this one. A crude version of DNS witness where you have a list of could he main and for every domain you do a request with dig for instance. Then you put the result in a file. Here we are looking for SPF records, a technique for authentication for outgoing e?mail. SPF words mostly TXT records, starting with VXP F1. We query every domain we put the results somewhere and we then we use very state of the art tool like WC to see how many SPF records we have.
The report with such a script ?? it was (SPF) we use T everyone uses it but the script has many problems. First a few broken demands for which you have to wait the expiration of a time?out, a few broken domains can slow it down a lot. You take ?? you do handle a lot of domain and then there is a broken domain for which no name server respond and you have to wait the time?out before moving to the other one.
Also, the output of such a script is not structured. It's quite difficult to analyse while you have to write a script after that to process a result.
And it's difficult to extend this methodology to more complicated queries. Just so take the example of SPF. You can actually put the SPF data in two different thought of DNS recalls. TXT records or the new SPF records. So even for survey like SPF deployment which is quite simple, you need something more complicated than the script. So at the beginning you write a script like this four liner, then you extend T then you extend it and when you have a shell script of 4,000 lines you start to think that maybe you should do it in another way, nor maintainable. (4 thousand) so DNS witness is split between two parts. A generic part which handles everything which does not depend on a specific survey. Such as a zone file passing and creating a lot of parallel threads to perform the queries.
On the second part is a module which is specific to the survey you are doing. So, if you want to survey DNS deployment you use a DNS module. For example, a DNSSEC module how could it work? For instance, you could ask the zone tore DNS key recall. If there is a DNS key recall the zone is DNSSEC ready. Of course if the registry sign its own zone and delegates DS recalls, you don't need DNS witness. You look at your database. But once which are not signed yet, the only solution to see how many domains in dot I 4 are ready for DNSSEC is to ask this domain.
Same thing if you want to do survey on the IPv6 deployment, everybody do it. Most of the IPv6 activity is to try to measure the very small number of bits that go on the wire with IPv6. So, IPv6 module for DNSSEC can, for instance, ask for what air recalls for POP later demain names, for instance www.domain or www.IPv6 dot domain etc.. and of course the ideas is it's quite simple to write a module. A lot of details are handled by the generic part of DNS witness and several modules have already been produced and you are welcome to write more.
Of course, it doesn't work for everything. Some techniques are very difficult to spot with DNS queries. Typical example is another e?mail authentication technique D Kim. D Kim works by putting information in the DNS but under the name which is not predictable because it depends /WHOPB what they call the selector. Every zone is free to create as many selectors as it's want and what name it want. For example, gmail dotcom do you say better as a selector so you have to query data dot ?? dotcom and there is no such ?? no de facto standard like www for web servers. So, in practice, it's very difficult to know how many zone under dot F4 uses.
Now, practical thing: If you want to use DNS witness because it is released, I take T I take the dot comes on file and balm, I run it. You generate a lot of queries. So, if you are the registry, it may be seen as a lodge met survey and it may trigger some problem with a name server managers if they don't think you are legitimate for the service. So it's better to ask before.
Here is how to run DNS witness. It's not really important. The only parameter that is useful here is numb thread, the number of parallel thread that you will use for the programme. Here we will need on the FR zone with the module DNSSEC.
Then what become of the result? Well it depended on the module. Every module is free to store the result in the way it wants. But most of the modules use a database, put the result into the database and so you can use after SQL to make analysis of the data.
So, which, for most people, SQL is simpler than pearl or observing.
DNS witness is written in Python. Remember, you can have a lot of data because when we run a survey, we don't store the global result. We store the result for every domain in order to be able to do more analysis after a while. So, for domain of 1 million zone ?? when you delegate 1 million zone, you can have several million lines of data in the database.
And we use a DNS library, DNS Python written by the people at.
When the zone is small everything is okay. When the zone is large and dot F4 is not the Larne /*S of all DNS zone, when the zone is large you can start getting a lot of problem. Speed of network, lack of memory, Python can be quite greedy. How do I order the limit such as the number of selectors in the code selector, such as Linux etc..
If you are interested in the details, they are all in the source distribution.
Another thing important with DNS witness is that it's parallel. Because when you query 1 million domains, many ?? well, yes, many of them are broken and it's a pain to wait for them. So it's better to do everything parallel. We run a number threads which is given by the user and for a domain the size much dot FR, we discovered for ISP until a good number of threads is something like 15,000. With it you can get a result between two and four hours depending on the complexity of the request.
So, if you want to module which does not exist yet in DNS witness, you can ask me to develop one for you. Then you have to say please and things like that. But another solution itst to write the module yourself. You have two Python class to develop, one to store the result and one to query the domains.
We are nice people to help you there is a utility module with a lot of utility functions that will be used by most modules.
Here is an example of a complete DNS witness module which does absolutely nothing useful because, as you see the query method only has one possible result which is obviously faulty too. Then the store method, just print the result in a real module, the query method would perform DNS queries. On the store method would perform SQL insert in the ??
Now, the results: Because many people are interested by the tool because I would like to run it on their own zone. But I believe that most of you are interested by the reasons.
All the data presented here was retrieved from dot FR between 17th October and now. Of course, because a programme is recent, I cannot Jet give you nice graph with several years of data.
The revolver, the DNS witness was to limit the load on the network. The machine was a T1 PC with deb and Linux.
For instance, dot F4, is not signed web not just count the DS records in the database but you can ask the zone how many have a DNS key? 49, among 1.28 million. Of course if the TLD is not signed, people under it have little incentive to sign the other one. So 49.
Do not among the 49 that have a DNS key, only 37 are actually signed. The other zone ?? the they have a DNS key but no zone, noen sec, nothing, just a DNS key.
Among the 37 that are signed, one is in the DLV ISC registry. Probably it's the only one in production. It's not my zone.
If you want to study deployment of SPF in dot F4 you have much more interesting figures because you find the 15 percent of domain in dot F4 use SPF. One warning, it makes only 4,350 different recalls. This is partly because some records are very standard. You can find them in every SPF, when you use a SPF for the records. So A makes question mark all is very common one but it's also because one big DNS host err in France choose to have SPF to all the domains it manges, which makes actually two thirds of the SPF domains in dot 4. That's a common problem with this sort techniques. One big actor in the market is' concentrated. One pig actor can change the data from one week to another with a single decision.
Now, IPv6. Because everyone talks about IPv6. We measure several things. If there is a quad A for NS on M X records and if there is a AAAA for domain, www.domain www.IPv6 at domain, but also we check whether the machines do reply to http or SMTP request, because we are ?? in many /KA*EUS as quad air record which is a link local address or sometimes it's a global address but it doesn't work.
So, just with the DNS. We can find that 4 percent of domains in .f4 have at least one AAAA. Web, mail, DNS. These domains can be said ?? we can serve these domains that the started migration to IPv6. But only 0.03% of a AAAA for every service, mail, web and DNS. We can say that 435 domains have Dunne the transition, they can live in a purely IPv6 Internet.
Some of the addresses we found were obviously bogey for instance. The first common address is a: 1, which is local most.
If you test not only if there is data published in the DNS, but if the data corresponds to something useful, we check HTP connection and we find that 92% of the addresses work. Work meaning that there is an http reply, it may be 403, but there is a reply. Because we are only interested in IPv6 connectivity. So 92 percent work. It's not too bad.
Unfortunately, if you sort the addresses to keep only the unique addresses because remember, one big /A*US err can put an IP address for many domains, the numbers are not so good. It's only 67 percent of the distinct addresses which work. It's still better than nothing. You have also ?? with the sort of today you have false negative, for instance it fails because there was a problem with the problem AFNIC connection at this time. You have a problem with someone /PEURBD a AAAA which is local host well work because the perform a test as an http server. In practice it's not sufficient to make a false results.
You can also perform a lot of other surveys. For instance, on white wards in the zone you delegate. 18% of the zone on dot I 4 is a white card. Again this sort of data is very sensitive to the time where you measure. For instance, when you come back to IPv6, you see the 4 percent domain with at least one AAAA in July with another programme, not with DNS witness. In July, it was less than 1%. And in October 4%, because in the meantime, one of the big web hosts in France added a AAAA to every zone. And a working AAAA.
So, now if you want to run the programme yourself, you can get it at this address. A warning: It is not yet open. It will be as soon as I'll be able to come back to my seat and use my laptop and if Internet works, etc., etc.. but this evening or maybe tomorrow it will work. You will be able to run it freely because it's distributed.
Of course no talk is complete without a glimpse on the future work which we plan. For DNS witness at the present time, we must go through a resolver which has a lot of good consequences. But in the future version, we will have an option to ask directly to the authoritative name servers. Also, we plan to develop new modules, for instance, we have two queries from our marketing team who would want to know how many domains in .f4 are e?mail only or web only. We also plan to develop a module for zone check patrols. This is a tool we use to /TKHEBG a delegation. But we do it only at delegation time. Maybe one year, two year, five years after the domain is broken and no longer passes the test. So with DNS witness on zone check, we will be able to say okay, 90 percent of the domains in dot I 4 are still okay. 90 percent is an assumption. We didn't develop the module yet.
And the rest of the project, we plan to get more users because there is no point in releasing software if there are no users, so invited to download to try top complain, to send bug reports, etc.. and we are plan to come back to the future RIPE meeting with more results on the long?term.
Also, we plan to work on the passive monitor for studies on what happens to our name servers. This will be probably based on DNS cap or similar programme, although thanks to everyone who contributed to this work, thanks to those who listened and now the questions:
CHAIRMAN: Thank you Stefan, any questions? Daniel?
AUDIENCE SPEAKER: I'd like to thank Stefan an AFNIC for sharing this tool. I think it's going to be very useful for many team. But what I'd like to say and ask but still on behalf of the operations team here, is if you want to try it out, please don't do it from the meeting network. We want our caching ?? our caching forward to live. Please ??
SPEAKER: What we did was to warn all of registrar for the usable channel that we will start using the tool and we'll give the IPv6 and IPv4 address of the testing machine so people could be, could know in advance what's going on. Of course nobody with a warning, but we had only one complaint /?PT. Someone said hey, what's that.
AUDIENCE SPEAKER: And the in the absence of any other questions, why price them?
SPEAKER: Why not? I mean if I had to programme it is as /KEL or Java or c++ or lieu ayou would have asked me probably the same question or if not you, someone else. Now, obviously Python was chosen for two main reasons, why it's very simple to write and to read which is a very good thing if you compare springs with pearl and two ?? at the previous discussion Jim said that we should not talk about political issues, so, I won't.
The second reason is that there is a good DNS library for making DNS requests, one written by Nominum. This time I won't say anything about pearl, which is also a very good DNS library but it's not the case with every language.
CHAIRMAN: Can I suggest that pearl lovers and the pearl haters meet in the bar and have a free frank exchange of views. I'd be happy to sell tickets for that event. Moshen.
AUDIENCE SPEAKER: It's not a question. But just a comment. We, of course, invite you to use it maybe as an end user and with of course the disclaimers of Daniel, but we also will be happy to share results with other ccTLDs or TLDs or whatever, so that we may for example, focus, let's say on IPv6 and compare from country to country or region /O region what's going on out of the DNS. That reminds me, the results of Arbour yesterday and I invited them actually to see this work. We don't claim to have the full view of IPv6 penetration. It's only a tiny view via the DNS. So, we are also willing to share that with other operators who have many other views of whatever penetration F it is IPv6 or other. So, it is also a tool for the community to share their results and to compare and to have a good statement of what's increasing or what is stagnating.
CHAIRMAN: Thank you Moshen. And thank you Stefan for the presentation.
(Applause)
Okay guys, that's us just about finished. Just before I wrap?up I'd like to say thank you to the speakers and presenters for the presentations. So an afore taking the minutes, to Mark for monitoring the Java room and to the very nice latey doing the stenography and transcribing for people out in web land.
Now let's see if there is any coffee and cookies left.
The session conclude