Paul Rendek opened the regional meeting and welcomed the attendees. He thanked the host, RU Coordination Center and the sponsors and introduced the RIPE NCC staff and the RIPE NCC Executive Board.
Opening Keynote
The RF Ministry of Telecommunication and Mass Media welcomed the attendees to the 7th RIPE NCC Regional Meeting in Moscow and congratulated the attendees on the upcoming "Internet Day", held on 30 September. He continued that, every year, this meeting brings together more and more people and creates a lot of interest throughout Russia among engineers, ISPs and those responsible for infrastructure maintenance. He said that the future of the Internet depended on the attendees to establish services. Now, the Internet is involved in all the aspects of our lives. The Internet brings us closer together and these meetings are an excellent example of self organisation. He added that the exchange of opinions can help to understand how the Internet will be developed in the future and experiences can be shared between global players and wished the attendees a productive meeting.
Q: Is the ministry planning to initiate the mandatory implementation of IPv6 for government sites?
A: The state is not going to regulate this. As far as IPv6 integration is concerned, not everything is clear yet and the recent Russian Internet forum proved that. Nothing specific was said about the advantage it gives to the user and no assessment has been made as far as practical aspects are concerned.
Keynote Presentation:One World, One Internet: A Historical Perspective
Elise Gerich (IANA)
Q: This year, the IANA, and the rest of us, deployed a new technical process for DNS management - DNS signing. I have the feeling that it improves trust as the reaction from people and governments is now slightly different. Maybe you can review some other technical processes in DNS route management? This is a proposal.
A. With DNSSEC signing there are two keys. The IANA generates one and, based on what we generate, Verizon implements the other. There are two parties that have to be involved. There is a page on the IANA website that has all the documentation about what was done for signing and what the processes were. There is a document called the DPS, which we had public comment on, and this document shows what was done for the signing, step by step.
Q. What can be done to improve transparency and trust, not only for DNSSEC because now there are no issues, but for historical purposes.
A. We have published the affirmation of commitments which talks about transparency and there is an open and public forum to discuss issues. We'll try to make sure the things we do in the future also follow this.
Q. Regarding IANA functions: There are a lot of different functions and not only the IANA executes IANA functions. This seems to sometimes create separation. I am interested to know how we can split and modernise this system.
A. It depends if you are referring to something that is broken that you'd like to fix or is whether it's a hypothetical situation. If the former, I'd like to know what you think is broken before I can offer a solution.
Q. You spoke about the affirmation commitment. There is a primary contract, the contract between the US government and IANA. I view the role of the US government as a guardian of the safety of the current Internet infrastructure. Do you think there is a possibility to change the role the US government plays and should this contract ever be reviewed? Is this contract necessary?
A. There was a transition period. There was a time when there was no more National Science Foundation investment. ICANN and the IANA function have a similar history because the IP addresses, the DNS and the protocol parameters were funded under the department of defence. At the end of 90s there was an MoU written between the government, the ISI and ICANN in order to start transitioning the intellectual property that had been developed by the contractors at the department of defence. The MoU allowed for these things to be transitioned to a non-profit organisation (ICANN) with an oversight from the IETF and the Department of Commerce.
Q. Who owns the intellectual property?
A. It's not a question of ownership now as the MoU tries to make it clear that these are global resources. Even when it was being developed with government funding it became clear that it would be a public resource and there have not been any real restraints on how people can use it. We wrote a proposal that became RFC 1466. This said that we do not need to have such tight control over the allocation of IPv4 addresses. There was a proposal that this global resource should be allocated from the IANA and, at this point, the IANA would still be the holder, or the steward, of the IP addresses but the regional registries would be responsible for seeing where the needs were in each region.
Some of the IPv4 address space was reserved for developing regions of the world, some was allocated directly to the RIPE NCC, to APNIC and to LACNIC. It was documented and I don't believe that there was any intent to exert ownership over address space. It was seen as a resource for global expansion of communications. This is the same model that we have today: the IPv6 addresses, the DNS and everything the IETF develops is a global resource.
Q. So it seems that the invention rights belong to the US government but the use rights are free.
Paul Rendek thanked IANA and ICANN. He explained that when the RIPE NCC asked who participants at the Regional Meeting Moscow wanted to see on the agenda, they asked for the RIPE NCC's industry partners and representatives from the international Internet community. Paul gave some further information about the IANA contract and explained that the RIRs are watching the situation closely. The RIPE NCC attends various governance meetings and speaks with multi-stakeholders and they all ask about the IANA contract. It is a hot issue for us all and we'll keep you informed.
Presentation: IANA update
Elise Gerich (IANA)
No slides used.
There were no questions.
Presentation: IPv4 An Interesting Future
Rob Blokzijl, RIPE Chair.
Questions were deferred.
Presentation: РФ-domain
Andrei Kolesnikov (Coordination Center for TLD RU)
[Awaiting slides]
Q: Do u have any statistics about the number of DNS requests to the .rf domain? How many people access the .rf domain on a daily basis?
A: I have the statistics but I can't give you the details immediately. Out of 18,000 domains, 6.5 are delegated so about 30%. I can't give you the number of referrals. We will soon do some more advertising because we need to make sure people understand that they have to type in Russian characters.
Q: If someone registers domains in the .rf zone, do you follow the further development of these domains? For example, if you enter sex.rf, it is a closed community but the domain is registered to a company that makes bags. It has no relation to bags. What if someone types weather.rf and suddenly enters a site with who knows what on it?
A: This is not a question to the domains but a question for those who deal with trademark registration in the Russian Federation. In some countries, there is a procedure for checking how the trademark is used. We don't have this in Russia. As the coordination center, we are involved in the registration of domain names and we are not involved in content. Your question is valid, but it's not a question I can help you with.
DNSSEC Panel Discussion
Presentation: A First Look: The Impact of the DURZ Rollout
Wayne MacLaurin (OARC)
Q. What's the ongoing analysis of the DNS at the moment now we are signed and as we add more TLDs?
A. We got huge data sets from all the roots. Most of the root server operators and cc-TLDs participated. We are still collecting the data and are already doing analysis on it. What we choose to answer depends on who's funding us and what we are looking for at a given moment.
Presentation: DNSSEC.cz
Ondrej Filip (CZ.NIC)
Q. Can you explain what you want to achieve by using DNSSEC? There are a lot of discussions about how to use it in practical terms.
A. What we are trying to achieve is to start a process inside the IETF to include more information about DNSSEC. For the first time we have an authoritative database that is secure and used by all countries in the world. It's a good opportunity to put some new data into it. Some data we think would be really useful is certificates for SSL transfers. It's useful because for the price of a domain, you'd get more additional services, like certificates.
Q. Are the majority of registrars doing this for their End Users? Or is the End User doing DNSSEC?
A. There are certain companies, like banks or large portals, who are running their own DNS servers so there's no way the registrar could sign the domain for them. The registrars are signing the domain for the End Users that are using their DNS service. There's also a group of important End Users, such as news portals, that use DNSSEC who do it their own way on their servers.
Q. cznic has a lot of cool tools relating to DNSSEC. If someone wants to get them translated into their own language, who should they talk to?
A. Come and talk to anyone from cznic. We are very happy to help you and to spread DNSSEC and cooperate with other TLDs.
Presentation: GOST Cryptoalgorithms in DNSSEC
Vasil Dolmatov (Cryptocom)
Q. Are the algorithm applied only in the Russian Federation?
A. In DNSSEC it's difficult to apply the algorithms everywhere because the standard was applied in July this year. Only two months have passed since then. .ru and .rf are not signed yet. Unfortunately, this process was slightly delayed, partially due to the .rf start up.
Q. Which organisation audited your code?
A. Which code?
Q. The code used to build patches for your DNS servers that support GOST.
A. It was built without any patches from our side. The patch was published and you can edit it yourself.
Q: Vasil forgot to mention that there are three RFCs that describe all the algorithms. And don't forget that the algorithms are public GOST documents and are open. You have your own position and point of view but how should we in Russia realise DNSSEC?
A. The same way as it is realised as all over the world. Thanks to the developers of DNSSEC, we can use different algorithms.
Q. We could have had a more complex, more hierarchical structure but we chose to build a hierarchical system with one route. Do you think we should sign everything with GOST or do you see a mixture of algorithms in our tree?
A. Currently in DNSSEC there is an acting algorithm and other countries have shown interest so why should we limit ourselves with solutions based on a mix of algorithms and transition from one algorithm to another because of the Russian framework.
Q. It's a good option to be compatible with the rest of the world because it is a question of validation outside of the boundaries of Russia. Unfortunately we are not able to change Microsoft or Chrome and everything else. Why don't we use GOST only for signing the state domains.
A. If we follow law, then in a number of cases it is necessary to use certified realisation which must be by GOST but from the other side there is no prohibition of the use of any other algorithms.
Q. That is what I am asking. When it is required, we can use GOST as we have to follow the law. But don't limit everyone else to using this algorithm. I don't see a problem with signing with RSA for example.
A. I cannot comment further on these kinds of questions.
Q. You have mentioned your product which, in a number of cases, must be used. What is the approximate price? Secondly, we are are in Russia and we all understand that in a number of cases we have very unusual situations. Can you be more specific on which occasions these situations might happen. For example, if I have signed my domain by RSA and not GOST will someone come and arrest me in the middle of the night?
A. The product mentioned here costs approximately RUB 30,000 per sever. I cannot give you an answer about your second question because Russia is a very unpredictable country and as it is well known, from one side, the strictness of Russian law is compensated with irregular execution of it. At the beginning of this project, the objective was to give a tool so that if there would be some requirements, we could easily switch without losing anything, without rebuilding anything, without making a separate DNS which would go to another place and not the root zone and make a 'Great wall of China' in the Internet. This was the objective and we were able to achieve it.
Q: What is the future prospect of implementing GOST in Microsoft?
A: When we were at the beginning of implementing GOST into the DNS they said no. Understand that the cycle of development in Microsoft is a very long one. We had an option about how these products could work in a virtual machine on a server. Until things with Microsoft work properly, users should not install it. There are several other systems.
Q Regarding the concern about multiple algorithms, I'd like to point out that the algorithm used to sign the root zone is quite new. In fact the first implementation only appeared in January 2010. There is already more than one cryptographic algorithm in DNSSEC in wide use. Adding another one is technically not very difficult.
Presentation: ISC, BIND, DNSSEC
Shane Kerr (ISC)
Q. We use SNS and it works, thank you. You mentioned that the DLV is going away but in my opinion it is still very useful for the test bed. Could you comment on this?
A. There isn't a specific date when we plan on removing the DLV registry. The DLV registry still serves an operational purpose for anyone whose parent zone is not signed. So, until many more TLDs are signed, we'll still keep DLV in service. We don't plan on keeping it around forever but you can expect it to be there for several more years. If there's a need for a test bed, maybe we can discuss setting that up as a separate service as well.
Q. Thank you. We intend to use that as it is pretty much ideal.
A. The code is open source. You can run your own DLV registry if you want.
Moderator: There are currently 20 TLDs that are signed and in the root. There's a lot of TLDs operators that are in the process of signing so we are going to see a lot more signed so it's going to become less and less of an issue that your parent is not available. Shane, what is the release schedule for BIND 10?
A. Bind 10 is a five year project. We are currently just past the half way point of the second year. In six months we are going to be releasing our second yearly drop which is going to be the implementation of the recursive server. Our intention is that by the end of year three, you will be able to run the code as a general purpose server. So there's about 18 months until we consider it ready for general consumption. We are an open source project. You can download the software today. We just made a release a week and a half ago. You can download the latest code from our source code repository at any time. We don't recommend it for general use but if you are interested in the functionality you can start experimenting today.
Moderator: If we look at NSD and Unbound, you decided to separate out authoritative versus secondary servers. Has there been any consideration of that in BIND development or is it going to be everything together.
A: Yes. The design for BIND 9 is that there is one piece of software which does everything. There's basically no customisation needed. If you don't want to use a feature you can turn if off via configuration but the software still implements it. BIND 10 is designed in a much more modular way. The way the software is written right now, you can run an authoritative only server which doesn't implement any recursive features. We are also currently implementing a recursive server which implements only the very minimum authoritative features. It turns out that it's very difficult to implement a recursive server that doesn't know anything about authoritative. So the intention is that you will be able to split the authoritative and recursive side. If you have a server that only acts as a secondary, you won't have to include any of the code that acts as a master, and also the other way around. If you don't do any dynamic DNS updates, you won't have to run that code. So we are hoping it will be highly customisable.
Q. A question for the panel: DNSSEC improves the security of the DNS and at the same time introduces some new moving parts and sometimes, those moving parts do not work as expected. Does DNSSEC make DNS more fragile or are those just teething problems?
A (panel). Maintaining a DNSSEC signed domain is a bit more complicated than just maintaining a normal one and in that sense it makes the DNS a little bit more fragile. On the other hand you are saving a lot of the problems that appear without DNSSEC so yes, it requires better operators but it secures DNS so I think that this makes it more robust.
A (panel). I think the main problem with operating in a DNSSEC world is that you have to treat the data you are administering a little bit differently. In the past, zone data was static, it never changed unless you were explicitly changing it. If you want to run a DNSSEC system today and do not want your administrators to spend a lot of time on it, you have to allow some automatic functions to happen, which means that you have to trust your system to do its own thing. It's a change of mindset and a change in the way of thinking about how DNS works. I think once the tools have matured slightly and once people start thinking about DNS in the right way for the future, I don't think it will be any more or less unstable than it is today. One slight difference though is that currently, a lot of things are broken in DNS and no one notices. I think that DNSSEC is going to make a lot of things that are already broken visible. I don't know whether that is good or bad.
A (panel). I will use an analogy. For example, in a car, when air bags were first introduced, they didn't always work properly and there were many problems. Over time, technology improved and now, we don't see cars without this safety device. DNSSEC was launched several months ago. I believe that it will take a certain amount of time and some people will come out with problems at the start but afterwards it will work smoothly.
Moderator. The hard part about DNSSEC has nothing to do with DNS; it's key management. You cannot be sloppy about the way you manage keys. It take work and a lot of processes. Key management and key generation is much more complex than DNS. DNS is probably the simplest protocol out there, without DNSSEC. The registrars and the registries are doing a lot of that work and I don't see the typical End User being able to figure this stuff out. We as an industry have to do this for them. A question for the panel: what are the challenges to DNSSEC deployment.
A (panel). I think there has been a lot of work on DNSSEC and many people have contributed to all the RFCs etc. The challenge that DNSSEC is now facing is how to bring it to the End User. It's beyond the technology now. The technical people have done a great job and now the administrative and marketing people need to step in and continue.
A (panel). My only real concern would be the magnitude of a failure. I think that if we break it, it might be harder to fix.It might be hard to figure out what is broken, especially in key management. In DNS, if you had to, you could hand edit files you could cobble together something that worked. We may lose that but I don't think we'll know until we have our first significant failure. If it is something like .sc losing the zone or .de did the same thing a while ago. I am not sure what that failure will look like but I suspect that it will take us longer and will be harder to fix when it does break.
A (panel). An area that has not been mentioned in terms of challenges is that the existing model of a lot of TLDs is the registry-registrar model. This does not match very well with the way the DNS has been designed. The people operating a name server can't talk to the registrar directly today. This, at times, causes problems because if you want to change where your DNS is hosted then that information needs to be updated in the registry and the people doing the hosting have no contact with the registry at all. I think it's an unintended side effect. I don't know if there is any technological or procedural solution for this.
Moderator. Assuming you have somebody knowledgeable doing the signing, it is purely a procedural matter to get the registrars and their registrants - the people with the names - to a situation where they can go through their registrar and make the changes, just like they would for an NS record these days but now you've got more records. I find the hardest part of it is how they are actually managing those keys themselves. At this moment, you are completely right, a lot of the registrars and the registries are not set up to do this.
A. I do not speak on behalf of .sc but I do provide service to .sc and to come back to the question about the .sc failure, it had nothing to do with DNSSEC. It was a complete manual failure. It wasn't even a system failure. It was an operator failure. It is true that DNSSEC took longer for them to generate this zone but the actual outage time had nothing to do with the extra ten or twenty minutes it took for them to regenerate
this zone. It was purely operator fault.
Moderator. This is a good point. When you see some of the things that go wrong and with us changing to a new technology, people will blame the new technology without any information. So, you are going to see stories that something broke in the zone and they implemented DNSSEC even though these things may be completely unrelated.
A (panel). I will support the thoughts expressed here. The main problem that I see currently are the operational problems and the issue of transferring the information from the DNS operator to the higher level zone operator as there is no direct link between them. So the domain administrator is involved in the process. They receive some numbers which they then have to transfer and undertake the responsibility that they have been transferred properly. The domain administrator and the domain owner do not understand what has happened and they will never understand.
The hope that we will be able to educate all the users about what a DS record is and how they have to transfer it is a utopia. We have to think about changes to the business processes related to registration. One of the possible options is that the administration of DNS zones could move to registrars because they are already in the same chain and can support keys. They already have a legal relationship between each other and mutual responsibilities. If DS records are entered into the zone by anyone, this will lead a large number of faults. A second very important idea is key management. DNSSEC is not such a unique concept, it's just first. For example, without VPN, nobody can exist. It's the same with key management and certification management. We are now in an era with encrypted Internet and many things are required to work with keys.
People don't have the experience of doing it so they have to gain that experience. This is going to be the main problem.
A (panel). I want to talk to anyone in the room who is getting scared about key management. You don't actually need to make changes to the key management process if you're happy with the level of security that you have today. So if you just want to sign your zones and you don't want to use any kind of hardware security module or other special encryption, and you trust your administrators, then doing DNSSEC doesn't really involve any new processes. The tricky part of key management is if you actually want to increase the security then it does take additional processes and technologies which means you will have to pay more. But it's nothing to be scared of if you don't want this stuff.
The moderator thanked the panel. He closed the session by pointing out that DNSSEC is here, it's a fact of life now, and it's being deployed. We are going to have authenticated DNS and this is a good thing. It is one protocol, a small but very important step.
Lightning Talk: DNSMON
Mark Dranse (RIPE NCC)
Q. I have been using DNSMON for many years. Is anyone going to talk about the new probes?
A. I think it is covered in the Labs presentation. To clarify, the new probe is covered on RIPE Labs in detail if you want to read about it. It is a concept for a much broader measurement network. TTM at the moment extends to 90-100 probes. The new RIPE Atlas network could extend to tens of thousands to hundreds of thousands. DNSMON at the moment is based on the TTM network. What RIPE Atlas will contribute to that in the future we don't yet know.
Minutes from day two and three of the Regional Meeting Moscow will be available shortly.