 Hi, welcome to the Designate overview talk. We'll be running through Designate and how it can be used in your clouds to improve customers' use of DNS. So what we'll be covering is what DNS is, how you can interact with it, so using the API or the client libraries, how we work with DNS servers and the existing DNS servers we work with, and then finally, how you can use notifications to auto-create domains and records as people create resources on your cloud. So my name is Graham Hayes. I'm a software engineer on the DNS as a service team at HP Helion. On the left is Andre Carlson, who's a colleague of mine on that team. We also have Vinod Mangapali and Tim Simmons, who are software developers in Rockspaces Cloud DNS team. So what is Designate? Designate basically means to give meaning or status to something. So that's effectively what DNS is. We give a label to an IP address, and it gives us a status. So Designate allows people to very easily create DNS records without having to go through the pain of editing DNS zone files or writing to a database or any of the other methods like the traditional DNS servers would ask people to do to create DNS. It's also multi-tenanted. So it can be set up once by your ops team and used by all of your customers. So it saves the infrastructure of multiple people running multiple DNS networks in the same cloud. So this is the current overview of the architecture within Designate. We have a fairly simple architectural overview. We have an API service, which just takes the input from the user, validates it, makes sure that they're authenticated via Keystone, and passes it over an AMQP queue into Central. This is where we have all our business logic. So it creates the record, makes sure that it's a valid domain, that you have access to it, and it stores it to a database. It then tells a mini-DNS, which is a service that it's a micro-DNS server that talks to the main DNS servers that your customers use. So it uses traditional DNS zone transfer to get information from the Designate database onto the presentation DNS servers. Now, we are going to be changing this in the next cycle, which Vinod will be going into in a few minutes. So Vinod talking about pools. So pools is a concept that we introduced in the current cycle killer. Pools are a set of discrete name servers. Why pools? If you are a corporation that wants to have a separate name space for internal and external sites, Pools allows you to do that. You could have a private pool for your internal sites and a public-facing pool for all your external sites. And the other advantage with pools is also that with pools, you can have different capabilities and you can have different sets of different levels of servers. If you have a large number of domains, you could also split the load among the name servers with having a number of pools. The other advantage that pools also provides for developers is the back-end plugins is simplified a lot. Currently, for the back-end plugins are responsible for all of the operations, any of the operations that change data. For each API operation that changes data, you need to have a corresponding operation in the plugin that changes data in the back-end. For example, if you modify or create, delete a record set, for a bind plugin, you would probably need to modify the zone file and then do a corresponding RNDC call to inform bind about the changes. Going forward with pools and mini-DNS, as Graham had talked earlier, this simplifies a lot. The back-ends can get all the changes from the mini-DNS. Since the mini-DNS talks the DNS protocol, but the back-end doesn't really matter what back-end you're using. It can just, as long as it talks the DNS protocol, it can get changes from the mini-DNS using a XFR currently. The plugins are just responsible for the creation and deletion of zones. So how does this look like? So for the happy path, the user makes some changes through the API. The API talks to the central. Central persists the changes into the storage. It then informs the pool manager. The pool manager, in the case of create and delete, it talks to the back-end. And the plugin informs makes the necessary changes on the back-end DNS servers. For any changes, the pool manager talks to the mini-DNS. So there are two functionalities that the mini-DNS provides for the pool manager. One is to inform of any changes in the zones. Mini-DNS sends out a notify to the back-end DNS name servers, and the back-end DNS name servers and receiving a notify send out an AXFR and AXFR. Currently, we support AXFR. We are planning to support AXFR in the current cycle. So Mini-DNS then sends the updated zone to the back-end DNS servers. The other functionality that the mini-DNS provides to the pool manager is to actually check whether the change has made into the back-end servers. Mini-DNS queries the serial number of the zone to the back-end to verify whether the change has made it into the back-end. Once that is there, it informs the pool manager, and then the pool manager marks the change is active. So the user can actually check whether it's active at that point. Now, Tim Simmons will talk about the API. So now that you know a little bit about what Designate is, I'm going to tell you how it works or how you can work with it in your applications and services. So Designate features a RESTful API, like any other OpenStack service mostly. There's a few features here I want to talk about. You can filter on resource data. So for your domain site, you can say, give me all my domains where the domain name is like this or equal to this. You can paginate your queries to the API. So if you've got a lot of resources, you can simplify that a little bit. Nested collections are a feature in some of our resources that allow very focused changing in certain places to allow you to minimize the number of queries you're going to have to make to change a lot of things. The API is easy to extend. I'm going to talk a little bit about that later. There's pretty robust policy enforcement. So there's a lot of different things that you can allow only users or admins to do. And right now, the Version 2 API for Designate is experimental in kilo. Should be the last cycle. Some of the resources that you can manage, you can see here zones, record sets, records, top level domains, blacklisted domains, quotas, and new very recently pools. So zones are kind of the primary resource that you'll be dealing with. Traditionally, these would map to zone files on your customer facing or application facing DNS servers. They contain a number of sub-resources, traditionally records, record sets. The fields that you would give to this kind of thing would be your domain name, your TTL, and maybe a description. It's also possible in Designate to import and export zones. So we provide an API that if you change the accept header to text DNS on imports, we'll take that zone file, hopefully, from somewhere else that you have, and parse that and put it in Designate. And if you're trying to maybe migrate away from Designate or maybe just back up your zones, you can export them so that you can kind of have that peace of mind or have an ease of moving between systems. There's also a tool in our contrib directory allowing you to take some zone files from a server that you've already got and prepare them for import into Designate. See, it's a pretty simple zone file that you get out. And it's a good feature to have. Record sets are a very important resource in Designate. All of the various record types that you might use on a daily basis, A's, Quad A's, C names, et cetera. You see the ones we support now, but it's pretty easy if you have some other weird record type that you like to use to add to Designate. So we encapsulate them into objects. And each record set type has a different data field that you can see in records that will be important for that record type. So for A records, that would be an IP address for C names, a fully qualified domain name, SOA records, expires, retries, that type of thing. You can see that record sets have a sub-resource that would be records. And you can modify a list of them or add or delete many of them at one time. That's one of those nested collections I was talking about. TLDs are another thing that's useful to manage. So there's a lot of TLDs out there. They're adding new ones seemingly every day. So in Designate, you might want to allow only certain ones to be added to your system. And this is what this lets you do. By default, Designate will allow any TLD. But when you start adding them through a convenient API, you get a very fine-grain control on the ones that you want to allow it in your system. So here we're adding .com. It's very simple. You just add com. And now your system will allow com domains. You can also add blacklisted domains. So these would be domains that you don't want in your system for customers or other people to add. So you could imagine that there's a lot of domains that you might not want in your system. And it would be tedious to put in every single one of those. So Designate allows you to use a regular expression to enable or to disable a big block of zones. So you can see here that in the first example, we have example.com being disabled. And in the second example, all of the subdomains of example.com and example.com being disabled. So pretty useful. You can also get floating IP pointers to your PTR, or you can make PTR records to your floating IPs in Neutron. So an operator would delegate the inatter.arpazone to Designate. And then users could make PTR records that were associated with IPs that are on their tenant in Neutron, which is pretty helpful. It's also really easy to extend the API. So there are various reasons that you might want to extend an API. You might want to change the way something works or add some custom endpoint. Maybe that calls a service that's not in scope for Designate, or maybe you just got some custom code that you want to throw in there. It's really easy. So all you need to do is create a controller and a view, just like any other API in Designate. Just using PICON, like most of you probably know how to use, add an entry point, and add it to your configuration file, and you're good to go. So I'm going to talk to Andre about the client. Yeah, so I'll mention a few things about the client or the client CLI libraries stuff. So the client is kind of like any other client that you have in OpenStack, like Nova, Cinder, Neutron. It comes with a library to use in your Python scripts, but it also has a CLI that you can use. Currently, we're offering only the client for V1, so you'll not be able to use it for the V2 one yet, since it's not stable. It also provides a lot of diagnostic stuff you can do. Like in, for example, Neutron, you have some debugging stuff as well. We have the same little thing, kind of. It's also the thing you, as an operator or as a user, would use when you're interacting from the command line. So what you can do with the CLI, you can create records. So I mean, sorry, create zones. So say you're wanting to create like xml.com. It's like Designate, domain create, and then dash dash name and the zone name. And you can also give it the TTL you want at the same time and the email that's going to be responsible for that zone. You can also show the information battle zone. You can do like domain dash get and then the zone ID. You can list the whole list of zones that you have in your tenant or the project by using dash list instead, like domain dash list. There is a ability to update zones, like if you want to specify new TTL or you want to change the responsible email for that zone. You use domain update, and then you can give it the ID. And then the dash dash TTL option, to set like new TTL of, say, 1,800 seconds. You can delete a zone by giving it the ID and delete the zone and all those records. So you can also operate on records, like if you want to create a new A record for your server, you can do that by doing record create, giving it the zone ID again, and then setting the name. You'll have to give it like www.xample.com and then a type of A and then like a data field of the IP. You can read records as well or list them and read them like you have a neutron. There's a way to list networks and to show the network as well to get the details. We have the same thing for records. You can update. Actually, that slide is wrong. You have to get a record get and then the domain ID and the record ID to get it. For updating a record, you can say, I want to set a TTL on a record. Say you have an MX record for a mail server and you want to just change that. You can change the TTL just for that record by giving it the TTL option when you're updating it. And to delete a record, you can use the delete command to delete that record. If you're, say, removing an A record for something. So when it comes to diagnostics, we have a few tools for giving you like the ability to sync a zone. So if you find out that your zone is out of sync on your name server versus what is in Designate, you can use the diagnostics command. Either synchronize all domains or synchronize one domain or you can synchronize a given record, but that usually triggers the synchronization of the whole domain anyways because the way of the backend works. So you can get some reporting statistics as well. You can get like counts on different things which is mentioned up there. You can also report stuff just for a given tenant, like how many domains they have, which is pretty useful at times when we're wondering how many domains are in the system, how many domains is in one tenant or any other counts that we support at the moment. So next up I'll mention Designate Sync, which is, we named it Sync because it was like a kitchen sink for all the events coming in. So this is basically how we take a notification coming in from Nova or Neutron or any other system and do something useful with it. We can have like, you can make your own thing as well, like to extend it or customize a given handler that we have. A handler is just a Python class or an object which will get loaded by Stevedor in the Sync. So to create your own, you can just check the example there and it's just like the controller example that Tim mentioned for the API. So say you wanna create a record for a VM when you give it a flowing IP. You can enable the Neutron thing, I mean the Neutron handler, but first you need to always have a domain ready usually for the handlers that comes with the sync from like the standard ones. So you create a domain that you want your VMs floating IPs residing and you enable the notification handler in the Sync section and then you need to give it the ID of the domain. So when you've done that, you basically start or restart the Sync service at the moment, it doesn't load it from any database. Then you boot a VM, so that's fine. Then you give it a flowing IP like in Neutron or via the Nova CLI. And then Sync will get like any other service listening for notifications to receive the notification and will actually call out to Central and say, hey, make me a new record with the name of this VM dot, or I mean appended by the domain name that you have. So questions? I think there's microphones across the floor there if anyone has any questions. So currently our providers providing DNS abilities to tenants without designate. Sorry, can you read the question? Yeah, without designate our providers providing DNS services to the tenants, do you have any ideas? As far as I know, there's no major open stack providers bar or rack space who provide DNS service to their tenants. You guys had a proprietary version still running. There's nothing else currently in OpenStack that does it. Is there integration with Solometer for notifications or something like that? We emit a load of notifications and they can be read by Solometer, we haven't done any, we haven't fully integrated with them yet. Where's the client code at? And is guaranteed, so it's, is it released in Juno or is it, what's its status as a program or sub-program? As a program? I.e. can we rely on it working and upgrading correctly into Kilo? Yes, it's currently an incubator project. We got incubated in Juno. There is a current production instance of designate running public accessible production instance so we won't break ourselves, we can make sure there's an upgrade path. The V1 API is stable and the V2 API should be marked stable in Kilo. We're waiting, we just wanna make sure we implement the right features before we call it stable and not causing us to have another version because we wanted to add something to it. You said there's a public version available, is that on the HP Cloud? So what do I need to enable to do something like an example.com on the HP Cloud to test this? If you log into your HP Cloud account and go to Horizon, there's an activate services button at the top and there should be a DNS button there and once you do that, you'll have the Horizon interface to designate and you'll be able to use the client. You'll be able to use the client as well, yeah. Thank you. Is it, is it plugable at all? I mean, can we use the API and plug in a different DNS back into it? Like a different DNS server? Yeah, and all of the processes to update the external DNS. Yeah, pretty much everything is plugable. The back ends are all fully plugable. So we have back end support for bind, power DNS, NSD, free IPA, I don't think there's anything else. Infoblox has a back end coming in as well. They have one in their own repo. And there is a Microsoft DNS one being released as well. So that was in your diagram when you had the back end at the top, but it's still gonna use the mini DNS to design transfers to that? We are, at the moment where that's how we're planning on pushing out the information, there is potential for other avenues if there's gonna be a small amount of people that won't be suitable for. So we have, that's one of the sessions we had this morning actually in the design summit was how to enable people to have non-DNS transfer of information using, trying to be more like the traditional back ends we have currently. And is there any link between the DHCP processes in Neutron? Not yet. Okay. It's, we only just got incubated, so it's been trying to get integration with Neutron is very difficult until you're incubated and even then it requires a lot of work on both sides. Do you, is there any support for the dynamic DNS in to designate? The RFC dynamic DNS? Yeah. No, but it is definitely on our roadmap it's something we want to do. Seeing with sync the name of the VM can be automatically signed. How is the name selected? Is that the instance name or something else? Yes, the instance name that comes through in the notification. Yeah, so actually there is a format option so you can actually set in the config for the handler what it's going to use from the notification. So if you have any other data coming in from Neutron or Nova, you can actually use that and it'll be like a string template in Python that'll use. Anything else? Current, the question was what's the deployment recommendation? Current, it doesn't really matter where you can run it on a control node or you can run it on VMs. Either will work. So we're actually running it on the public cloud in HP. So we're running it like a series of VMs. Yeah, we're currently running production in VMs. Yes, everything talks pretty much via RabbitMQ internally. So you can scale out anything that you think is going to be hit hard or needs a lot of resources. And if one of the central's dies, for example, the others will just take up the slack. To piggyback on the last question about instance names being mapped automatically in Disgnate, what happens if you have two VMs with the same name? Well, it's a valid record. You can create a record with two IP addresses. You can have two records with the same name on different IP addresses. Okay, so it's like a round robin, for instance. Yeah, that would create a round robin record, for example. The handlers that we ship with are supposed to be examples. They're not designed, they're not, they'll work for most use cases, but if you want to do something more complex with them, it's very easy to extend them and put whatever logic you want into those handlers. Okay, thanks. You had a question? Can you repeat that? No, it's so, well, I mean, you can use it like any other service in your cloud as a user as well. It's publicly accessible. So you can use, anybody can use the API or you can have your control panel integrate with the API to put in whatever data that a user wants to. So there's a lot, you can use, any person can use it once it stood up somewhere so you can have many tenants and many users using it. For example, with HP Cloud, a lot of people, loads of people point their NS records at our name servers and use the horizon interface or the command line to manage their own DNS. It's, the sync handler is just an example it wouldn't necessarily be used by a large scale public cloud for doing the auto generation of names. It's an example, they're put in place to give people an idea of how you can use the handlers and to go and extend them as they see fit. It's mainly aimed at end users rather than infrastructure for getting, so it makes it easier for end users to manage DNS rather than them having to write its own files and run DNS servers themselves. Hi, concerning the notification sync, you introduced one for floating IP auto registration. I wonder if there are a similar one, but for internal IPs, let's say I have two VMs I want to register it automatically and use FQDN to communicate instead of an IP. Yeah, there is a no fixed IP one as well but the problem is we don't, so that would end up creating like a Nova name on a public DNS with an internal IP. So at the moment we don't have like a DNS thing inside the tenant's network, but once the pool stuff is in place and the MDNS stuff is working well, we can plug that in there and we're gonna have like a tenant network only visible DNS server. That answer is that. So that's kind of like all the pool stuff and all that is kind of leading up to features like that? All right. I'm going to piggyback again on my last question about multiple instances with the same name, right? So I have a tenant, I call it, I call my instance name hp.com, then I have another tenant that also calls his instance hp.com, what happens? There's two instances. You don't want to create round robin DNS because it... Yeah, and this is why it's an example handler. It's not supposed to be used fully. It's to give people an idea of how you can take the notifications and use them and then put in your own business logic. But if that driver would be used, it would create the round robin. There's no like tenant isolation or some... No, if you wanted to avoid that, you could put the tenant name, I think comes in in the notification so you could create machine name, tenant name, DOS, whatever domain is assigned in the handler config. Okay, thanks. Hi, integration with heat? Yeah, we were just talking about this today. We really should do it. Yeah, it's quite definitely on our roadmap and it's something that we just need to sit down and do. I'm not sure. I think he will take us into the truth folder. But it is definitely, we aim to get it done soon. Another question, integrating with Icehouse. Is it possible? Integrating... Designate with Icehouse. Running it on an Icehouse, yeah, it's possible. We've run it since Havana. I think even Juno should actually work with Icehouse. Might be some conflicts with the sync stuff because of maybe changing notification contracts, but Keystone and stuff like that doesn't change so it should work. Thank you. Yeah, so one of the things that's kind of missing at the moment is applications running across multiple availability zones and using maybe DNS to provide wide IPs for DNS load balancing to get you to the closest regional availability zone. Is that something that you see designate integrating with other projects to facilitate? The sort of the Route 53 style health checks for DNS records or it's definitely something we've been talking about and there's a lot of work going on in Elbass at the moment that we should probably coordinate with. It's difficult to know how far down the road designate should go, but we're open to suggestions. If anyone has something they think we should be doing, please come talk to us and tell us. We're more welcome to hear how people want to use the project. And the other question I've got is when DNS breaks, it's a pretty bad situation. And because of that, there's a lot of, especially in large enterprises, there's a lot of nervousness around change in DNS. And so to have a system that allows users effectively to go in and make changes to DNS that will go and sink into a production DNS instance is a pretty nervous situation in large enterprises. So has that been factored in at all? And you don't know, you've just enabled it. I say designate is in use by large enterprises that they have delegated certain zones inside large enterprises to designate. It comes down to whatever your team is doing at the time and if they're dealing with your IT security people to prove that having the users be able to do it themselves is a valuable ability in a fast-moving business. Okay, so you do using it by its own delegation? Yeah, nothing will result to it unless, say, HP.com delegates, example.hp.com to the designate name servers. It won't resolve example.hp.com until hp.com points their NS records for example.hp.com down to us. So, okay, so when you say points down to us, sorry, the backend name servers have got to be dedicated to the OpenStack instance. They can't be existing name servers that exist in your enterprise, okay. It's trying to manage and keep everything in sync with that will be quite difficult and it would open up the opportunity to overwrite stuff that shouldn't be overwritten. Okay. Any other questions? Yeah. The question was, do you push any metrics to anywhere for billing purposes? Yeah, so at the moment as was another guy as well that asked for salameter integration, but we don't have that yet or I mean, we in HP have our billing stuff, so we build DNS, but at the moment there isn't any integration between designate and salameter, but I guess, I mean, we're an incubated project so it has to be on the roadmap, I guess, to provide that. We do emit events, though. We do emit what do you create a domain, create a record, delete a record. We do emit a notification event like every other DNS or every other OpenStack project. Yeah, but we don't have anything gone into salameter yet. It's a roadmap item, yeah. I had a question about floating IP integration. What is, how does the fact that IP floats or not have to anything to do with the DNS operation itself? What is the use case there? For example, if you have a floating IP assigned to your mail server and you want the reverse DNS for that to say mail.mycompany.com, that's the use case. And it's generally, if you're running a mail server, for example, that doesn't have a reverse DNS entry, it'll be marked as spam. So there's loads of use cases for people having reverse DNS control of their own IPs in their tenant. You can also, if you go to a different use case, if you have an Ironic, for example, in triple O, you can have Ironic emit notifications when nodes come up into designate, if you're running designate in the undeclide kind of, and designate can then create records automatically for, say, the ILO interface when it comes up or is discovered. That's one use case. Any other questions? Yes, if you add limits to the number of zones or records that can be created, it's configurable so the admin can decide for a tenant how many zones or records they can create, and if you go over that, you can't create it anymore. But there's an API for it. Yeah, we have an API and the client as well as, like, you can go, like, photo update and then, like, the tenant and the quota you want to set. Thank you. Thank you. One last thing, we're both HP and Rackspace are hiring, so if you're interested, come talk to us.