These are unedited transcripts and may contain errors.
DNS Working Group
Wednesday, 15th of May 2013 at 11a.m.:
PETER KOCH: Ladies and gentlemen, may I kindly ask you to focus your attention to the stage and slightly, slowly, sit down, open your laptops, start reading e?mail. Could the people in the back be so kind and close the door. Violently. Thank you.
So welcome, welcome to the first session of the DNS Working Group at RIPE 66. We are going to have two slots this time, again. But I will come to that in a minute.
First of all, a round of introductions, my name is Peter Koch, I am one of the co?chairs of the Working Group, the other two co?chairs are Jim Reid in the front and Joab in the other front. If you have any things to raise, any suggestions, complaints, gripes, whatever, please approach us. You can spot us either because we are like the old farts, or because we have these fancy yellow badges; when you get old, you see everything in yellow. Anyway, we have a Jabber scribe for the meeting, that is Kaveh Ranjbar who is running to the back right now, and Marco sitting in the front is doing the minutes, so that is two RIPE NCC staff, thanks for that.
If we do have remote attendants, we'd appreciate the occasional audio check and for those in remote attendance, if you want anything to be relayed to the microphone, please relay to that the Jabber monitor.
For their benefit, anyone in the room, please make sure if you want to add or comment anything, come up to the aisle microphones and if so you wish, your affiliation.
That is mostly it. To that extent. We are going to have two slots, this is the agenda for the time until lunch. That is basically four presentations as presented there, all the slides are uploaded, you can download the material and look at it at your laptop if you so wish. And let me go through the rest of it. Anyway suggestions to, any agenda bashing, anyone desire any changes? Review of action items. That is probably an easy one. We do not currently have any open action items so there is little to do but we might want to see something different at the end of the second slot. Mentioning that, there is a slight change from what we have been doing before in the afternoon slot, we are going to have the ENUM report in this Working Group because the ENUM Working Group itself doesn't meet here in Dublin. It hasn't been decided yet whether that is a perpetual change or is going to change back again. So, just stay tuned for the ENUM stuff.
If you have any suggestions about topics you want to see, either here or in the plenary or if you have topics you do not want to see, please let us know and you can do so by approaching us, by sending stuff to the mailing list or to the Working Group Chairs neither private or to our DNS?WG at RIPE dot necessary address. So with that said, I'd like to invite Stephen rut enfrom SIDN, and he is going to give a presentation about SIDN's experience with rate limiting.
STEPHAN RUTTEN: Good morning. My name is Stephan Rutten, I work as a system administrator at SIDN, foundation for Internet Domain Registration in the Netherlands. So we host dot NL zone. And this talk is going to be about abuse we received in last couple of years and months and increase in abuse in DNS traffic.
Up until last year, we did not do any rate limiting, we didn't want to do any rate limiting, we just wanted to answer all queries that were coming in. And last year that changed because the traffic we received also changed, and that is what this talk is going to be about. So I am going to talk about the rise in abuse of DNS traffic and what we did to fight off this abusive traffic to at least not have all the adverse effects of it so that our production does not, is not interrupted and that third parties are not receiving any nasty traffic. And later on, I want to talk a bit about what we are working on right now to improve our service to our customers.
So, in 2012 we saw an increase in any traffic, I think a lot of people probably in the room have seen an increase in any queries. Anyone here not familiar with these kind of attacks? Everyone knows about this. OK. And who has experienced an increase in any traffic last year? Quite a lot.
So, but what happens with these, just to give a quick summary of it, what happens is you get a lot of any queries in our case just any queries for simply for NL, not for anything else, not for any sub domains but just for NL and in quite a huge numbers and the queries that are sent are about 20 bytes and traffic that gets back is about 2 K so we have amplification factor of about 100 times and the traffic that we received last year was, it could have been a lot worse because they could have enabled DNSSEC, so the RD bit on it and then the amplification factor would be almost 200, so we were lucky that they didn't do that, probably didn't know, but what the effect would have been if they would have enabled that. This is a picture I like to look at because this is actually what happened last year, you see at the beginning you already see a lot of ?? this is all any traffic, all this green stuff on the left is already unusual traffic, so something was already going on but it didn't bother our systems, we had no trouble with it; it was just our traffic and you get weird traffic coming in. But then in, about the 21st of June, this traffic spiked and, well of course, we didn't really like that because it's not really, it was definitely not traffic that could be of any use, and it was all directed to certain parties that were getting all this traffic together and in an amplified form and they were receiving denial of servers attack through our servers and that was the reason for us to change what we were doing up until then until we started to looking into what can we do to get rid of this trouble, and what we learned from that is that, it was really helpful to have a good contact with Peter, with our people that are doing the same because we weren't the only ones receiving this any traffic or a lot of people that were seeing this, a lot of parties were seeing the same kind of thing, so what helped us a lot was that Steffann made a little script that enabled us to generate some real quick firewalling rules in IP tables using U 32 module in IP tables with which you can just look at inside a packet and see if it is, for instance, in any query, so it is in this case, and these were any queries for dot NL so we could just make a rule for that and the effect that have you can see right after these spikes, you see that once the attackers probably found out that something didn't work any more and the traffic was simply gone and you see a little trial after that, but well, it was quite effective so we have ?? we were quite happy. But later on the incoming traffic was still abnormal, it wasn't really a problem, you see a number of like 2006, some peaks over there, about 10,000 queries on our Unicast name servers, that is what we are looking at right now. But was wasn't really a big problem at that time but still something was up and was not the way it should be. Then, next incident that we had major incident that was we had any traffic directed at our secondary named server so it wasn't for but for other zones and this was on a cluster of systems which were running FreeBSD and open BSD and we simply ?? there is no IP tables, there is no U 32. So what we did to make sure that this traffic wasn't really bothering the production of this name servers, was just limiting the traffic but that meant we also had to throw away that traffic so we weren't very happy with that so the solution we came up with was to replace this cluster with new Linux based cluster, so we have ?? so we could could use the U 32 filtering in IP tables. Are any people here running FreeBSD or open BSD on name servers? Do you have any other solution toss fending off this kind of abusive traffic?
AUDIENCE SPEAKER: Things like double NAT.
STEPHAN RUTTEN: What we did at that time, we build our Linux cluster and used IP tables on it and when we saw more of this traffic we also implemented RRLs in BIND and also in NSD name servers. And, well, from that time on we haven't seen any new, any traffic not on the NL zone, we haven't seen any traffic coming back in. So, to be able to always have our production able to reply to all queries that are coming in, what we are doing right now is we are increasing our Anycast name servers so we are rolling out Anycast name servers at the moment. We have installed a new one this week and another one is coming up real soon. And what we are doing there is that we are deploying these at our, at sites that are great users of the dot NL zone like big ISPs and so if there is any abusive traffic that is only ?? it will only be concentrated on that one location, and any other locations will not be affected on that. And the other thing we are doing is we are increasing our monitoring, so the ?? because that is the first thing that happens when some strange traffic is coming in, something that is unusual. And that is the way we hope to be ready for the next big one because it's not a matter of if there will be another way wave of nasty traffic, but the question is when it's going to happen. And this small overview is probably not, you can't really read it over there, but what you can see here is we have about 30?plus checks on all our name servers so we want to be able to see exactly what is going on, so we look at simple things like the hardware, of course if the hardware is running all right. But we are also looking at the number of end queries coming in, and number of AMS?IX queries because we see a lot of spikes in strange AMS?IX queries from all over the world and well this is something that is increasing all the time, we are just adding checks so we know exactly what is going on on our name servers at all times. And, well, this is a view of this week when it's simply the normal kind of traffic, you see some strange spikes like these, simply something that is going on all the time, we have ?? we have strange new traffic coming in and as long as it's not a problem we don't have to react right away but it's good to know exactly what is going on so we have seen some strange traffic increase in TCP traffic this week in a regular ?? with regular intervals, you can see it in this because this is just looking at the unicast name servers and number of queries per second and but if you look at what ?? the transports of these queries, how they are being delivered over UDP and TCP we see change new blocks of traffic coming in, maybe you have seen something similar. I suppose it's not very unique for our zone. But well, you see this traffic is, the normal traffic with the rate limiting implemented so we are constantly limiting traffic and that is basically what I wanted to tell you about, so what happened over at our zone is probably not unique. So if you have any comments on that or something or another solution, implemented, I am very interested in hearing your experiences with that. So if you have any comments on that, please let me know. So, if you have any questions, then please, ask.
AUDIENCE SPEAKER: Thanks for that. I have two quick questions one: Do you keep IP tables in RR L in place at the same time?
STEPHAN RUTTEN: Yes we do, at the moment we do.
AUDIENCE SPEAKER: What is your response in case you see the next big attack of suggest don't expect?
STEPHAN RUTTEN: Well, at that moment we are going to look at what kind of traffic that is, so I can't really say what the response will be, but we will have to form our team and do some analysis on it. What we are working on right MoU is to create some triggers for (now) monitoring so when traffic is unusual, when we see unusual traffic coming in that we immediately make a TCP dump of the traffic so we can analyse that later, but we are all going to have to simply look at what is coming in, what kind of traffic we are getting at that time, so I can't really, at this moment I don't know yet.
AUDIENCE SPEAKER: OK, thank you.
AUDIENCE SPEAKER: From RIPE NCC I have a question here on chat: Any plans to direct all any queries to TCP?
STEPHAN RUTTEN: Any plans to.
AUDIENCE SPEAKER: Direct all any queries to TCP?
STEPHAN RUTTEN: No, not of yet, but it's obviously something we could think about.
ANAND BUDDHDEV: Of the RIPE NCC. I have a question about your usage of BIND with RR L. The dot NL zone is going to be mostly referrals, I mean will have many delegations so did you notice rate limiting for referral responses and if so, what did you think of that?
STEPHAN RUTTEN: Sorry, I can't answer the question. Maybe some of my colleagues want to comment on that but I don't have any answer on this question.
PETER KOCH: What you asking for is what the false positive rate is?
ANAND BUDDHDEV: That is what I meant, yes.
AUDIENCE SPEAKER: SIDN. We do see false positives, but they don't affect the regular traffic that much so we are still tweaking with the slip rate to see if we can, if we can bring that down. As as far as the referrals are concerned, we do see them but it's not supposed to be traffic this is on our name servers anyway.
PETER KOCH: Any more questions? Nobody. OK. No more questions. Thanks very much.
(Applause)
And before ?? before I invite Marek to the stage, I must admit that I violated the process by not asking the audience whether you had read the minutes of the previous RIPE meeting, so the DNS Working Group meeting minutes, well, not that previous but 65, they were submitted to the Working Group mailing list. Did anyone read the minutes of RIPE 65 DNS Working Group session? OK. Of those seven people ?? thanks ?? any objections to call them final? That is not really asking for approval, but I do it that way anyway. Thanks. I think we can declare the minutes final then. And that brings us to Marek's presentation, Marek works for CZ.NIC, the top level domain registry for the Czech Republic and we will talk about Knot.
MAREK VAVRUSA: Good morning everyone. I am working for the CZ.NIC, and I am not going to tell you much about new DNS release as just one of the features we prepared and that is a recent struggles with zone file parsing. Knot DNS is a little piece of DNS software which is basically another name server alternative like you can put it on master or life server. In my free time I usually enjoy cat videos on the Internet. So that is much about me.
Why another ?? parse business. How many of you have needed a zone file parser? I guess it is not much. So, what I am ?? what I wanted to tell you in this presentation is why should you care even if you have something that sort of working okay?ish and what are the options you can take? And what did we end up with? So we had this almost classic combination of flex for flexico analysis and Bison for parsing which has several upsides: For example, you can find it on almost any platform, it's proven by time and stuff like that. But it's also kind of lacks performance and it's awkward to work with. I am not telling it doesn't have a pure parser option, but it's sort of awkward. So we were in a position that we either chose something new or stay with the same layout and use slightly modern tools like the R2C and lemon for parson, or be brave and try something new. My usual preference is to handwrite in C and zone file format looks easy enough, right? Well, it turns out it's not the case. It has so many nooks and crannies in it. If you look at the name authoritative pointer, you can write really weird stuff in that. When we thought about that and figured that it wouldn't be so maintainable in the long run to write everything can see and the other thing is the generated parsers have come a really long way since the beginning, and they are harder and harder to beat with handwriting code.
So, we decided again that we could try something new, maybe it wouldn't be almost everything do it ourselves, and discovered this thing called Ragel, so what it basically does is it takes regular language description and turns it into state machine. So far that's worked like the other scanners do, like the likes R2C, it also does a little bit more. You see regular languages have a great weakness, for example the famous problem when you want to match the number of nested parentheses, so the regular language counsel, so this is different this things called actions which enables you to execute arbitrary code on every state transition, where you execute the action when you consume, you can execute code on each of the character. For example, it solves the parentheses problem, when you read the open parentheses, you increment the pointer and with the closing parentheses you check if it matches. So, that is one of the great things in rage he will. Then we discovered we don't really need a fully context free parser on the zone file so the rage he will would be really what we just need. It also has so many great details about it, you can generate so many different state machine implementations like table driven and stuff like that. You can visualise the state machine with, if you wanted to just ?? if you are interested, they are ready good.
So, what we have done is we kept all the features that we had like pretty much every used record type, custom types, things like raw data write out, the directives, like include in TDL and even the special escape sequences and stuff like that. We also designed a very thorough testing suite for it covering each possible corner case, invalid inputs, stuff like that. And at the beginning our major beef with the flex and Bison driven parser was the performance so how does the rage he will one perform. Well, we used to tackle this problem by separating from the zone loading phase, you don't have to compile over and over again because it was slow, with the rage he will based parser, the parsing and loading time is about a quarter of what it was when we compiled the zone and loaded it separately. So there is no need for the zone recompilation step any more so it's great for the users and us as well, when you have incoming zone updates or dynamic updates you always had to push out the full zone text file and also the compiled zone file and you had to track whether, I don't know, whether the serial changed or whether the file got corrupted and stuff like that. So, I think that about concludes the presentation. I hope I made the choices clear, if you want to play with the parser we have created it's part of the Knot DNS source code, it should be presented in the ?? it should be coming out soon. You can check out on our website, if there is some interest you could also release it as a separate project. That is about it, thank you and if you have any questions.
SHANE KERR: From ISC. So, how tweakable is the behaviour of the parser because if you go through the spec there is a lot of ambiguity and things like that, can you change the behaviour or is it fixed right now?
MAREK VAVRUSA: I am not sure what you mean by tweaking the behaviour. It parses everything it throws at it.
SHANE KERR: There is a couple of different errors in zone files and may or may not be errors depending on how you interpret the scrolls standards.
MAREK VAVRUSA: It parses the syntax, it doesn't do anything about the semantics.
SHANE KERR: OK.
PETER KOCH: Shane, were you referring to the leading 0 digit stuff?
SHANE KERR: All kinds of stuff, yeah, yeah. But OK, if it doesn't do anything about semantics, I guess there is not much that can go wrong. OK.
PETER KOCH: You hope so. Any more questions?
KAVEH RANJBAR: I have one from Mike Gibben from Google. How fast is it? That is question that I can ask?
MAREK VAVRUSA: I think I showed it on the slide before. Well, roughly when we took an older .cz zone which has around 563 megabits which is around 5 million of the records, it parsed the zone in about 20 seconds; whereas it took to about a minute and a half to parse the zone and then another 16 seconds to load it. So that is about it, I guess.
PETER KOCH: Thank you. So maybe I have a question: So what, what stand alone use would you envision for that parse parsing tool? I mean, it's part of no but do you see any use of it for using it stand alone or as a plug in for other tool like syntax checking or anything like that.
MAREK VAVRUSA: I may not have made it entirely clear, it's not wired into no, but it's just part of the source code but it doesn't really rely on anything from the node library so it could be used stand alone as such.
PETER KOCH: Sure, I am sorry to misrepresent the link between no and the tool so we have seen the needs, say, for the zone file parsing as in consistency checks and if I understand correctly you are looking at the individual record to do the syntax checks but you don't follow semantics. For example, if I wanted to develop a tool that does NSEC3 chain checking that would not be implemented right now but it would be possible, is there a way to extend this or do you have any ideas how to continue the work on that product?
MAREK VAVRUSA: Right, that is basically what we do on no, it takes the zone file and it records as an input and gives you the parse one like in the wire format so you can do pretty much everything you want to do with it.
PETER KOCH: Thank you. Any more questions? OK. Thank you, Marek.
(Applause)
And that brings us to our next presentation, which will be from Sara Dickinson from Sinodun, hopefully I pronounce that had correctly. An update on open DNSSEC.
SARA DICKINSON: I am here today with my open DNSSEC hat and T?shirt on, to give an update on the open DNSSEC project.
So a bit of background first off, what is open DNSSEC? If you don't already know it's a turnkey solution for DNSSEC. It ought mates key and zone management for the user. So it will consume and produce signed zones for distribution to name servers, commonly be deployed as a bump in the wire solution. We take some efforts to be RFC compliant in that activity. And also the software is developed under an open source licence so it's freely available under a BSD licence. Some of the key features of the software, you can see from that high level architecture diagram, internally we have split responsibilities among two components, we have one component referred to as the enforcer and the job of the enforcer is to consume a policy that defines assigning parameters for the zone and to do some zone management as well. It outputs information which is consumed by second component called a siren, the job there if you haven't already guessed it is to actually sign the zone, so that is responsible for managing signatures based on the information it receives from the enforcer.
So, that provides a flexible configuration, you can have one policy for all your zones or many policies for many zones.
The system is scaleable, so you can have many zones with few records or one zone with many records and we also support key sharing to make it easier to manage many zones. It's developed with security built in, so the communication to the HSM is done via PK11 interface and as part of the project we develop an application called soft HSM which is a software implementation of an HSM module so to simplify configurations you don't need a piece of hard waiver, soft HSM can do the job for you.
What is the organisation behind the product?
Well, we have a number of companies and organisations that contribute resources into the project. We have an architecture board made up of individuals from those organisations, that guides the direction of development. We have a project team who are actually doing the open source development of the project. And alongside that, we now have a commercial company established and the role that that fulfils is really to provide activities like training, pay consultancy and long?term support contracts. So it's a ?? what is the current status of the project?
Right now, we have two stable releases available. We have a 1.3.14 release. We have recently decided to adopt U bun?two style model. So in other words, we will be declaring some releases as long?term support releases. So we will support that particular release until a given time after our next long?term support release. Alongside that we will also be releasing standard releases, the last one of those went out last month, that is 1.4.0. So the support policy on that will depend on the next immediate release so we will support it for a given time after 1.5 if that is what was to come out or 2.0.
In terms of upcoming development releases labeled 2.0, it's called the enforcer NG release, I will explain that on the next few slides. Currently there is an alpha snapshot of 2.0 available on the website.
So, in terms of where we are in 1.4 versus 1.3, the major piece of work that was done in 1.4 was a refactor of the siren component that I described earlier, what we have done is add input and output adapters on to that component. In 1.3 open DNSSEC supported receiving and producing zone files only in a file based format. With the new adapters we can now support IXFR both on input and output so that is a major new piece of functionality in 1.4. Just to mention because it was such a significant change there was a change to our configuration files so there is a bit of an upgrade path there but it's hopefully fairly painless. The other major piece of rework we did in 1.4 was to remove the integrated auditor. The big advantage of that was it removed our dependency on ruby so it made installation much more simple. And also, these days there is a myriad of different tools that you can use to validate your zone, so we are recommending that rather than using integrated tool, use a completely separate tool for their validation process. So to just hammer that point home with some pictures:
On the left you have got the 1.3 architecture, so you can see far?based zone processing and a completely integrated auditor into the work flow of open DNSSEC. Whereas on the right?hand side in 1.4 we have now capped that work flow with adapters so we can pull zones in from various sources and distribute them to various sources. And the auditor is removed and we anticipate users will do their validation downstream of the output adapter.
Other updates that we have put into 1.4. In 1.3 there was a requirement that you had to have the pen for your HSM in clear text within your configuration files. In 1.4 we have provide add command line tool so you can just enter it once and it will be securely stored to improve that situation. We have also added a number of enhancements and bells and whistles to our command line tool that interacts with the enforcer component. We have provided more information for a number of key commands there. We have extended the hook that can be used to submit the DS record so it can now key off the CDA ID and we have also deprecated the one step key backup process that we had, and this is in favour of a much safer multi?step backup that we think is far preferable.
One other thing that we have done in 1.4 is open DNSSEC supports two database back ends, S Q light and MySQL, S Q light is a great database for getting up and running with, for people who want to use open DNSSEC in a production environment that they use the my QS L back end, we have provided migration scripts to make going back and forward much less painful procedure now, between what they want to do between test and production environments.
As I mentioned we also produce a soft HSM component and that is is quite largely parallel to the open DNSSEC product. We have a stable release 1.3, again there is going to be long?term support for that. And we have a development release 2.0 in the works.
Two of the major features in that development are plugable crypto libraries, so that is going to enable support for both an AP SNL etc. And also some improved security over some of the design elements of 1.3. We are closing in on a beta release of 2.0 so we are hoping that will be available in the next month or two. So if there is anybody interested in looking at that and working with us on beta testing, we would very much like to hear from you.
Some other news from the project. Just to mention that we are slightly modifying how we version open DNSSEC so we are going to more closely reflect changes in the API as opposed to component level changes. I would like to draw your attention to the effort we are putting into automating all our aggression tests, so what we have been doing is using Jenkins to do this. Fearing to rely on the right network, I have a screen grab here rather than trying to show you the real thing, but this is a publically available site, so please go and have a tour. The jobs grid shows you all the jobs that we run. Across the top hopefully you can see that against each branch that is supported and in development and against each of our database back ends, if there is a labour missing it's SQL Lite version, so we run across all our branches and then the left?hand side you can see all the platforms that all those tests run on, I think we are up to 14, something in that region, so we build a product and we run smoke tests and daily tests across that entire matrix every day. Our coverage isn't complete, we are getting there and it's a work in progress but please feel free to have a tour around and see where we are with that.
Additionally, we are trying to continue to put effort into our on?line documentation. We have got real desire to make this a proper knowledge database for users. In 1.4 we have added a set of quick guides there so sort of float outs to help out with the routine processes that you might do with open DNSSEC, and we have also set up an area for users to contribute back to this, so open DNSSEC is used by variety of organisations in a variety of configurations and a number of our users have kindly contributed back information on how we practically use in practice. So we are hoping that is a good source of material for people new in the product and we are shortly going to set up a site again to try and improve interaction with the user community to understand the usability requirements to work towards a number of usability developments in the future.
And that is just a screen grab of our documentation page, so again, take a tour.
So, to look forward and to think about where we are with the road map, so the 1.4 release was very much signer focused and almost exclusively looking at siren developments. Looking forward, the next release 2.0 is really focused on the enforcer component, and there were two things that we wanted to look at in terms of enforcer component, one was its performance and the other was the functionality.
So this is a very, a brief slides looking at where we are on the performance side of things. I will, firstly, hold my hands up and say I have shamelessly cherry?picked a corner case which makes the new enforcer look really, really good, so, please don't hold that against the current enforcer because that would make me feel bad. But to give a bit of context here as to the kind of performance problems that we are trying to tackle:
Where we want to be with open DNSSEC as a product that can comfortably handle the order of tens of thousands of zones, with the old enforcer it didn't scale quite so well when you get up to that order of magnitude and so the new enforcer is very much geared towards enabling that scalability. The case that I have picked here is one where a given number of zones are added to DNSSEC and that is the horizontal axis and on the vertical axis is the time that it takes the enforcer component to simply wake up, take a look around, figure out whether anything needs doing or not and in this specific case nothing happens to need doing because of the combination of the policy and timing issues.
So what you can probably see is the blue line with the crosses on it, is real data from the 1.3 enforcer component, whereas you introduce up to 1,000 zones it's heading sky wards, so you are talking about for this particular case it was around about a minute to process 1,000 zones and the reason for that is that the design means the enforcer has to waning, find a zone, look at its state, figure out if there is anything needs doing, decide there isn't and then walk on to the next zone and work its way through every single zone that is configured. Whereas the design of the new enforcer, what we have done there is borrowed the task based schedule of design from the component that we currently used so why this looks so good and this is the case where, when there is nothing that needs doing, there is no jobs on the queue, the enforcer wakes up, takes a look around, nothing to do, I can go straight back to sleep so this is one case that new design really improves things.
We are currently doing this benchmarking, we are going to look at other scenarios and benchmark data as we get it. But I will comment as an aside that running the script to add 5,000 zones to the new enforcer and all the measurements ran in less than a minute which is the time it took the old enforcer to wake up and figure out it had nothing to do with to 1,000 zones so I think it's fair to say we are making progress in the right direction there.
In terms of functionality with 2.0 what we are also looking at is extending the options to manage your policy, so we are going to introduce support for more key roll over mechanisms, algorithm roll over which currently isn't handled in 1.3, support for combined signing keys and also support for unsigned zones will be in there. Beyond 2.0, what we are looking at is obviously, now that we have got the architecture in place we want to add more adapters for zones, dynamic updates is top of the list with database input not far behind. We also want ?? are working towards having a common API to improve system integration and if you have a look at WIKI page there is a number of other developments.
So finally, a slide on where to find us. We have a website, we also have a Facebook and a Twitter feed and we have had nine "likes" this week. And also, we will be in the bar tonight at 6 o'clock, the idea there is just really a completely informal session, come down, meet the team, ask us any questions about the software. And clearly, I am going to make a legal disclaimer that the choice of location has nothing to do with any incentive based policy for the services that we might offer. So, that is everything on the project today. Thanks for your attention and I hope to see some of you this evening. Thanks.
(Applause)
PETER KOCH: Thanks, Sarah. Any questions?
AUDIENCE SPEAKER: I don't really have a question, more an anecdote that shows that no good deed ever goes unpunished.
Open DNSSEC was of course started to raise the security of the world, I recently encountered a totally num DNS related project where people had thrown out all their hardware security modules and replaced them by your soft HSM because they were far less hassle. So, I am sorry to report that no good deed ever goes unpunished. And keep it up.
AUDIENCE SPEAKER: Carsten, I have three questions: First, will there be a new auditor in version 2.0 or are external auditors for the future?
SARA DICKINSON: We are recommending external auditors, partly because we think there is an advantage to just completely separating the logic and the code base to say let DNSSEC do your signing and choose something else independent to do your auditing to give you a nice warm fuzzy feeling that you are not picking up anything through the interaction of those two operations.
AUDIENCE SPEAKER: That leads to the second question: There will there be an API to hook in these auditors to open DNSSEC so the auditors can report back?
SARA DICKINSON: There was discussion of that. I think there is no firm plan at the moment. We are open to a future request on that, though, we have a bug tracking system so we can certainly look at that as part of the process.
AUDIENCE SPEAKER: Last question is: Is SQL Lite also not recommended for smaller installation, less than 100 zones? We had no problemes with that in the past and LITE is a little bit easier to maintain than MySQL.
SARA DICKINSON: We appreciate that. So our recommendation is based on observations from some of our users of locking issues they have seen with LITE, we have a very crude locking mechanism which can lead to blocks, so if your enforcer happens to be running and you want to look at your key list, put the kettle on and get a cup of tea, depending on your configuration that could take a while to come back. We are actively working for trying to find fixes for that in 1.3, we are not quite there, maybe when we do get there maybe that will mitigate that to some extent but we certainly feel for bigger installations and production environments MySQL is more robust to handle con currency.
PETER KOCH: If you have a question jump up.
SHANE KERR: From ISC so. My question is about the new support you have for zone transfer stuff, does this mean that you maintain internal state about each zone, a kind of internal copy of it?
SARA DICKINSON: I am getting a nod from Mathias, so I will say yes.
SEBASTIAN: I have three questions, but I will stick with one. Do you have any particular preference for MySQL over postscript because some of us we are kind of nervous around MySQL licensing?
SARA DICKINSON: It's on the list to be discussed for 2.0 so one of the other things that 2.0 does, it's got a better abstraction away from the database back end.
AUDIENCE SPEAKER: One observation regarding the about preferring SQL LITE over MySQL ?? SQL in our production system, you have a few of those in zones and seen logging issues so if you can go for MySQL, do it.
SARA DICKINSON: Yes, thanks.
AUDIENCE SPEAKER: Jake, cyst net, I would like to ask the HSM, is there any plans to support backing up of the keys generated by the open DNSSEC, HSM like smart cards for which there are no way to get the private key out of them once it's generate on them so something like generate private key by some script we will call which generate the key on the server and then upload the key to the smart card for cases of backup? Something like that.
SARA DICKINSON: Not at the moment that I am aware of but perhaps it's something we can talk about this evening.
You had a you had a math, you were saying 2.0 is meant to handle up to tens of thousands of zones. What is the bottleneck there, is there database performance or is the hardware the limitation?
SARA DICKINSON: Are you asking what was wrong in 1.3 or why we think the limit will be ??
AUDIENCE SPEAKER: No. In 2.0 what is it that limits it to tens of thousands rather than, say, hundreds of thousands?
SARA DICKINSON: It's a good question. I don't think we know properly because we are literally ?? I mean, that benchmarking data, I got on Tuesday this week. So, that is one thing we want to understand. It might be probably the zone management, if anything.
PETER KOCH: Great, thanks. And thanks for the presentation. Which brings us to our almost final speaker for the morning.
(Applause) Peter Janssen from EUrid, demonstrations and we will have some switch over with the laptops.
PETER JANSSEN: As Peter said I am from EUrid and I will talk about one specific feature that we have built into YADIFA. First of all what is it? For those that don't know, it's yet another domain implementation, and no the not an acronym. Little bit of background: We wanted a substitute or alternative to the BIND and as these solutions that we are running, so we ride to make it or made it RFC compliant, security in mind, T6, ATL, multi?platform, it's open source BSD so you can download it, look at it, play with it and basically do whatever you like with it.
And as I said, the first idea was or the first use case was to actually replace, have a replacement for a TLD authoritative name server so another use cases are, you are a hoster and you have 20, 30, 100 thousand zones and there are zones coming in, going out, every single minute or hour of the day. You don't want to bother with reloading config files and all that sort of thing, we what we tried to do is come up with a solution where would you con line do dynamic zone management. What does that mean? The whole idea is you can add a zone, remove a zone without stopping the name server or any interruption in query zone, only existing zones not the new zone. You want it to be reliable and highly secure so you don't want anybody else to be able to add or remove your zones. You want to be compatible with DNSSEC obviously, you want to do this as a master name server or as a slave name serve and you want to be able to config all things security.
So, prime thing that we thought of, well you have that secure mechanism between a master and a slave name server which is protected and all that sort of thing. Why not use the DNS protocol to configure the name server itself. Imagine you have a flock of YADIFA and one special which we call the herd master and this one will actually control all the other ones. Basically, the installed configured with one basic thing which is a secure key that actually enables them to know that they are talking to somebody that they can trust and not anybody else. And that is all there is of configuration.
Suppose you want to configure a domain ?? zone domain dot EU and your default one first,or a slave of the herd master and you want number two and number three to be a slave of the number one, you send some DNS message and herd master will split that up in individual messages going out to the name servers and turn around and do obvious things like you are a my master please give me my zone. That is basically the whole idea.
So what I wanted to show you is let's go to one specific example and actually look what is happening on the wire. So, what I am going to show you in the demo is three individual machines, virtual machines, two of them are running YADIFA and one is to be able to control sending messages.
So, first step, we want to provision demo 1.EU, which is a zone, we send a first message to the first YADIFA name server and it's a little of grey, I hope there aren't too many colorblind people in the room, that is supposed to be grey, white grey, that is a dynamic update message, the only difference there it's not in the Internet class but it's what we call the control class, for obvious reasons we have named that control class currently using a specific number for that, two A still remains to be seen how this officially should go further.
What you see in that message is we send one dynamic update message and we are saying demo 1.eu, you are the master, zone type: Master. I have become the master of this zone. When it gets that message it's processed and it picks it up internally but doesn't do anything with it. So you can keep on sending messages up to the moment you are actually saying, sorry I have put something in here. What does this message look like on the wire?
Here I have taken an extract from the RFC where there is dynamic update message, I have highlighted in yellow the interesting things, the first one is the dynamic update message, further down you see the class 2A, 42, in decimal, and you see the update there which says demon 1.eu, class 2A, and the type is 10753 which is just that zone type message I was talking about. What you are saying there is you are to become a master named server, that is all there is to it.
It doesn't do anything with it up to the moment you tell it everything you got in terms of dynamic configuration now please make it happen. That is another message. This time it's yellow because it's a standard query, it's not an ?? telling us with your configuration that is running now and the new updates to the configuration that you got, please merge them together and bring them live. The moment that your YADIFA gets this it will execute what you send it and when you start querying it for that zone it will start responding for that zone.
Next step: Looks like this on the wire. It's a standard query, again class 2A and yet another number to signify the CFG merge command. Next, we are going to still the same name server, two things: Please, when you get something new for demo 1.eu in terms of contents, notify this other name server. And by the way that other is now a slave for this zone for you, so basically you tell one YADIFA to tell the other it is to become a slave for this zone. And again, what does it look like in terms of network packets? It's a dynamic update message, it's class 42 as usual and two records there, one to signify this name server is a slave and other please notify if you get changes to the zone.
What is not shown here, because wire shock doesn't know about that, is the data I highlighted there is the R data which contains the interesting information, the IP address of the slave and things like that.
Again, we send it to merge to make it happen. At that moment in time your YADIFA will send a zone change notification, again in the control class to the other name server, a the other YADIFA, what will it do on receiving notification? It will turn around and zone transfer the notification, not of the zone but of the zone configuration. So again, it's in yellow, standard query but in the control class it's asking for the configuration of the zone. Once it has received that obviously it will turn around, in this case to the same name server but it could be to another but this time to the Internet class and actually do a zone transfer of the contents of the zone, not the configuration of the zone.
So, now, some gymnastics, I am going to ?? I have on my machine here running three virtual boxes or machines, one is the controller, which you can see the DDSHL, two other YADIFA running there which you won't see and I am going to run a script but the script will show you which commands that are executed and each time you are going to do some queries to the name servers to see what is happening. So baseline I started my master and my slave name server. What will they respond? And not to have any other DNS query tool with too much noise on there. We did a small visual ditch, what you see here is the root or the root name server that we have on my machine. When you query that for www. demo 1.eu it will respond for the name server for EU, when you query that one it will respond for demo 1.eu and master and slave EU which is the two name servers that we are talking about and when you ask it, it will actually give you a, for the moment, refused, for the simple reason that it hasn't been configured to handle demo 1.eu. All fine. When you run the script, basically what you see here, YADIFA which is not ? so the YADIFA is the demon is the control tool, if you like, it leads from a file you see there just above the contents, so what it says is please talk to server 101253, which is the first name server, and to set zone type master, which is basically dynamic update message does get sent to that name server. If I would ask again, it will still tell me, it will still tell me refused for the simple reason I have sent configuration message but I haven't asked it to merge it into the running configuration so the moment I do that, we do YADIG, basically it's a tool which allows you to go in other classes so you tell this name server for this domain name in this control class and this type, please send the message and basically when it has done that magically, when we ask the master again, it will still have some issues but the issue will be different, it will be seeing no such domain. At this moment in time, it has configured the zone, but it doesn't have any content for it so it knows about it, but it doesn't have any content. If I would ask the other name server, obviously that would still say refused because it doesn't know anything.
So the next step, we are going to create the zone on the slave name server and how do we do this? Same way. We do YADIFA the control tool, we ask it to do contents of this file and what is in this file, we still talk to the first name server and still talking about zone demo 1.eu and to zone notify this to name server the other and incidentally the master slave thing here is the name of the key that should be used to secure the communication between the two name servers and the second is set slaves so this makes official slave for demo 1.eu. If you ask my slave about it it will still say refused for the reason it has received this stuff but hasn't merged it into his configuration, but will do exactly the same thing. We tell it to merge the configuration, then we go there and now it will no such domain, like the other one.
So at this moment in time, the two name servers have been configured with the zone, still no content so, the next step is all too traditional, we are going to do at some ?? add some standard resource records to it and reuse Yazoo, which is our NS update and no, it's not an acronym so it's not yet another zone update, surely not. It's just that.
So if we ask now the master, and I should ask it explicitly for the A record of www and so on, it will tell me IP address and I should do the same thing. It's very hard to do this standing up. As you can see here, both the master and the slave responded with the IP address that we just asked here.
What we have done now, we have two name servers running and the only thing that got sent to the name servers at all times is DNS queries or packets in any case, going up and down.
So one last step: Going back to the presentation. Just a small overview of the types we have defined, left dynamic update type and right, zone type that we already talked about, zone notify we already talked about, but a whole slew of other things we denied to control the cell or set the configuration of a specific zone, up too the count, the time?out intervals and things like that.
And on the right side you have the same thing, we talked about configuration merge but you have configuration save, which saves it to disk, so when it gets restarted it doesn't lose the configuration, you can drop and merge them all and save them all, you can freeze the zone, tour the zone and so on and so on. And that is basically what I wanted to show you.
It's not out there yet so if you want to play with it, we can't ?? well we could but we are not have it official Lyon our website yet, that should be having somewhere in the not too far distant future as a sort of better because it's reasonably stable but we do know about some quirks and things we need to do, removing the zones is not in there yet so you can provision a zone and can't remove it for the moment, it hasn't been implemented, we are working on that and basically trying to define all the things that we need. If anybody is interested in hearing about this, talking to us about ideas, what we should do differently or what basically what you think about it, please let us know. The usual channels apply, including myself being here and ?? we will be here all week long. If you have any questions on that. Please, shoot. Thank you.
(Applause)
PETER KOCH: Any questions?
AUDIENCE SPEAKER: So, well thank you for this. This has been one of the big things that DNS has been missing for the past 30 years or so. Everybody assumed it was there already, how do you get the zones out there ? I don't know. Zone transfer but we always missed out the stuff of distributing which zones we wanted to transfer. I happen to have a conversation with Paul about this and he told me in their initial Pascal based implementations they had this already, for the next two years they were sleeping so thank you for this. There have been several other initiatives, both within ISC, PowerDNS has limited super slave feature which is thousand times smaller than this but it's already popular so this should be really good. My question, of course, is, have you thought about this being inter operable and will you be making any efforts ?? I am not saying we need to do a 12?year IETF project about this; but have you made ?? well would you be open to making this inter operable because power DNS really needs something like this and it would be great if we made something that was just not one or two named servers.
PETER JANSSEN: Long story short, yes, we would be used by different namers by bind, power, name servers. In terms of interoperability, one of the things that we looked at is this is very easy to put something in front of other protocol XML based ?? I don't know what ?? would exist somewhere to actually have a proxy running on the machines and actually translate on one machine only and translate the incoming XML at that moment in time to the DNS message. The advantages we see with DNS, you have that secure layer between your master and your slave name servers and don't ??
AUDIENCE SPEAKER: We need to keep this DNS because it goes through all the firewalls.
PETER JANSSEN: Yes, if it passes through to do a zone transfer and configuration, it's nothing else but that, I would see this as big advantage. I am very interested in talking to people who want to work with this ?? on this together with us and actually implement something. I would love to see a standard so ?? because that takes away the grey area, should take away the grey area but I am not in favour of having 12?year or 15?year process where we finally come up with something. That is why we basically built something, we showed that it works and we can take it from there. That is basically the message I think.
AUDIENCE SPEAKER: Final question, it's not officially out there on the website, but is the code out there.
PETER JANSSEN: No, but if you want to look at it we will arrange something in a face?to?face mention.
AUDIENCE SPEAKER: Thank you.
AUDIENCE SPEAKER: From Netnod, I am a bit interested in the security model for this, how you authenticate the updates and also how you transfer that authentication information to the downstream slaves to speak. You said there was a stream that identified the key, but how did the key content end up?
PETER JANSSEN: The initial deployment of a name server should contain a mandatory contains a TC key that will be used to secure the communication to control the master slave communication for the configuration of zone files. The TC key that is used to transfer the content of new zone file can actually be configured over one of these previous messages you can transfer to a slave but it's done in a secure way because that transfer is done by the ?? the one TC key to secure it all that is basically the idea, at deployment time you have one TC key that secures the ?? over that configuration channel you can configure new TC key. So from one name server to another, at the moment in time it's safe there at the other side and it can be configured to be used to zone transfer, the contents of a newly configured zone.
AUDIENCE SPEAKER: If I get that right that means you are using the TC key to encrypt the next TC key?
PETER JANSSEN: Yes.
AUDIENCE SPEAKER: It's also possible to have multiple controllers, control one single server?
PETER JANSSEN: Yes. The slightly longer story, there is a whole story with ACL, only except, things like that ?? and obviously it could do the control part over another port and have that port over the VPN of something like that. So if you really, really paranoid, which you should be, you can ample with layer on layer on top of security without any issues. Thank you.
AUDIENCE SPEAKER: I have a lot of questions but later on just one question now, I would like to see the configuration more being in a private zone in the Internet class because that would enable to use all the existing software that is existing already that does update the ?? does queries, maybe even open source management tools that can work on the configuration. That would be really nice.
PETER JANSSEN: I hear you and I understand. That said, the files that I showed you to configure the new zone for instance is basically standard and is update speak and it's the tool that actually, your default tool that sends it over in the control class, you in the user that uses the tool and defines the input doesn't basically have to know about the fact that is the the control class being used. You just generate the file as zone blah?blah, zone type this and it's a tool will send it over. There are ways of making this easy without having to do anything special.
AUDIENCE SPEAKER: I want to use existing tools like things that exist five years ago that already existed five years from now.
PETER JANSSEN: Let's take this off?line and discuss this again. I am not saying no or yes, you have to see what the ?? what works best for people out there.
AUDIENCE SPEAKER: I would like to return to the security keys issues. Am I right here you have shared secrets ??
PETER JANSSEN: Yes.
AUDIENCE SPEAKER: How is secret used to encrypt the payload and channel or something ??
PETER JANSSEN: The standard is using just DE?CIX or the standard DNS DE?CIX which is open to on the message which I realise now probably for the sending of the new T K keys that we have to do something special but I don't think that is even implemented yet for the moment so this is still something that we need to think about. Basically, when you deploy your different name server it gets out of the box a TC key which enables it to actually know that is the talking to his authorised master to get configuration information but that is more authorisation than anything else not authentication and not encryption and basically there is no big issue there except for TC key that gets sent over so that is something we still need to ??
AUDIENCE SPEAKER: Is there any mechanism or procedures to maintain the key life?
PETER JANSSEN: ??
AUDIENCE SPEAKER: Or just done on manual administration.
PETER JANSSEN: Basically yes but it's on the front end and your management system should actually send at the right time the message over saying do a new TC key, deploy a new zone with this master and slave so it's basically, this is a framework for configuration on the lowest level, the whole management environment around it is something else. I am not saying that we have built it, far from it, I am not saying we are going to build it maybe but that is something to be seen. And also, the big issue there is that it needs to fit into the set?up of the person or the company that wants to Tuesday so the host probably actually has some provisioning tool based on my sequel, some sort of database and there should be some sort of interaction between that of course and so there is some layer in between that that extracts the information from the hosting environment and converts that to configuring the zones, pushing them out.
AUDIENCE SPEAKER: Thank you.
AUDIENCE SPEAKER: Marco: DE?NIC. I am not going to evaluate security model or the architecture of the protocol extensions because I will leave that to people more qualified than me. I want to give you a big thank you for doing a live demo.
PETER JANSSEN: No problem.
AUDIENCE SPEAKER: Because it's risky, because it's refreshing, because it's running code and I think we need more from that. Thank you very much.
(Applause)
PETER KOCH: Thank you. Thank you. Thank you, thanks to all the participants in the discussion.
And now we have established a new tradition this this RIPE meeting which is that every slot ends early.
And I am inclined to follow that tradition. So you get to your lunch early. We are going to reconvene at 2 o'clock and enjoy. And be back. Thank you.
(Applause)
