 Would that be ready, I suppose? Well, without further ado, I think we'll begin this talk. Please, everyone, please make yourself at home. That's what you think. Hands out of pockets. Remember all the things the speech teacher taught me? He was this crusty guy who would walk around with chewing tobacco in his mouth. Do the body surf? OK. OK, we'd be more than glad to do so. Hello, everybody. Hello. Welcome to the talk on designate. Man in a DNS for OpenStack. I'll start out by introducing myself. My name is Patrick Galbraith. I've been in the open source, working in open source since probably about 1993. Had a long weekend, and somebody told me about this Linux operating system. You could download Slackware and 23 disks later and, well, set me on a course to where I am now. I worked at slash.org with Brian Aker. I worked at MySQL for three years, classmates, all kinds of different companies doing web apps. Kind of a MySQL Perl C guy, but now I'm a Python guy. And I'm the tech lead for DNS as a service at HP. Kyle, who works on my team, he created designate. And we're going to do this talk about designate. Kyle probably wants to talk. Can I introduce himself to you guys? So my name is Kyle McInnis, and I've been involved in OpenStack for a couple of years. Started with HP January or so. I'll leave my introduction short. Yeah, I was lucky to begin working with Kyle back in October when I heard about this project, because I was looking for a way to solve building DNS as a service. And lo and behold, somebody was already working on it. And that's how I met Kyle. And I said, please, please, please let's hire him. So I'm very fortunate to work with him and a number of other really brilliant people at HP Cloud Services. Anyhow, so let's see if I can use this properly. What is DNS? I know that's a very simple. Why is he asking that question? Obviously, we all know what that is. But just to get you thinking in the frame of what this discussion is about, it's the internet's phone book. You want to be able to get to an address. DNS takes care of doing that. We don't think so much about the internals of DNS. It just works. It's one of those things that's so ubiquitous and so innate to our experience on the internet. It's just there. For me, when I was asked to work on DNS as a service, I thought it really does match my background in databases. It's a distributed database. It's probably the most distributed database. So it's asynchronous. Nothing is instant in DNS. It's the ultimate, eventually consistent model. And like I said, it's one of the most overlooked parts of the internet. You don't think about it. It just does what you want it to do. Sometimes there are problems, and it's very debilitive to your experience on the internet. And you know the rest. I won't belabor the point too much. So what does it designate? Well, it's an OpenStack-inspired DNS as a service project. BioOpenStack-inspired, we mean that the way it's designed, the way it looks, tastes, feels, is done in accordance to how every other OpenStack project is built. It's an API providing support for creating, updating, deleting zones, adding records, management tier for wrapping the underlying DNS servers, whether it's PowerDNS, Bind, MySQL Bind. It's also a modular foundation for building more complex DNS services. All throughout this talk, we'll be stressing the term modular, pluggable, extensible, and easy to work with any type of DNS server or database backend. Most importantly, it's an emerging standard for DNS in the OpenStack ecosystem. Why should I use designate? That's one of the questions you'll ask in this talk. Answer. Every user of your cloud needs DNS. That's a no-brainer. We need DNS. You're running your web application in the cloud. Whenever you're spinning up, you need to have DNS to be able to resolve DNS queries. I'm reading some notes, I'm sorry. But why designate? Well, it provides a standard interface to DNS, regardless of the underlying technology. If you think about it, if you had DNS servers running Bind, for instance, your interface to Bind was, you had to edit zone files. If it's PowerDNS, you would interact with a database that uploads records for PowerDNS. Designate allows you to be able to use any backend DNS, and you have a standard API that you can do things in an automated fashion. You can do orchestration and use designate to do all of the things you need to do, where you would add records. If you delete something, you can make that all automated and without the manual steps you would have with something like Bind or whatever DNS server you're using. And at this point, Kyle's going to do a demo to show you how simple it is to set up designate. Thank you. And we know how demos go. So yeah, demos rarely tend to work well, but we're going to try it anyway. So earlier on, what we've basically set up is we've got a running Keystone out there and running on HP Cloud. And you've got a precise VM ready to go. All the kind of basics that you don't really need to worry about today, like MySQL and Rabbit are pre-installed. And what we're going to end up with in the next five minutes is a DNS server with the API out in front, actually being able to resolve queries. We're going to do it based on Power DNS, because that's the best supported today. So we need two seconds. This better work. There we go. OK, so earlier on today, what we set up was this VM. It's ready to go. It's got our PPA installed. We're going to go right ahead and just start installing Power DNS and designate. We're just going to use two of the services today, the API and the central service and the CLI itself. This is mostly using packages from the Ubuntu Cloud Archive. So it should be compatible with the Havana release. There shouldn't be any conflicts with running it alongside on your noble controller. All the dependencies are the same. We're not going to allow the app to configure the Power DNS database, as designate will manage that for you. OK, so that's actually installed. Not quite configured or running yet, but it's ready to go. We're going to turn around and get it up and running. So the simplest thing for designate is to get it running with Power DNS and MySQL. So we're going to go ahead and tell it we want to use Power DNS. We're going to set it up for Keystone. We're going to set the Keystone username's passwords and so on. We're not exactly abiding by security best practice here, but we're going to tell it where the database is. And we're going to also tell it where the Power DNS database is. We're going to restart the two core services, the API and Central. Populate the databases, if I could spell. Ah, create them first. And we're going to set up Keystone. OK, and that should be a fully functioning designate talking to the Power DNS database. We haven't told Power DNS where it is yet, but we'll just make sure things are functioning first. So on our designate machine, we'll load the credentials. And we're going to see if a domain list call returns nothing. And of course, something went wrong. Of course, see how easy it will be to debug a designate issue. I'm not entirely sure why this is failing. Typical. OK, rather than debugging on stage, that would have essentially worked and allowed us to configure Power DNS where the database is. And finally, go ahead and simply use the CLI to create records, delete records, add zones. We essentially should have worked. I apologize. Had it working before. Yeah, typical. Sorry? I did. I had it working 20 minutes ago. And then I cleared things out. And obviously, I've made a mistake somewhere. So rather than debugging here live on stage, I'll move on. Essentially, that was pretty much the final step. At that point, we would have actually been interacting with the API, creating records, deleting records. We would have just had to tell Power DNS where it is, spin up as many Power DNS instances as we want, and from there, actually direct traffic towards it. So it should have been that easy. Oh, well, this back over to Patrick. Yes, this is why nobody should do live demos. We were laughing about this earlier. We said, yeah, it'll be great. We could show this and say, ah, this was in case something went wrong. Oh, well. That's OK. That's why we wake up every day and enjoy our work, right? Anyhow, designate architecture. As you can see very clearly, the fonts on here. That blue box points to the other blue box. Anyway, does this thing have a red dot thingy that the cat likes? Let me see. Oh, look at that. That, right there, is a user request. That is a designate API that sends a message over RabbitMQ, which then goes to designate central. Designate central, then we'll talk to the database, store it there, go to the designate back end here, which in this case would be Power DNS, adding the records to Power DNS. At that point, we can now do queries against the DNS server. It's that simple. This whole area down here, this is future development. And that is designate pool manager future work. I'll talk somewhat about this after this slide. But that's essentially what designate is. This part right here, which I didn't yet mention, this is called designate sync. And the purpose of this, and you'll like this, is so that you could have messages, say you're launching something from Nova, Neutron, whatever, going to designate sync and have the messages go there. So if you're spinning up an instance, you could have a means of having that as soon as that instance is spun up, you also have a DNS entry for it. And that's the idea behind designate sync. Designate architecture in general, everything is pluggable. As I mentioned in the beginning, the whole idea with designate is that we want it to be pluggable so that any database can be used, any DNS server can be used. How many of you have run DNS servers out there? So you have an existing infrastructure, existing architecture. You don't want to have to rewrite anything. It'd be really nice if you have something that you can use with your existing. And that's the idea behind this. Database, RPC, DNS server, Authzy, et cetera. All pluggable. Everything is distributed, and there are no single points of failure. That is just good design. Modeled after every other OpenStack project. As I mentioned, if you look at designate, you'll look at it and say, yes, this looks like, tastes like, smells like an OpenStack project. Heavy use of Auzo libraries that ties in with the last bullet point. Designate architecture, the API server. It's a front-end HTTP service. Supports a JSON. It communicates with the central service of the RPC, RabbitMQ. No direct database access. That all happens through the message bus. API, the current API that's in use, v1 is built on top of Flask. v2 will be built on top of the con. And work is in progress. It's very close. A very high percentage. I will not give the exact number of percentage, but it is very close to being done. Central, designate central. It's the core service. It's the only part of designate that talks directly to the database. It allows multiple front-ends to designate, a REST API. In the future, dynamic DNS, RFC 2136. Inbound zone transfers. That's pretty cool. I like that one. Communicates with DNS via server plugins. Power DNS, bind, DNS mass, MySQL bind. Communicates to the database via plugins, whether it's MySQL, PostgreSQL, SQL Lite, via the SQL Alchemy plugin. Also, it's architected in a way that will allow you to use no SQL databases, whatever flavor of those. And there are many of them that you would choose to use. Designate architecture for the future. So we're introducing a new pool manager service. A pool will be a similar combination of Nova availability zones and flavors. So we have this concept of multiple shared pools. Example, you have one premium pool from multiple data centers. This is the premium service. Or you have a discount pool from a single data center. Support for private pools. This was really nice of me. How many of you would like to have private DNS? Every pool has its own DNS namespace. And you can even have two customers that use dev.local zone at the same time. Also, we'll be introducing a new scheduler service. It allocates zones to pools similar to the Nova scheduler. We'll be embedded inside of a central service for smaller deployments. Think about Nova Conductor inside of Nova Compute. More about future development. DNS sex support. Zone import, export. That has been merged. So it is now available. In the notes, it says a fellow named Artem from E-Novance did this work. Thank you very much. Complete V2 API. That'll be very, very, very soon. Very soon. HTTP and RFC 2136 dynamic DNS. More complete Nova Neutron integration, as I mentioned. You'd be able to read events from Neutron and be able to feed them into sync. Horizon DevStack integration. Who's been involved with contributing code? Three of these organizations here. Us, of course, Rackspace. And as I mentioned, we have that excellent patch of import, export from E-Novance. So I want to thank you for coming to this talk. And right now, a Q&A session would be a good thing to have. We'd love to have some questions fielded. So please do ask. We have instances in the cloud, right? Could you start from the beginning of your question? Please. So personally, I would think that the main goal of the DNS service is to be able to resolve names of VM instances in the cloud, right? Yes. So now users be able to say, when they launch instances, they would associate names with instances. And those names get created automatically in the DNS service. So for us, the core starting point was just a standard DNS service. It shouldn't matter if it's Nova VM that you're allocating it to or some randomers website. Essentially, by getting that core in place, we can start building on automation around creating records automatically as VMs boot. We can start doing all of that sort of work. And while we have the basics of automatically generating and allocating records based on booting in Nova VM, we'll receive the notification from Nova and we'll go ahead and create a record. It's not as flexible as we'd like it to be yet. It's pluggable, so you can essentially use whatever you like. But the stock version today will take the IP address of the instance and call that the hostname. So that's a manual step currently? Well, it's automated in some ways at the moment. We have a plug-in, a basic sample plug-in that will turn around, receive the notification from Nova automatically in roughly real time to the instance being booted. And we'll go ahead and create a DNS record based on that. The record we create at the moment is an awful choice of name, but we basically couldn't find any agreement on what should the hostname be when you spin up a new instance. Some people will put a fully qualified domain name into the name box when they're booting a VM. Others will put a short hostname and expect it to be automatically assigned to a particular default domain for a tenant, while others might want something totally different. So by having a plug-in, the notification will come in, it'll be parsed, it'll be handed to your plug-in. Your plug-in can then simply call create record with a name, type, and IP address. And it will go ahead and create it. So we have the basics of that in there, but not no specific limitations other than the sample. Thanks. Either. Do you support split horizon, meaning if you assign a floating IP address? So at the moment, we don't. We do plan on building that support out, but we haven't really given it a massive amount of thought of how we're going to do it yet. One of the difficulties with doing that is we want to support things like par-DNS. We want to, at HP, we use a combination of par-DNS backed by Akamai to actually provide global pops. So there's certain limitations there in that. We have to try and stick to things that are usable on all the different DNS servers and providers out there. So for the moment, we haven't built that out. We do plan on doing it, but we haven't given it enough thought on when it's going to happen or how it's going to be done yet. I think there was. OK. How about DNS sec? That's on the to-do list for coming up fairly soon. We're starting to see more and more people asking for this as things like Dain and TLS within DNS and so on are coming along. And I think there's definitely starting to be an actual demand for DNS sec now. Rather than two years ago, it was something nice, but nobody really used it while that's starting to change. Have you planned to set up more than one DNS server? It sounds like you have only one autographed DNS server in this setup, actually. And would you like to support hidden master setups to deploy zones to other different public name servers? With our setup or? With Designate, I presume. With Designate. Today, with Power DNS, because it's MySQL, it's quite easy to just point multiple DNS servers at that. It's quite easy to replicate that out to other regions and point more Power DNS instances at it. With Bind at the moment, we're somewhat limited in that we've got one at the moment. I know Arton for me, Novens, they're planning on using NSD, which right now we don't support. But he's looking at doing that integration for us. Oh, cool. I've seen it. I wasn't sure it was completely out. I thought it was only out. That's very similar to what we do with Akamai, in that we run Power DNS internally. We run a whole bunch of them. Akamai will do zone transfers from us and populate that out to their 75. Yeah, I was doing this with Bind the last year. Because you were so funny about the DNS transfers of zones, it could be used in the other way around like pushing zones outside your cloud. If you provide Bind, for example. Yeah, so one of the future developments we've got there is the pool manager. And as part of that work we're doing, Graham is essentially taking, right now we're somewhat synchronous. He's we're starting by splitting out the front end piece from the back end pieces. Once we have that in place and we're doing that asynchronously, it'll be a lot easier for us to asynchronously go off to 100 Bind servers and write out the appropriate config files or make the appropriate ordnndc calls. And that's in progress at the moment. Probably a couple of months out. Yeah, how stable is the V2 API and is there a corresponding working client for that? The V2, go ahead. The current API, our product is GA, so it's very stable. OK. And does that tie into or what are your plans around what your roadmap for affiliated or incubated status in OpenStack? We plan on actually having that conversation again after the, so after some we're going to think about is it time to apply or not. OK, cool, thanks. The key for incubation is that they like to see that people are contributing and we certainly have seen an uptick in people becoming involved, particularly as people become interested in coming to these conferences and seeing what we're doing. The thing I was thinking about that I wanted to touch on a little bit further is that when we talk about how well it works with different back ends, I'm going to stress our own architecture, which is, it's a pretty neat architecture. We have power DNS servers that we, that's kind of our central DNS server, then use zone transfers to Akamai to update what they have. And you can have any kind of, the whole idea is that you have whatever architecture you have with your current DNS setup that designate becomes this really nice front end that'll, yes. It's very OpenStack, but it's also, there's so many more implications than just that. It's a great project. And what organization are you with? Inovans. Oh, OK, OK. That's where you, OK, great. OK. Oh, OK, yeah. Any other questions? Yeah? Yes, so we have a somewhat limited set at the moment. We support all the common things. But over the coming months we'll be making that a little bit more pluggable so we can potentially support things like alias records that will resolve on the server side and things like that, which we might not be able to put into, like, Bind doesn't support that, Paradeanus doesn't support that. But should providers have a mechanism to do that, we want to allow them to plug these virtual types in on top. So today we support A, Quad, A, C name, text, SPF, probably the ones I'm not thinking of. And then for DNS sec, when you start thinking about how you're going to implement it, have you started to figure out where the key management is going to go? Because that's very interesting. I think that's our biggest thing at the moment with DNS sec is figuring out how key management works. And potentially wanting to avoid doing it, if at all possible, ourselves, and looking at things like Barbican as potentially a way of doing this. But it hasn't been, the key management side hasn't fleshed out enough to really give enough detail. OK, any questions? We support people adding pointer records, but we're not currently automatically managing pointer records for instances as they boot. There's probably nothing preventing you from doing that in a sync handler, which is the default one is like 10 lines of code, and it takes a notification in, pulls the information, and it'd be quite easy to create multiple there, but we don't do it out of the box today. We can allow users to do that if they own the zone. We also, by default, include the ARPA top level domain as blacklisted so when the administrators can create it. That is one of the more interesting things about reverse DNS is that we're going to have to figure out a good way of allowing a customer to change it. If you're a cloud provider, you've got one big IP pool or a couple of IP pools, and they're shared. So unlike a customer bringing their own zone to you, each individual record is delegated potentially to a different tenant. So we have to allow for that. That's coming up very soon on our roadmap, so I know I'm going to have to figure out or get Graham to figure out how we're going to build that. But it is, yeah. The tricky, if you think about it, somebody brings up an instance and it has a reverse record, and they shut it down. I think part of the problem is we have to guarantee that these records get purged. It's difficult at the moment because without being an incubated or integrated project, we can't get hooks put into all of these other projects to call out to us. We have to rely on the notifications. As long as we're relying on those, we have to rely on those guarantees of delivery. There might be delays in that happening. The IP address might be reused for another tenant by the time we've finished processing the purge IP record. So there's a lot of difficulty in getting that done just right, so that it's going to be reliable enough that everyone can actually use it. How about supporting client-subnet DNS? Sorry, I couldn't hear. How about supporting client-subnet DNS? I'm not sure. Sorry, I can't hear. The client-subnet DNS? I'm sorry. How about supporting the client-subnet? Client-subnet? That would be, so you're talking about the likes of G-O-I-P and so on? Yes. We're planning on that sort of stuff, but we haven't gone out and built it yet. One of the issues with that is the likes of Bind. If you want to do G-O-I-P, Bind, Parity DNS don't necessarily support it. We've been looking at writing a back end for a DNS server called GDNSD that we've been thinking about as potentially a way of doing that. But it hasn't come up yet to a point where we've had to go out and build it. I think we're at a point where we've got all of the basics in, and it's stable as hell. It works, except with the demo. And we're now really starting to look at all of these add-on extra features that aren't necessarily core DNS and starting to prioritize and build those out. You can even have a particular, if you had a partnership with another DNS provider, they may have their own implementation, so you have to have a back end for that as well. Yes. Guy, I'll be behind you. Depending on the back end, especially for Bind9, I see in your code, not the MySQL backbind, but just straight-up bind, have you run into issues with glue records in subdomains, where, for example, a user says, I own example.com, and he has a separate domain called subdomain.example.com. So you have two separate domains in the zone file. But you would have to have, in the primary example.com domain, say, oh, for this subdomain, you need to look up a separate NS record instead. We have a couple of bugs around handling subdomains, handling both a parent and a subdomain at the same time. There are a couple of things that don't quite get handled right. That particular one is handled by PowerDNS, so we didn't notice that one. We obviously use PowerDNS internally, so that has worked for us. But there's definitely some issues with handling those. Usually nothing particularly serious. There usually just comes issues, potentially, as you're trying to delete a domain. It's one of the big ones we've noticed. But that's something we're working on at the minute. Do we have any others? Well, I suppose if none of you have any other questions, you feel free to come up and talk to us. We can conclude this, but I really appreciate every one of you coming here and coming to see our talk. That last slide, hopefully you took notes. Too late. That's OK. Thank you.