Archives

DNS Working Group ?? 18th November 2010 at 11 a.m.

CHAIR: Good morning everyone for the rest of you. This is going to be the DNS Working Group meeting version 2 at RIPE 61, so if you are not prepared to receive fully loaded DNS information, this is your last chance to leave the room, and I'd like to ask people in the back to close the doors. So we can keep on doing our secret business and not being disturbed by the outside activities. Thanks.

My name is Peter Koch, I am one of the three co?chairs of this Working Group. And this morning it's my turn to guide you through the second part of the agenda. So, first we will have a status report on the interim ITAR by IANA, that he is given by Elise Gerich from IANA. We'll have a bind 10 update by Jelte Jansen. IDN reemployment reports by injury gay or bun off. And then we'll have a longer presentation followed by a discussion on reverse DNS for IPv6 and Kostas and Dave have prepared some slides to kind of represent the ISP view and we'll have Richard Byrnes to give us some insight on the application needs for DNS reverse mapping in v6 and after that, we chairs at least hope we will have a fruitful and/or lively discussion on the panel.

That's basically it. Any questions? Any suggestion to say change the agenda? Okay. So then, just let's go. And I'd like to invite Elise to the stage to give us an update on the IANA ITAR.

SPEAKER: Hi, my name is Elise Gerich. And thank you for ivniting me here to talk about retiring the ITAR. So, basically, this is a very short presentation.

So this slide basically just gives you the early status of what happened and why there was an interim Trust Anchor Repository created. RIPE was one of the organisations that prompted the establishment of the internum trust anger repository. Otherwise known as ITAR and so it went into production in 2009. And we are retiring it in 2011, so it had a good and truthful life of about two years. And it laid the foundation for what became the DNSSEC signing of the route and the DS records that are submitted through the IANA in order to get the Trust Anchors of different TLDs into the route.

So, this graph represents ITAR's life and its now demise and as you can see as soon as the route was signed, people who had Trust Anchors published in ITAR started to my great to the route itself and at this point in time I think we have it's approximately 49 TLDs that have Trust Anchors published in the route itself and those that were in ITAR have been my greating from ITAR to the route itself.

So this last slide, so this is a very quick presentation, three slides is all you get ?? is that a summary of the status of the project for ITAR, and I should recognise Kim Davies who I think many of, you know, he is the person at IANA who has maintained and taken care of the ITAR during its lifetime. So, basically, the requirements were well known and were executed and this was a way for TLDs to get publication of Trust Anchors into a public place and we learned a lot about this. We being ICANN and IANA, and also VeriSign so that when we actually did the signing of the route, we had learned a lot. We had lessons learnt from this experience that benefitted the actual deployment of DNSSEC in the route. So, the notice has gone out, Jan 2011. The ITAR will be retired and we want to thank you very much for prompting ICANN to establish the ITAR and for the collaboration that you gave us in running it over the last two years and I guess it's like long live the king, this one is long live DNSSEC in the route.

Thank you very much.
(Applause)

CHAIR: Any questions?

LARS LYMAN: It's not a question, it's a comment. Thank you for retiring this. This was an intermediate thing and it was a good idea at the time and I am very glad that you are retiring it so that we actually move things onto the real route.

SPEAKER: Thank you and we don't often get to retire things, but it's fun when a project's been successful and it runs its life and then we can say good?bye. Any other comments or questions? Suzanne?

AUDIENCE SPEAKER: Suzanne Wolfe. I just want to congratulate you on being able to declare victory and move on.

SPEAKER: Thank you. I am the lucky beneficiary of joining ICANN and being the IANA starting in May of this year, so there are many other people who really should take the applause for this project and like I mentioned Kim Davies but there are many others that have been invested in this. I just get to be the one to claim victory. So thanks everybody.

CHAIR: No more questions? Fine, thank you.

SPEAKER: The little voices in my head claim I for work for ISC. The bind 10 project has been going on for a bit now and we are still working very hard on it. These are the generous people that make this all possible. And I am here to talk to you about a sort of things about bind 10.

I will first talk a little bit about the architecture. I will mostly speak about the way we use modularity here. I will talk a bit about the DNS library. And I will have some homework for you. But don't worry it won't take you more than a few days.

More BIND 10, we chose to use a set of cooperative processes as opposed to the monolithic structure that BIND 9uses. This has several drawbacks but in my opinion, more advantages, for instance, you don't have fade sharing between modules. If a module has a fatal error, then it doesn't necessarily have to take down the whole system with it, which did happen with other systems in the past.

And also you get how we envision this and how it currently works. Let's start out with the core of BIND 10. We have a master process which starts up the rest of the processes and gives them the essential information they need to run. I say master, but it's actually ?? that's also a name in DNS, so we renamed is the boss of BIND, or Bob for short. And then we have a messaging module. Internally all modules communicate with each other by sending adjacent messages over an synchronised channel. This is the module that makes sure all the other modules get the messages they need. And we have a configuration module. We do ?? we intend to do full life configuration and this module makes sure that every other module those what specifically to do at any given time. These three modules make up the core of BIND 10. If you run threes three modules together you are already running a BIND 10 system but it's not really doing much anymore. So let's add some actual feature modules. We implemented a command and control module which serves on an http F server and accepts it's a restful that accepts commands for the rest of the system. This is what clients use to connect so we can implement for instance a nice web interface. Right now we only have a command line interface that secretaries to this. But, since it's an API that we will specify in detail, we can make any clients use this.

We are here for DNS, so let's add an authority I have server. We say we want to have, be a master for a few zones, so we have an Xfrout module and well, let's be a slave too so add an Xfrin module.

So each module we adhere has its own set of external agents it talks to this could be a night set up for a full authority I have server that most of the things people need from DNS. But if you only want to run a slave server for instance, you can have the authoritative part and just the Xfrin module or if you only want to have recursive server with dynamic configuration you can run command and control with just recurs sieve server. We intend to build extra modules in the future. For instance, the IETF is talking about having a general main server control protocol. That would be implemented as a separate module. Or we are thinking about providing clustering support. That would probably also be a separate module that connects to its clustering peers and shares information like that.

We are writing BIND 10 in two separate languages. The core libraries and the high performance part we write C++. Everything else we do in pie on this. But since some our pie on this parts needs those core libraries, we are writing repairs for those. So, from a code level point of view, it looks a bit like this. The green circles are pie on this modules and the blue ones are C++ modules. You see here command and control and boss don't need to use DNS data so they plug into the standard library here, but Xfrin and Xfrout do use packets and messages from DNS. So we wrote pattern linings around C++ DNS library. So you could use a fruitful scripting implementation, but as you may know, that scripting languages are easy and fun to use but may not be the most efficient implementations. So, having these repairs, just give us a library that is faster than a pure scripting language and we hope that that makes it a bit more useful to do actually interesting stuff with it. Though of course, it's probably still slower than a pure C or C must say plus implementation.

So, my colleague Jim did some bench marks against free existing scripting implementations. He wrote a toy DNS server that just takes one inquiry at a time and makes a response out of it. The code is on his web page, for our library, the main loop looks like this. Actually does any more. We have not frozen the API yet and this doesn't run with the current version any more, but it should give you a pretty good idea. It's simply receive one message, prepare a response and depending on what the query contains, either send back an error or send back some data. For the existing DNS pie on this library, it looks quite similar. Although, if you look at our stuff, we have a specific message renderer to render the data a little bit more efficiently we think. And net DNS library, well, it's almost the same like the DNS route. It's about the same size, about the same contents. So what he did was he ran it on his laptop, and I don't know the specification of his laptop. So numbers, you can probably ignore those. But it does look pretty good. My computer did not have that font there. Looks nice though...

But as you may have expected, and as you can see here, having a single layer wrapper around a C++ implementation does give you you quite a bid of speed improvement over a pure scripted implementation. And that was one of our goals so I am quite confident that we are reaching, at least this one of our specific goals for our libraries.

And as I said, some homework for you. I have a pretty clear idea about what I want in the DNS server and the features I think are cool and I will be running at home and on my other networks. But we really don't know what you want. Some of you may want a pony. I cannot promise you we'll get you your pony. I can promise we'll take a good look at it.

So we set up a survey. The URL is a bit long. You can just follow the link at ISC.org, and I want you all to come talk to me. Originally I was supposed to give this talk on Tuesday, so I said I'll be here all week, but it's already Thursday, so I'll be here the rest of the week. And I kind of hope that I am going to be doing some sightseeing tomorrow, so I am going to be here the rest of the day. But if cannot tackle me in the hallways, please send me an e?mail. Thank you.
(Applause)

Chair: Any questions?

AUDIENCE SPEAKER: George Michaelson. I have also played with the libraries you put up there. I can confirm from my own experience exactly what Jim May saw about the relative speeds excluding the rubbey. There is an additional one, the packet disassembly pie on this code. Because there are so many mangled and miss formed DNS queries out there, it's actually quite important to test again mall formed stayed coming along the wire and I observed that the pie on this that is available to do low level packet decomposition into DNS is extremely slow. If you can do a similar class of improvement you you did in your native pie on this, I think the community could benefit. That speed up is very impressive. Thank you very much for releasing this code. I think a lot of us are going to like it. That was a very nice simple code example. So thank you.

SPEAKER: Thank you, we'll take a look at that.

CHAIR: Anybody going to take to him. Next the Sergei giving us an overview or experience report actually of the first implementation of a Cyrillic country code top level country domain.

SPEAKER: Thank you very much. My name is Sergei Gorbunov. I represent our research centre. We are not the registry but the registrar, the biggest one for .ru and are currently for .rf also. So our country, a week ago, has successfully launched the open registration in the first Cyrillic top level domain, .rf. So we have some interesting experience to share with you. First of all, some key note dates in .rf history and .rf history implementation. In 2005, ICANN decided to introduce some code, some non latent ccTLDs and in 2008 the Russian president got information about this idea, so after that active stage of work under the project of .rf has started, and to the end of 2008 we have streamed for the Russian cyrillic top?level domain also registry for .rf was selected, the coordination centre for TLD. RU became a registry for .rf. During 2009 all policy issues were resolved, so when ICANN approved Fastrack process, a Russian application was on its own non?latent TLD was the first. It was submitted on 16 November 2009. And was formally approved at the beginning of 2010.

So, in May 2010, the domain was delegated in the route and the first website became available in TLD .rf where president R F and Government .rf.

So, some words about .rf management. On the top we have the coordination centre for TLD RU. It's the registry for .rf. It is responsible for all policy issues for all registrar accreditations and it also appointed the technical centre for Internet as a technical provider for .rf, it supports .rf technically, and also we have 19 registrars that were created by the coordination centre, and physically, they send their applications on .rf names to the technical centre of Internet.

Some registry features. It is EPP based with some kind of modifications regarding additional fields and some changes of registrar transfers scheme. Also, the registry has two nodes in Moscow and in St. Petersburg. One is primary, the other is standby. The nodes can be momentarily rearranged in case of any emergency.

Thick or thin: To be defined. Currently the registry is thick because it keeps identification data of registrants, but from the January 1, 2011, the situation may be changed. It is connected with Russian law of personal data from January 1, all organisations that keep some personal data should be ?? must be officially certified. And it isn't defined yet if the registry will get such a certificate, or should it get such certificate, and in case there will be no certification for the registry, it will be thin and identification data will be stored by registrars or maybe it will be stored by the registry but in encrypted form and the keys for the encryptions will be stored by registrars that will be officially certify provider of personal data.

So, the registry is able to proceed 30 which are queries per second and has two hidden primary DNS and 11 secondary DNS located in Russia and abroad. We hope that DNSSEC soon will be implemented. Currently it is testing in .rf, and also our registry is able to support IPv6.

Now, some words about .rf implementation schedule. At first, it was like the following, you can see it, there was a sunrise for Russian governmental bodies and Russian language trademark owners. Then there should be a land rush in spring 2010 when the main names should become available to everyone. But at a higher price than a standard price, then there should be step?by?step cost reduction to the reduce the standard cost and open registration to everyone at a standard cost should be started at, in summer 2010. But, this plan was unable to come true because at the end of the sunrise, the coordination, the registry understood that there are a lot of ?? they understood that there were a lot of categories of users, categories of intellectual property rights, owners who were out of sunrise due to strict rules, so their names might be registered by cyber squatting, phishers, and so on, during open registration, and there was a risk in this sphere. So, here you can see the list of intellectual property right owners who were out of sunrise.

So, some consultations were organised by the coordination centre with market expert who patent attorneys, with trademark holders and finally the schedule was updated.

So you can see that two Russian language trademark owners and Russian governmental bodies were added. None of the Russian trademark owners and some officially registered in Russia, non commercial organisations, mass media companies which names are not trademarks. So all of these categories of users could get, could obtain .rf name on a priority basis. Till 16 September 2010. Then it was decided knots to hold any Land Rush. So it was cancelled and currently domain names .rf are available particularly to everyone from 11 November 2010. There are only two restrictions. Domains are not available for non?residents and also the transfer between registrant is prohibited. This restrictions will be enforced till end of ?? the first year of open registration.

So, of course there are shortcomings. There was some mistakes during .rf introduction. Very strict rules of sunrise in the beginning and a hot of trademark owners and intellectual property rights owners couldn't obtain .rf on a priority and basically at the beginning, the strictness of the rules couldn't protect .rf from the cases of registering domain names similar to key words from Russian dictionary during sunrise. How was it possible?

So, for example, we have got domains like cinema .rf and some others registered on a priority basis. During Sunrise and of course it was a policy short coming. It was possible because according to Russian law, in some cases, it isn't prohibited to register domain names similar to ?? to register trademarks similar to the words from dictionary and some users used this peculiarity of Russian law so they registered trademarks similar to key words, then applied to register the domain names and their applications were success three approved because, according to the policy, they were formally correct. Of course this caused some kind of scandal on the market, so the coordination centre stopped sunrise to realise to understand the situation. But after some weeks, the sunrise was relaunched in the same way and the representatives of coordination centre told everyone that the problem was not in the policy for .rf but in the Russian law, which permits registration of trademarks similar to key words from dictionary.

Of course, Land Rush absence is another short coming, because we see that there is a high risk of cyber squatting during the first date of open registration, and the Land Rush was declined in a couple of weeks before the open registration started. So, that's another short coming, because there were a lot of last minute changes during the implementation of .rf and that's not good experience.

Everyone understood that there will be a high demand on .rf names during the first days of open registration. So it was necessary to prep for this demand for registrars and for registry. So, a pre?order system was organised, thus by sum registrars and during the pre?order, there was about 100,000 applications on .rf names received by registrars. All identification data for these domains was transmitted to the registry beforehand. And also registrars was able ?? were able to establish TCP and EPP connections beforehand, before the open registration started, so, that was done. So registers could not waste their time during ?? after the start of the open registration.

So, there was a restriction for registrars. Each register could transfer about 4,0008 hundred queries per hour. Then on the second day, open registration, this figure was doubled. Currently each register can transfer about 10,000 queries per hour. And also a list, a blacklist of domain names that are prohibited for registration. Unfortunately, the registry announced this, that list just a couple of hours before open registration started, so to that time, a lot of pre?order applications were received by the registers and some of them should be cancelled because the domain names in the applications were similar to the words from this blacklist, so sensored words.

Also, the registry didn't announce which node will be primary during the start of open registration or in St. Petersburg and a registry should prepare for this somehow. So for example, RU centre place some servers in St. Petersburg and also we provided some network protection mechanisms, so our queries speed sending to the registry was maximum, or you can see that we protected from the ethics and also we changed our traffic routes to exclude influence out, outside influence on our traffic. So that was right decisions because our speed, query speed transition to the registry was maximum.

And the final slide is about the statistics we have now, so, experts, market experts predicted that during the first day of open registration, there will be about 100,000 domain names registered, but finally, they were mistaken, because 100,000 registrations were after, were reached after during availability. So after two days of open registration, we had more than 250,000 registrations, and currently we have about 500,000 registrations. So or estimate is to register about 800,000 in a year.

Thank you very much. If you have any questions, I am ready to answer.

CHAIR: Thank you Sergei.

AUDIENCE SPEAKER: Hi. I heard some rumours that blacklist for domain names were based on a kind of dictionary of offensive language. So my question is: Are you going to revisit this list because, as far as I know, some normal words were for some reason were replaced in that list.

SPEAKER: Yes, I have seen the blacklist, so it was sometime ago it was published in the Internet, so everyone can see it now, yes. And there are some regular words. It's the question to the registry if they will, if they will check this list or not, so, we hope that it will be checked, so regular words will be excluded.

AUDIENCE SPEAKER: Thank you.

AUDIENCE SPEAKER: Jim Reid, just some other random guy in the bus. Sergei, I am a bit confused about what was happening for existing domain name holders in .ru, when the Cyrillic version of the ccTLD was introduced. So let's say for example, I had registered Kremlin.ru, was there some kind of mechanism that that name in its Cyrillic form would be preserved or protected so that someone could come on and register the Cyrillic IDM version of Kremlin.rf in its Cyrillic ccTLD?

SPEAKER: Unfortunately there is no particular mechanism for this. But the domain ?? you have named .Kremlin.rf, for example, yes, it was registered on a priority basis by Russian Government.

JIM REID: I expect it would be, but I was thinking for general case.

SPEAKER: General words, no.

AUDIENCE SPEAKER: Just a really quick question. I saw all of the restrictions that you have imposed posed on this but I don't think it was clear to me. My question is this: Do you allow any Latin characters to be intermixed in the domain?

SPEAKER: No, so only Cyrillic.

AUDIENCE SPEAKER: It's kind of interesting to see that, you know, there is things about land ?? it's not really different between Latin characters and other characters, it's a lot of speculation going on there. And but I have another small question and ?? are you talking about APP extensions you made and are these these come highly published somewhere or?

SPEAKER: I can name these additions, for example we have the field verified and unverified, that depends on if the domain name owner provided its copy or not. Also we have the field about identification number of the organisation which owns the domain name. Also, there are some information about the registrar, so, these kind of changes.

AUDIENCE SPEAKER: Yeah, it would be interesting to see this. Public to that not everybody would be inventing the wheel again.

The other thing is you said there were 11 DNS servers for IIU. You can only find 6 in the DNS.

SPEAKER: Ah, there is a map, so I can show it to you. It's on my laptop, so there is a map for the servers. So you can show it to you.

AUDIENCE SPEAKER: But, strange it's not announced in the DNS. But we'll talk about it later.

SPEAKER: Maybe it's a question to the registry again, yes?

CHAIR: Okay. That seems to have answered all questions. Thanks again. I guess there is one more question.

AUDIENCE SPEAKER: I am from Russian federation so I am potentially user of this domain. You told about over 200,000 of registrations already made. Also previously you have experience with IDN registrations in .su. My feelings and most such registrations in .sr give ?? of four domain partners, what is your estimation on this 200,000, how much are really users with real websites and how much just gives it to park the domain and advertiseers or something like that.

SPEAKER: We hope that there will be demand because it's very easy to type this domain, to use the domain, to use it for marketing purpose, so we hope there will be demand. Currently there are about 30% of all registered domain names, they will already been delegated. So, that's for us that is good statistics. We see a lot of domains that relive work, for example for very big brands in Russia, so they are used for directing on the main site and so on. So we hope that there will be demand.

AUDIENCE SPEAKER: And another question. You have not mentioned but are you ?? another option for the ones who use the same domain name. So the question may be for ?? is there some practice in the world for allowing the people who want register same name to battle with ?? and maybe other question: Who is beneficiary for profits for such registrants?

SPEAKER: So, the auction was organised mainly because of the Land Rush absence. So otherwise, if we ?? if we are not holding an auction, yes, the domain names will be registered by cyber squatters because they have special programmes enabled to register domain names quickly, more quickly than a regular user. So that's why an auction was organised and if you know in other TLDs during implementation, auctions are common practice during Land Rush officially provided by the registry. So, in our case, registry declined to organise any Land Rush, so we decided to do it our self, somehow to protect the domain from cyber squatting.

AUDIENCE SPEAKER: So it's profit of a ?? centre exactly. Thanks.

CHAIR: Just quick clarification there. You did an auction for your customers.

SPEAKER: Yes. Yes.

CHAIR: Thanks again.
(Applause)

Which now brings us to the ?? session talking about DNS reverse mapping for IPv6 and I'd like to invite Costas, Dave and Richard, if he is already in the room, to the stage and give presentations and have a discussion afterwards:

Costas working with OTE. It is actually the grief telephone incumbent, so to speak, the Telecom Italia of Greece. So we pumped into this issue in our pilot IPv6 offering. We planned to offer a dual?stack access to our users, and we are currently having a limited scope, the dual?stack access. I think we can talk a bit more about it in the next RIPE meeting when we have more details on the subject. But the issue is what to do with the reverse DNS mainly for customer allocations.

So, when I researched on this issue, therefore, let's say, no current best established best practices like in the IPv4 world, so I post?it on the list and the good chairs told me to prepare a presentation and I collaborated with with Dave on the subject. Thank you, Dave.

So, what's happening now in the IPv4 world? Well, there are quite a bit old current best practices from the old RFC 1912. Every Internet reachable host should have a name and make sure PT R and A records should match and even if host is multihomed you should make sure that all IP addresses have a corresponding PT R record. So more or less these are the basic rules, that all ISPs try to follow.

Where it is actually used the reverse DNS stuff. Well, some applications still use reverse DNS lookups as a security measure. I can understand that it's a weak form of authentication but most applications or quite a few applications still use it. So, if they fail to find a reverse mapping, or even a matching reverse mapping, they consider that a potential security concern and they could drop the connection entirely. Websites could also use the reverse mapping as a form to verify whether a client is located in a specific region. And one application, one killer application that makes use of this is e?mail with MTAs which can be configured to drop connection in case of no PTR or no matching PTRs, depending on the policy of the administrator.

Another case would be use reverse mappings to log useful host names instead of addresses in the IPv6 case this happens, this could be more useful. Also on trace routes, and someone could also score mails on the basis of missing or non matching reverse mappings.

So what do we do at OTE? I think not very much different than most ISPs. We have our fair share of allocations. This is our current image in the LIR portal. We provide authoritative name service for about 20,000 domains. We accommodate a lot of customers, and of course the public sector in Greece. We generate automatically matching PTR records in arpa with corresponding forward records and we also, for the customers assignments, we pre?populate two specific domains. We might change the first one depending on whether the customer is dynamic or static, we use home.ote net .gr and the static for the static. We.populate these forward zones and have scripts generate the reverse PTRs for them.

Well, this approach does not really work in IPv6. First of all, editing manual zone entries I don't think most administrators would like that, given the exact and elegant form of picks reverse records. A single customer assignment can be a /56 based on current practices or there is a shift from what I know to give a /48 to customers. So you can't possibly pre?populate a zone with that many PTR records for a single customer.

On the other hand, when state list configuration mechanisms are used for host addresses you can't possibly know in advance which address a host can take. And on top of that, some popular operating systems, they generate random temporary global addresses, some sort of privacy extensions. I don't know if this is an RFC or not, but this happens. So, we can not possibly know in advance, using this mechanism, what kind of IP address a customer can take, or pre?populate the entire set for the customer.

So, the main questions: Should we even care about the PTRs in IPv6 arpa? Do we even further need them to match just like in the IPv4 world? There are quite a few people that will hate this, even in this room, okay. It's really nice to have domain names in trace routes. This is actually an actual trace route from our network to Google.

Okay, so how could the records in IPv6.arpa be of any use in the IPv6 world? Well, current practices use PTR records in Greek authentication methods in services and this might not go away in the near future. I think most people will just try to map the IPv4 working things in the IPv6 world, so we could be stuck with these mechanisms for quite a long time. It is actually useful to have human readable names in log files in servers. Useful to show names in trace routes. And certain applications like e?mail, could use reverse mappings to provide scoring, create reputation of domains, and stuff like that.

So, what are the current approaches to the problem? I was pointed out to an informational RFC, the draft?Howard, currently in its fourth revision and I was told that was pretty much what we have on the subject now on the Internet engineering taskforce. This document describes a few approaches for the problem. No response, based on wild card matches. Various dynamic DNS approaches. Delegation and even dynamically generation of PTRs when queried on the fly.

So, let's start with the first, with a more simple ones let's say. The first one is quite simple. Provide no responses actually for PTR records. Just ignore them. We have no worries for reverse DNS and all the shortcomings that come with it. It is an option of course.

The on the fly generation of responses actually says that ISPs could generate PTR for addresses when they are requested on the fly based on demand from a specific algorithm. They could even cash or pre?forward the AAAA records for the TTL or the generated PTR. This entails additional processing loads and it's a bit of an issue for denial of service attacks. So providers should employ de/TPHAOEUR of service counter measures. It could be used in a DNSSEC environment provided you could on the fly provide signatures for the records.

I will skip a bit the dynamic approaches and I will go to the simple delegation approach. Well, in the delegation case, things are quite simple. You delegate the customers assignment to the name servers of the customer. You make it the customer's problem. Of course, quite a few customers would have the skill set to do this. Since we are talking about it from an ISP's point of view, but at least they have a limited enterprise network and they couldn't force their own policies on the subject. Of course more frequent delegation could mean more frequent Lame delegations and we should have regular audits to pick these up. So, back to the dynamic DNS approaches. There are quite a few dynamic DNS approaches, and a good discussion with Dave came with a few interesting ideas that Dave will discuss a bit forward.

So, dynamic DNS approaches are a way to ensure that forward and reverse records match. Of course, my main concern is does it actually scale? Do we have any real large scale networks using dynamic DNS solutions in the network? Once the interface configuration is complete, hosts could provide both AAAA and PTR records and they should need to know which name servers to update. There are also concerns about the authentication of the update requests, potential denial of services to the entire system. And we also have the issue of generation of illegal or inappropriate names that hosts could provide. So we need to address this issue as well.

Now, the most simple approach discussed in the draft?Howard draft, is having dynamic DNS updates generated from individual hosts, which is a simplest case actually a residential user, a single host is connected directly to the ISP. The ISP could provide the address information, the recursive name server to the client and a domain research list via IPv6 currently. Here the document says we could over load a bit the meaning of a search list, so a host can determine its fully qualified domain name by appending the host name and a potent of the search list path. After that the host will perform multiwill SOA queries to find the longest prefix delegated by the administrator. Once it finds finds that it will send a dynamic AAAA and PTR update. The main issue with this approach is that this is not the default behaviour for many hosts. I don't know if it is the default behaviour for any hosts or any operating systems. And one main issue also is that most clients are expected to be connected through a residential gateway and not directly to the ISP's network.

So the main idea with discussions with Dave here was if it would be possible to let, say, take advantage of the AAA mechanisms currently employed in ISP networks so as to generate dynamically records, PTR records. So we have actually more or less two cases. IP over Ethernet setups based on the DG P and ETPP setups.

Dave: Okay. So, here is a diagramatic interpretation of a simple dot /SEUS 3 deployment. And you see that the user is connected to the infrastructure via a box that for reasons of space saving, I have labelled CM plus RG, for those who are not familiar with the term, sometimes referred to as home gateway, the residential gateway is the CP path. Traditionally in cable networks you would have a cable modem and then you would have your equipment downstream of the cable modem. The cable modem would act a bit like a bridge. The residential gateway it the CP and it provide the land services. In this diagram the two are together with one unit that you buy much like the tradition at ?? it provides DHCP for your LAN and everything else.

In this scenario, we go and we get, we request a v6 land prefix and that goes through the CM T S and that requests that up Sister the upstream http server. And then you know a prefix is returned and to be delegated to the residential gateway and the residential gateway does the h v6 with all the hosts and users LAN.

At this point when we asked for this delegateded prefix and it's assigned by the DHCP, we can make an update. It can make an update to its name servers and it can tell them that this prefix has been assigned and leased. Then there are a number of different ways of doing this here so we can do a number things. They could issue a wild card and we'll talk about wild cards later. We could perhaps give the name server authority to start doing, answering on the fly queries for stuff inside this. Or you know we can just put some static entries in for instance, just the gateway address for the user so at least you know trace routing in and out, there is some kind of, there is at least one record there. Perhaps the user doesn't need PTRs for anything that's delegated outside. And then we can ?? when the lease expires, we can remove it from the name server.

In the PPP scenario, it's the same except you have radius in this case. The underlying mechanism for IPv6 really does still use NDRA in ?? in most implementations that are out there, this is actually radius mediated. So what happens in this case, we make a call from the CPE and the radius, in this case the Naz or Raz and the radius is asked for audit and some prefixes are assigned and perhaps a transfer prefix or perhaps this comes from a pool, but the delegated prefixes themselves an assigned from the radius. That's done from the CPE. So when we do that, we can make use of radius accounting which is actualliey a bit more verbose than a ?? with radius accounting we get star packet. Which says that the users ?? this is the use certificate online. They are authenticated and these are the address details. In there we are going to get the within a prefix and the delegated prefix as well and then we can do the same with the name server. The advantage of using radius counting is we get a stoppen with the user logs off or we can time it out if for some reason there is a failure and we don't get that.

I have been told that we don't have much time so I'd like to quickly move tonne to wild card records. Wild carding is quite interesting. I like wild carding. Personally do I it myself. You can wild card the customer as assignment and then if the customer has got specific needs, they can punch holes and you can give them an interface. This is just to highlight for people that say don't do wild carding, wild card bad for DNSSEC. That's not quite true. In NSEC and also in NSEC there was you can say it was expanded from a wild card and there is a small illustration of how that works with the labels filled there in NSEC.

Management of holes is you know when the customer wants ?? this is the wild card entry here ?? management of holes where the customer wants to punch holes and create entries here. Let's see if I can find in this case ?? this is ?? so, basically giving the customer interfaces, these are the prefixes that are assigned in the CMD brief for you and letting them create holes in them so they have static entries over the wild card that you take back over.

SPEAKER: So this is actually my personal opinion on the matter currently. For infrastructure ranges, the servers and network elements more or less continue doing things in the IPv4 way. We populate the forward Jones and have scripts generate the reverse records that match. Now, for customer assignments, if a customer is large enough, has DNS picoseconds, delegate this assignment and get done with it.

Otherwise I think the wild card approach seems more promising currently. We do not have any DNSSEC employed yet, we do not have any zones signed and we actually don't intend to for quite sometime. It has to become the norm for us to employ it. So I think this is an initial approach on the subject for us and I would be really interested to know what other people are are doing on the subject and what do you think and how this could all work out.

So if you have any questions?

CHAIR: I'd like to take clarifying questions right now. And then give Richard a chance to present the application needs, again clarifying questions and then enter the discussion. Thank you. Next up is Richard Barnes.

RICHARD BARNES: So, hello, my name is Richard Barnes, I work for BBN and I come from the application layer. So I share a couple of Working Group in the IETF, they are dealing with a couple of applications that have a need for reverse DNS or something that hooks kind of like reverse DNS to make some new services happen that are working on. GeoPriv is one I'll talk about in particular, there is also one called Alto.

Some emerging applications that are being worked on in the IETF have an increasing need to ask the local network stuff. So, there is this knee owe location case, if I am going to try and place an emergency call, a 112 call over VoIP, I need to figure out what country I am in say or I need to figure what city and street I am in so they can send the police. If you think of all the people in the Internet, all the people I interact with over the Internet, who might be in a position to help me with this?

Well, my local ISP knows an awful lot about where I am. So, as a host, I'd really like to be able to figure out where a location server is for my local network so I can ask my local network where I am. So we have got this geolocation application where I want to find out a location server for my local network. Also in the Alto Working Group in the IETF, we are doing work on optimizing peer to peer network. The question in this case is if I am host, which peers should I be connecting to in appear to peer overlay to minimise the burden on the network I am using? Auto film connected to the Comcast network and there is 50 peers also that are close to me on the Comcast network, I might want to use those rather than some peers that are in, you know, China or in Germany or what have you. You know, to optimise my download experience, my peer to peer experience but also to play better with the local network, so there is a dual incentive structure here. So also in this case, I am trying to get information from the local access network. In this case the information I am trying to get is isn't location information, its rankings of IP addresses to say these IP addresses are better for to you connect to than these other ones. These will give you better service and impact and network class.

Again what we are doing in the IETF in both of these cases is defining protocols that you use to ask these questions from the relevant application servers. But there is an underlying need then to discover where the applications servers are that I should talk to.

So, when it's possible, we use DHCP as the starting point for this discovery process which is how we should be configuring hosts because using the configuration protocol. What we do here is both of these applications prefer is for it to get a domain name out of DHCP, a name that names the local access network where you can put records that describe URIs for the service ?? at service points. So, you know in that case, it's ?? there is no reverse DNS involved. It's just DNS. You pull out a domain name out of DHCP. You shove a query out to that name and you get back a URI. But as Costas I think noted we have got situations like now where customers are behind residential gateways, behind Nats, aren't getting DHCP information from their provider. The things like search prefixes you can get out of these can be really whatever the vendor wants them to be. We see lots of Cisco dotcoms and Westel dotcoms and things like that coming out of residential gateways. In cases like that, we need to be able to ask ?? we need host to be able to ask what is the right server for me to talk to for this IP address, because they can't get a name to ask for out of DHCP. How can we answer this question?

There is two databases that come to mind right now that are built to provide information about IP addresses. We have the WHOIS database. I can say who is this IP address and find out about it and affiliated things. So in principle we could put these server points on the WHOIS. But there is a little bit of weirdness about using WHOIS with applications. It's designed more as a sort of human facing database. So, this is ?? led these Working Group in the IETF and these application designers to settle oncoming back to the reverse DNS. So to find out about services that I need for my local network to find out about services for myself, I want to issue DNS queries, very verse DNS queries from my IP address. There is some tricks about NATs and finding out what my real IP address is. There is some open discussion about ?? if we are talking about IPv6, hopefully this is not a problem. But you know being conservative, yeah, we should be prepared I guess.

So there is some ongoing discussion about sort of the bounds of this mechanism. There is some caveats around things like NAT and what is my real IP address and how do ?? what IP address shall I be using for this?

But, you know, this is sort of high level approach that these applications are taking and ?? the previous presentation focused on PTR records which are you know the large application of reverse DNS, but you know if we are using this stuff for service discovery, the relevant records here are NAPTR records which allow us to specify a service that we are provisions and provide a URI. These are also different from the traditional PTR things in a they're designed ?? they'll be uniform across broad classes hosts you'll have the same location server or the same peer to peer optimisation server for an entire sub net or an entire ISP network. So, the dynamic generations and things like that, are a little bit ?? the requirements for those things are lighter here. Wild carding may be an appropriate thing, might be an easy way to address these things. You need to respond to these queries for individual addresses because hosts ?? you want to prevent hosts from trying things like tree climbing to try a /64 or a /56, to try and you know poke through the reverse DNS to find that.

I wanted to present those examples of how some applications are thinking about using the reverse DNS. Just going back here talking about these two specific things. One final note.

There is always a question in IETF work about how real this is. We are defining the standards but is anyone going to deploy them? I think in these two cases, especially, there is some degree of reality here. In the P2P optimization cases there is some real interest from Comcast and Chinese providers. They have done some tests and they have found they have been able to reduce their upstream band utilisation by double digit percentages for P2P traffic. And geolocation I mentioned briefly the emergency services case. This is very important and we may see requirements for them to support geolocations in the near future. I think that's all I have. I have reference to specific documents here.

CHAIR: Thanks Richard. So, now the floor is open for discussion. I stole the back mike, so please come to the front.

AUDIENCE SPEAKER: Hi, George Michaelson, I think it's really great to have this conversation. Because reverse is is at cost centre to the RIRs, we invest energy and effort in support it and tools to do it and the value proposition on comes up. So having people re affirm there is a volume proposition is actually a good thing. I know you kind of pose it had as a question but you also to some extent provided some statements there and I actually think there is a question that kind of floats in the air, the elephant in the room question: Is there a killer justification for DNSSEC in reverse? Is that magic combo of having absolute trust in what you are being told because of DNSSEC and that it relates to an IP address, some glue logic that maybe lifts reverse out of a vague, oh, it's kind of interesting, kind of nice, and takes it into a different place where it says, no, this is an authoritative statement. This is an authoritative statement about an IP address that is coming from the person who is delegated control over that address. I am wondering if this is something there that you could maybe riff on a bit, have a bit of a rap about.

In a less hippy sense, the other big problem from an RIR perspective about reverse, is the cost of the NX domain, we see, for us, a very high percentage of NX domain because compliance is low, and that has about five times the cost to serve compared to a valid answer. And in v6, that gets proportionately larger and the multiple delegation chain starts to have implications for the interested DNSSEC proposed pro providing information sets and the like. It has implicationings for us in terms of scaling. So if we are going to do reverse in v6 and we are going to propagate a sense that it has a value proposition, the compliance levels become a provisioning issue for us.

ANDY DAVIDSON: Just to quickly respond to that. I you asked do we need DNSSEC at all? Can we not these it as authoritative? What about responses in transit? And really, do we want to be in a situation where we are saying that we are not being to apply DNSSEC to, you know, we are going to create a patchy response in terms of some stuff we sign and some stuff we don't sign? I mean I understand there is additional overhead but I think this is part of a bigger problem about how you sign and how you manage your host resources well enough to be able to deal with issuing she is signed responses. Shane?

RICHARD BARNES: So, I do think, just responding to George's question about killer Aps, I hope there is some danger if not killerness about these two Aps that I mentioned you know. Alto peer?to?peer optimisation thing does have a direct impact on how traffic flows at least for peer?to?peer Aps and the early tests indicated it could cause major shifts in peer?to?peer traffic impacts networks and how it ?? how stressed your transit links are and things like that. It can have direct financial impact to ISPs to get this discovery right and if it requires reverse DNS to get the reverse DNS working right.

Costas: I'd also like to comment that RIRs have different needs than ISPs. If we have an issue provisioning all that stuff for our customers and we don't see any real benefit in it, then we won't do it, it's as simple as that.

Having said this, though, the wild carding approach I think seems to cover most of the cases discussed here. I don't know if you agree, Shane?

SHANE KERR: So this is ?? I'll start off with the disclaimer that I am a long time reverse DNS sceptic. I think largely reverse DNS is a waste of time and money for everyone involved especially for the RIRs as George pointed out bear a large degree of the burden. ISPs also feel it. That's my warning. Now I'll get into it.

Now, having said that, with picks and especially with DNSSEC, people you know there was this brief discussion about killer applications and we are at the stage now where for the first time I think in the history of the Internet, reverse DNS may become interesting and useful. It's a lot harder now because of the vast size of the v6 address space and because DNSSEC is a pain in the as, but in terms of certificate distribution and key distribution and ?? all of a sudden a lot of interesting applications are coming out. So ?? and so it's good that we are having this discussion, because reverse DNS is also an area that was long ignored. I mean this was a problem ten years ago with picks. But it was kind of ignored and hand waived away because it's kind of a solved problem. It's not a solved problem as we see here.

So, there was a discussion at the IETF, I guess a year or so ago, and the proposal was simply to say that as an ISP you don't have to provide picks delegation. This was shouted down. I don't know how many people that are in the picks actually run networks but they said this is a horrible idea, we don't want to say things like that. IPv6) I would be interested to see what network operators think about that proposal. Just a simple proposal saying IPv6 reverse DNS is optional. You don't have to provide it if you don't want to. I think that was the first approach. I don't know what the current status of that is right now.

I guess that's it. I think ?? another possibility that because we have reverse DNS hasn't occurred is there may be other ways to solve a lot of these specific problems. So, the use case for instance of having something in a tracer route that makes sense. That information doesn't necessarily have to come from the DNS. And actually DNS is probably one of the least efficient ways you can get that information but that's what we have today. If this is interest in approaching alternate ways to do those kind of things, I'd be very interested in helping with that, but I think you are going to get resistance if you try any of this because DNS is established and reliable and we all know it and love T I think we are kind of stuck with it. Anyway, that's it.

AUDIENCE SPEAKER: Owen DeLong. We are a network operator, we run a relatively network some of you may be familiar with T I think reverse DNS is fairly important to a lot of different things. We actually take kind of a different approach. We actually maintain a website where our tunnel broker users can log on and put records in to our name servers for their reverse DNS and we also, you know, allow them to delegate their reverse DNS to their own name servers if they want to through that same web interface. That's worked reasonably well so far. We haven't had a hot of abuse of it. And we have been pretty happy with the results.

I think wild carding makes a lot of sense for the NAPTR stuff that you were talking about Richard. But I don't think wild carding for static hosts makes a lot of sense. I am not sure you really need to provide a PTR record for every dynamic host on the planet especially the one using privacy addressing. I think that you just sort of accept the fact that those show up an annexe domain means that they dynamically allocated hosts most likely and move on. I don't see a problem with that. But for static hosts I think it is well worth having a PTR records in there and I think that things like mail and, you know, SSH and things like that are going to continue to perform poorly or break if it's not there.

Lorenzo: Personally I think that reverse DNS is on sort of unmaintained, it has Lame delegations and so on and it's only used by trace route and people doing geolocation and things like that. But on the other hand ?? could say to say: Also sending mail.

AUDIENCE SPEAKER: I think on the other hand, I think it is useful, it is useful for those applications. I very much like the dynamic DHCP tie and wild card approach because really that's the extent of the information you have as an ISP. And that's really the administrative boundary, right, and if you want to let them poke holes in it, that's seen better. So, I think that that would be ?? if we were looking for a kind of a best practice for a sort of residential v6 deployment, I think that would be a good candidate. It depends if you have the gear that the do it. For example if your DHCP server is in your BRAS you might not be able to do it, so ?? so, yeah, I look forward to that. The only question I have there is if you have, if you have a dedicated link for subscriber but you do want to support auto configuration because you want to support a laptop plugged into the wall that scheme won't help have you'll have to have essentially your routers talk to your DNS servers which is something that's not there today.

Dave: I just want to follow up on some these points quickly about reverse DNS use cases. Before this ?? before this week, I did a bit of research and I asked a few people and I post add mailing lists about matching forward and reverse and what it was really used for. And I got one real top answer here. And, you know, e?mail checking, right spam checking, it's queued in scoring great but there was one really killer application for matching forward and reverse and I am sure everyone can get what it is and it's IOC, because you connect to an RRC server and it doesn't ?? you present some phony, false PTR, and and you don't have a matching forward, then it won't display the name so people don't get vanity names and that was really it and nobody else could give me a better use case, so I find it quite interesting.

COSTAS: Also when there are aggressive users, if the MTA administrator is aggressive in its policy, then this is where it actually comes into play, but other than that, yes.

CHAIR: I am going to close the queues because we are approaching the lunch break and then we'll wrap?up.

AUDIENCE SPEAKER: I was thinking about the use cases that were presented, peer?to?peer and location and things like that, and I think you have to make a decision whether you really need per host information or per network information. I think a lot of problem here is that you sort of, you are going for the host information through reverse DNS and that's actually a lot of extra pain for, you know, for no reason in that particular application, so ??

RICHARD BARNES: The problem with thinking of the network level for applications is that if you are on a host, you don't necessarily know what network you are in. So you don't know what network to ask about. You only know to ask about yourself. And so, what you see is people trying to get at that, if you look at some of the documents, you see people trying to get at that by climbing through ?? removing labels, dropping labels off the end and climbing up through the tree. But you know that imposes a lot of extra query volume on name servers and thing like that. Especially if there is a lot of NX domains, wild carding I think answers a lot of these questions.

DAVE: Wild carding does open up another can of worms if you like. Because with wild carding, there is the temptation to say right for location information just create a big wild card at the top of our prefix and then anybody ?? because we are based in one country and the prefix isn't in this country. Anyone who is not here and mobile will poke holes. That means obviously you are not NX domaining where perhaps you should be if something is not supposed to be there or is not used.

LARS LYMAN: Regarding that ?? I should start out by saying I am a long term wild card Department I can, but nevertheless I see the virtuous of that in this context.

I nevertheless want to make a warning if is you wild card stuff at the network or prefix level and then you punch a hole for a PTR record you will rip out the functionality for any NAPTR or other record which is wild carded because the wild card is not per type. It's per name.

DAVE: If you punch a hole you have to punch a hole with all the correct resource types.

AUDIENCE SPEAKER: Exactly. You need to keep that in the back of your head. There was a rhetoric question in the slides, will it scale? It will scale, that's how it's built. And by specific design we put a period between every HEX character so it scales.

COSTAS: What do you mean scale, the wild card approach or the dynamic DNS approach? With all the updates coming from residential gateways and stuff?

AUDIENCE SPEAKER: Yes.

COSTAS: Have you done it? Have you seen it in practice.

AUDIENCE SPEAKER: It's scaled because you can do more delegation ?? so.

SPEAKER: You could have administration overheads though.

AUDIENCE SPEAKER: It comes to cost, of course.

AUDIENCE SPEAKER: But it does scale.

AUDIENCE SPEAKER: Also there was mentioning of using WHOIS for looking you have stuff like an and I don't think that's the way you want to go because that's a heavyweight and it's not well specified, so, that's where my question does scale come in and also you have a parsing problem too to get the information out there. I think that DNS is more efficient even though I can envisage having even more efficient ways to do it than DNS. But that would take designing new protocols and stuff.

AUDIENCE SPEAKER: Alex Man RIPE NCC. This is about DNSSEC and reverse DNS. Somebody asked me whether we could sort of host a solution also for DNSSEC with regards to reverse DNS. I mean, we do something similar for resource certification and we could possibly offer that. But I don't know what kind of a can of worms that would be and what kind of implications that would be. And I was just wondering how do you feel about a service like that.

DAVE: I'd like it. Well if you offered it, I'd take it.

AUDIENCE SPEAKER: Okay.

CHAIR: Okay. So thanks to the audience for the discussion and thanks to the presenters and all their efforts. I guess it's time to applause.
(Applause)

CHAIR: I'd like to add one or two remarks and try to sum this up a bit and probably make it a kind of actionable thing for the group.

With another hat on, I'd like to point out that the Internet drafts that were presented by both Richard and Costas are that, it's Internet drafts, it's work in progress in the IETF so with the exception of the one RFC there is nothing officially published yet, it's work in programme and most of them were so?called individual submissions, the status is it's suggestions to the Working Group to consider this work to go forward. Which, for this audience and anybody else, means there is still time to participate in the discussion and steer the outcome. And part of the exercise today was actually to give some of the ideas operator exposure and collect some feedback and encourage people to watch, look at these documents and read them.

And just out of curiosity, the main document, and Shane made a reference here that there was an attempt to get a carte blanche from the IETF so to speak on giving up on reverse mapping which the IETF of course is neither able nor willing to give because nobody would listen anyway the updated version is exactly what Costas and Dave based their work on, or part of their work on, the draft?Howard reverse DNS and so on and so forth.

How many people in this room have actually read that Internet draft? 10 or 15 roughly. Thanks. So, we probably want to consider this topic further in the upcoming future and maybe in future Working Group sessions. It's kind of, the question is: Can we as a Working Group do something about this? And we have discussed this among the chairs and it seems that there is no clear way forward one way or another because we have seen various interesting ideas about how the DNS reverse mapping could actually become useful and maybe as Shane said, for the first time in history, as well as there are definitely operation hurdles or challenges to overcome here. We'd like to collect more feedback and come up with safety requirements ?? we are not yet sure that we really can came at a document but maybe a short list of things that we would like to have people agree upon. Again with another hat, we know it's very hard to reach agreement about anything reverse DNS, that's the reason why one of the attempts in the IETF to have a document on that kind of failed. So we will not repeat that exercise but we would like to concentrate on this issue for the next month plural or so, and if anybody has any other suggestions please find us in the hallway or take it to the list, we'll try to keep the discussion going there and come up with some list of issues and maybe conceptions or perceptions that need to be addressed.

With that, I'd like again to thank Costas and Dave and Richard for bringing this up and working on this. Thanks to you for participating in the discussion. Thanks to RIPE NCC and AV staff for supporting this and especially thanks to the stenographer for following the heated debate and lively discussion.

With that I guess it was time to conclude and say good?bye and see you in Amsterdam.

(Lunch break)



LIVE CAPTIONING BY MARY McKEON RPR

DOYLE COURT REPORTERS LTD, DUBLIN, IRELAND.

WWW.DCR.IE