 Okay, so I guess I'll start off with some introductions. We have Graham Hayes, he is a software engineer on the HP Cloud DNS team and one of the Designate Core reviewers. We have myself, Kyle McGinnis, I'm the Designate PTL and the tech lead of the HP Cloud DNS team. And we have Tim Simmons from Rackspace, software engineer on their Cloud DNS team. So what we're going to talk about today, we have overview of Designate, quick intro to what we do, quick intro to the APIs, client libraries and so on, and how we integrate with the DNS servers, so how we talk to bind, how we talk to all of the other guys, and a little bit of our current integration with Nova Neutron, which is called Designate Sync. We do have some plans for some more advanced stuff, we've got some working sessions with Nova Neutron tomorrow, so keep an eye on that space. So first up, what is Designate? Designate is an OpenStack style REST API for managing DNS. So architecturally, we're very, very similar to Nova Neutron, sorry, to Nova and Trove and so on, in that we aren't a DNS server, we instead orchestrate and manage the DNS servers. So if you want to use bind, perfect, if you want to use ACMI, perfect. So we have two different models, on-premise, that would be using like bind or power DNS, you run the DNS servers yourself, you have the whole infrastructure under your control. The other model is where you integrate with a third party, so we currently support ACMI and Dinect. So they'll run your front-end infrastructure that the customers actually query, but you'll manage the control plane. So why would you use Designate? As I think everybody knows, DNS is not cool, it is absolutely not the coolest thing you're going to have. It doesn't have Docker in the name, it doesn't have Neutron in the name. So it's plumbing. Everybody has something there today that mostly works, every company, every cloud has something there, but as people are starting to move towards cloud and they're able to turn around and go, Nova boot, why are we filing support tickets for the IT department to actually have the DNS provisioned? So we should start giving users the full control to go end to end. So yeah, that's why. So I'm going to hand over to Graham and let him talk a little bit about the API and client libraries. OK, so we have three real ways you can interact with Designate at the moment. We have a REST API you can query directly. We have a command line client that does all the major features, the basic stuff that users need to do with DNS right now. And we have a new OpenStack client-compatible command line client being developed at the moment. And then we also have Python bindings, which allow you to whatever you can think of doing and you want to do it programmatically, our bindings give you full control over your entire zone and all your records and record sets. The command line of the Python bindings obviously interact directly with the REST API, but with that we currently have three APIs we have available. As of Kilo being released, we have now deprecated our V1 API and we've moved on to V2 which is the latest and greatest API we have. It has a lot of nice features that allows you to have zones that are created by one tenant, transfer the ownership to somebody else. So say your one team is looking after a particular domain and they're transferring ownership to somebody else, there's a very nice way to do that in the API and just transfer the ownership directly over. We also have an admin API which has generic admin tools, things like you can look up the amount of usage for a tenant, so how many zones a tenant has, how many records they have and what the quotas that are set for each tenant and you can also set the quotas for each tenant from that API. The V2 and the admin APIs also support plugins. They're based off Pekin, so if you can write a Pekin controller, you can load it into the API when you start up the API service. So this allows you to take the power, take what design they can do internally and also expose it in whatever particular way that you might have internally to your end users. So I'm just going to show you, this is for the V2 API. This is a basic how to create a domain. So you just post with two simple key values, obviously if we were using keystone authentication, you'd have an authorization header at the top, but this is just a basic no off example. And this will return your zone and you'll notice that everything in the V2 API is now asynchronous, so you'll get a response immediately with the status appending and Tim will be going through in a minute how the status will progress from pending to active. So it's a nice, fairly basic object and also as part of the V2 API we decided that we didn't like just giving generic error. We were going to give slightly more feedback about what you did wrong. So can anyone see the problem with that request? Yeah. You notice a thousand, that's not a valid IPv4 address. So if you send that into our API, you get back this and it actually gives you the full path of where you went wrong, what went wrong and what it was validating at the time. So this will obviously make, when we start integrating it into Horizon properly, a proper feedback loop or even programmatically, you can look through the path of what the message is and the error type to really understand what went wrong and this is available on all the resources in the V2 API right now. So Tim is now going to show you how we go from the pending status to active. So just a quick little audience participation. How many of you this morning got out of bed absolutely psyched that you were going to hear about DNS today? Okay. It's a lot of people. You're all lying. I know you're all lying. That's not going to happen. So like Kyle said, DNS is not something that a lot of people get super amped up about except apparently in this room full of nerds. But kind of contrary to that, there's a lot of different ways that you can run DNS. It's probably because it's been around for such a long time. All of the things you see in a beautiful word cloud here are ways that you should be or definitely can run designate. This is important because every single person who comes into our IRC room or contacts us comes up after the talk is going to say, hey, can I run it this way? Can I do it with this DNS server? Can I do it with this configuration? And I think a lot of the reason that happens is because somebody has always got some old legacy system that they want to integrate with and it's DNS, nobody wants to change that. That's super boring. No product manager is like, yeah, let's go. We got to update that DNS server. So given that, designate needs to be a few things when it comes to talking to DNS servers. It needs to be flexible so we can talk to all those that I showed. It needs to be scalable because I don't know about you guys, but if you've ever had a DNS outage, a lot of people come and bang down your door and it's not a pleasant time and it needs to be simple because nobody wants to deal with complicated setups for something that should just work. So the way that designate does these things is down to a few of the components that exist in designate. So first I want to talk about flexibility. If you're going to talk to all of the different DNS servers that exist in some way or another, you need to speak a similar language. DNS has been around for such a long time and it was architected so well that there's a universal protocol for updating and transferring zone data between two DNS servers. I want to describe that briefly. Please don't fall asleep. It's going to get more exciting. Notify is when you as a DNS server say, hey, slave or hey, friend, I've got an update to this zone. If you'd like, you should probably come and try and get it. That slave or that other friend, master or whatever is going to try and perform an AXFR which is a full zone transfer. So the master is going to zip the zone file up into DNS wire format and send it along and then the slave can do with it what it pleases. So the designate component that does most of this legwork is called mini DNS. It's a very, very minimal DNS server that we wrote that's specifically targeted for these DNS protocol things. That sounds a little crazy, but we try to keep it very small, very simple and it gives us full control, which is really, really great. We can do things with that like configuring the frequency that we send those messages, configuring timeouts, configuring retries and if there's some error or some unfortunate thing that comes up during the process, we can go and actually fix it. Designate as a whole acts as the master for your zones. That's the source of truth for you. If you think about it like that, mini DNS or some cluster of horizontally scalable mini DNS nodes is going to be your DNS master. So that's going to be actually where those slaves come and transfer zone data from. And I say it acts as a master, there is a specific use case where designate doesn't have to be the master and I'll talk about that in a minute. So most of what I just talked about there is a lot of what you'll be doing. DNS zones don't get created and deleted too, too often. They're mostly updated because people don't want their zones going away on DNS servers for any period of time. So updating is pretty easy. For almost all DNS servers, they support that universal protocol and everybody's happy. Creating and deleting can be a little different though. Some DNS servers are backed by a database. So when you want to create a zone, you need to create a row and a table. Some have very specific protocols like binds which uses R and DC to add and delete zones. So you've got to integrate with that. Some newer, fancier DNS servers have REST APIs that you can go and use. And some have other services that you're going to go and call some other API out to. So trying to do that universally is not particularly possible. So as part of our pool manager, which is a mechanism for keep or it's a service that deals with the proliferation of DNS data from designate to whatever DNS servers that you need to manage and helps keep them in sync to make sure that they're going well. It has a customizable plug-in infrastructure so that you can choose and use whatever creating and deleting mechanism you need for the DNS back end that you choose. So like I said, for bind, you're going to call R and DC, blah, blah, blah. For power DNS, you're going to be adding rows to a table in the database. And that's really nice because there are all sorts of configurations even within, like, okay, I just want to use bind. It's like, okay, well, which way do you want to run it? And depending on those, it's going to be different, which kind of pool manager you use, which kind of pool manager back end you use. And if you have some wonky thing that you need to integrate with, this is a great place to do it because the stock ones work great, but there's no reason you can't write a custom one. For people who need even more control and they don't want to do a zone transfer directly to a DNS server, we have the agent. So this is a very small Python daemon that runs on or near to the DNS server and talks directly with mini-DNS. So it kind of implements the other side of the DNS protocol that mini-DNS is spitting out. This is really great in situations where you need total and complete control. If you're running huge bind and you don't want to run bind as a master and a slave at the same time, you can run the agent on that bind server, let it talk to designate and do all of the great things that designate does. And bind doesn't even know that there's not some poor engineer sitting there hacking out those own files and creating commands. Other situations might be where a DNS server doesn't support zone transfers or maybe down the line incremental zone transfers for some reason. You can just lay the agent on top of that and mini-DNS knows no different that it's not bind or power DNS down there. And you can integrate in whatever way that you want with the DNS server. What someone did recently is they used the Netflix client, the denominator, and they integrated that as an agent back in. So that literally you can call designate and then your designate can call another designate. So you designate while you designate. So, thanks to that guy, I guess. The one situation where designate doesn't have to be a master is called secondary zones. So you can set up in your company or your whatever a DNS server that you own and you manage, but it's probably unwise for you to try and run that as a highly available server for the entire world to consume. You're gonna get DDoS for some reason, you're gonna piss off somebody and it's gonna be a bad time. So what you can do is keep your cards close to the chest and tell designate, hey, I want you to add a secondary zone with my special snowflake DNS server as your master. And designate will go and do the zone transfer from that server and then fan it out to whatever DNS servers it manages. So if for some reason you don't wanna use designate's great API or client, you can do that. This is really great for a lot of other use cases. So Kyle's gonna tell you about Nova and Neutron. Okay, so in designate, we have a service called Sync. The designate Sync service is an event listener. It sits there listening to RabbitMQ for messages. The messages are what Nova and Neutron and other services can omit. So for example, attaching a floating IP, booting a VM. I thought that was a different slide after this. Attaching a floating IP, you'll get an event. If you boot a server, delete a server, you'll get events. And you're able to then take that information and run it through a plugin, a plugin if you're choosing. It will then turn around and look at the information in the event. That might be the house name, the tenant it's in. It might be the flavor. It might be all of that kind of information is available. And turn it into a series of actions against your DNS environment. So maybe it's add a new record. Maybe it's delete an old record. Maybe it's add another A record because you've booted a new load balancer. So it kind of sits on the outside of designate where we have the sync service listening to Nova and Neutron through RabbitMQ. And it then simply talks to our core service called Central. So it looks just like API calls coming in. It looks just like anything else you might be doing. So it has the full power that anything you could have done in the API. You can write this tiny little plugin. You can include two samples out of the box. They are the Nova Fixed and Neutron Floating IP Handlers. They're samples. They're really basic because every single person in the world has turned around and said, we want something different. We don't want the name of the VM.myDomain. We want something else. And we decided, okay, make it pluggable. The Nova Fixed one is, I think, eight lines of code. The Neutron Floating IP one is, I think, about 20 lines of code. So it's tiny. You're not writing, this isn't a three-week exercise to go build and write one of these things, at least not for simple use cases. So it's there, you have to, if you want to use this, you're going to end up writing a small plugin for that. There's a sample in the Contrib folder. It's an entire Python package. You pull it out into its own Git repo and it will install as a plugin natively alongside. So there's some samples there for you. And I guess we're going to go to questions. This went through very, very quickly. So sorry about that. Actually, timing these things is always very, very difficult. So do we have any questions? If you use the microphones, there's one there, just so that it's caught on video. Hey, guys. So my name's Joe McBride. I work a little bit with these guys, too. And I'm just curious for the audience, who here is running designate in production? Just raise your hand. Nobody in the room yet. Who is evaluating it to run in a dev or production environment? That's a lot of hands. That's 40, maybe? OK. For you guys, I got stickers. So come on. They're designate stickers. And by the time you go to production, you should be having these on your laptop. OK, I have, in fact, two questions, if you don't mind. The first is about the records that are handled by designate. And you said that, indeed, DNS is not some kind of fancy stuff. And there is no in technologies. But there are still records that are still new. For example, I'm thinking of TLSA and the SSH fingerprinting. I see a great use case of using SSH fingerprinted DNS. So I would like to know, that's my first question, if it's supported. OK, so we don't support TLSA. We just haven't gotten around to doing it. We do support SSH fingerprints. I see exactly the same use case as you. But to make that really viable, we need to make it worthwhile to do that. We really need to get DNS second place so that you can actually trust the chain and the fingerprint you get. And you never have to say yes when you SSH into that new server again if we get all of this right. Yeah, and that was my second question about DNSSEC support. Because you said that, and I don't know how agents are working because it was just clearly explained, shortly explained. But basically, if you have AXFR and you don't do DNSSEC in designate, you will just get, I would say, your zone file, which has no DNSSEC records after that. So if you send it, for example, to bind or port DNS, whatever, it will still be unsigned. So for us, it's completely important to have DNSSEC. So how is it possible to make it work? So there's probably a couple of ways you can do it. So the easiest to explain one is the likes of the Akamai backend, where Akamai will zone transfer from us. And they will sign the zone and publish it on their network of millions of DNS servers. So that's the trivial way. You can then take that idea and apply it if you're trying to do this today, rather than when we get it fully implemented. You can then take that same idea. And the agent backend, the agent service, is it effectively gets a copy of the zone, and you can then do what you like with it. So you could run it through the bind's DNSSEC tools to have it signed there and then. You could do that with all of the backends. Longer term, we're planning to get DNSSEC built right in. So when the zone transfer happens from mini DNS, it will get signed at that point, or possibly pre-signed a little bit earlier, and pushed out. So the whole zone should be signed at that point. OK, I saw a last question then about the, you said that the agent receives raw data from the zone. Is it specific on the backend that will arrive later? I mean, for example, bind as $generates things that doesn't work in NSD, for example. So what you'll get in the agent is you won't get a zone file. You will get, if you're familiar with the DNS Python library, you will get a DNS Python zone object. You can then do what you like with that. So you might call the toText method on it, which will render a bind zone file. Or if you need to do something like, let's say you need to put it all into Power DNS into the database, you might iterate over all of them and insert them into the database. So you have a bit of flexibility there in what you do. Does that kind of, so does that answer the question? Exactly, thank you. You should definitely come to our fishbowl session at 5.20, I think it is. Oh, yeah. The use case discussion. Yeah, before we forget, we have a fishbowl session at 5.20, where we want to try and get feedback from users on what they actually want, what we're doing right, what we're doing wrong, and so on. So please come. No. I put my phone away before this. Joe, do you want to look it up? OK, Joe will shout it out in a minute. We'll tell you what it is. 306. 306. Thank you, Joe. Hello, my name is Tom. I used to work for one of those DNS companies on your slide, and now I work for REC Space. I've been sent from the future to tell you of your pending doom. Excellent. Just kidding. You guys always like to hear about our doom. So I have a couple of questions. What types of records do you attempt to validate, and how do you validate those? OK, so records, any record we support, we will validate. We have a, for every record type, we have either regexes, or we break them up into component parts. So for an SSH fingerprint, for example, we break out the type and the encryption type, and the actual fingerprint to the separate objects, the separate variables, and then we do validation on those. It's pretty in-depth the way we do validation. For the most part, we try and make sure that everything that comes in through our API is 100% valid, even if there are cases where some DNS servers would accept us, because we deal with bind, parity, NS, Akamai, Dinect. And when one of those services doesn't support, I can't think of a good example right now, some of them will blow up if you put a CNAME next to an NS record. It's totally invalid to do that, but some will actually serve that, others won't. So we generally pick the strictest set of things and validate that. OK, cool. My other question is, and I think I heard you mention it, support for XFERS instead of XFERS? Is that coming? Is that something you're interested in? Which one? IXFR. So we haven't got that implemented yet. There's a spec up at the moment. We're still trying to figure out how we're going to track all of that state in a scalable way. That is on the cards, where many of the NS will do an IXFR if requested instead of a full zone transfer. Obviously, when you start getting to 500,000 record zones, doing a full zone transfer, it's slow. Yeah, also the note you had about zone create and delete, there is absolutely a cloud provider here who unaccidentally dropped 50,000 zones on a provider. And pushing 50,000 zones to the edge on any provider is painful. So just be cognizant of that if you're attempting to do what looks amazing, by the way. Just be careful what you try to push. Oh, yeah. At HP Cloud, we've been running it in production for three years now, two years maybe at this point. So we know it works. Is there any support for creating pointer records alongside A records? Yes, so you absolutely can create pointer records. So obviously pointers are a little bit weird in that two tenants of your cloud might have IPs next to each other, but they actually live in the same reverse DNS zone. You can't really divvy those up into anything smaller than a slash 24, not without a lot of cheating. So we have an API endpoint in the V2 API for handling reverse DNS specifically. And it will handle your floating IP space and so on. It will show them the list of their floating IPs. And you can just go, I want this pointer on it. And behind the scenes, it will shove all of that into a shared zone so that customers can see or touch each other's pointer records. I had a question that kind of talks about the PTR records. I asked Kyle the PTR for Neutron. Like host names are a good example of something that's really at the boundary of designate Neutron and Nova all kind of fight for who controls the host name if you get it through the metadata server of cloud and then it's Nova, if you get it from DHCP, it's Neutron. Is there any way that, along with that, are y'all going to stick on just the authoritative side? How do you see all these things kind of evolving together? So we have a work session with Nova and Neutron tomorrow about much tighter integration. Effectively, today you're right. You type in a name. It goes into Nova. It might be totally invalid. It's not a DNS name. It has spaces. It has special characters. It has all of that fun. Sadly, there's not much we can do there without breaking the Nova API. So we do have to figure out some way of providing that information through to Neutron. Neutron then turning around, creating the port, talking to its DNS mask, putting the right stuff in there. And then if you've registered a particular network or subnet and saying, I want my servers in this to have public names. Here's the designated main ID for it. Have them call out to us. So that's kind of the direction we're going at the moment. Tomorrow is when we're hoping to figure out some of the smaller details, though. So don't have a great answer on who will own the name. I have a question about how you get messages from Neutron and Nova. And I'm assuming that's RabbitMQ or MessageBuds. Are those Qs that's messages created for Designator? Are you just relying on the generic messages coming from Nova Neutron? All right, so we get the generic messages. So it's the exact same stuff that Celiometer listens in on. So if you configure Nova and Neutron just right, you don't really need that slide, do we? If you configure Nova and Neutron just right, they'll emit the notification twice, once for Celiometer and once for us. And that allows us to consume it. So you get all the Nova and Neutron messages? Anything any service emits into Rabbit, we can pull in. The plug-ins are what actually you effectively get the raw payload into the plug-in. And you can do what you like with the content of it. All right, thanks. Hi. You described earlier that Designate could actually act as a secondary with an additional primary upstream. Could you describe a use case for that? So a big use case for that is public cloud and enterprise not wanting to hand out, not wanting to get rid of their internal authoritative DNS server, but they want to make use of the public cloud's mix of DNS servers. So an enterprise doesn't want to stand up 200 DNS servers around the world to get a nice and fast. But the cloud providers and the DNS providers absolutely do, they have that. So that's, I think, the primary use case for that. Well, it does also open up a theoretical possibility where you could run Designate internally. And have a Designate driver for Designate that uses, say, HPs or rack spaces Designate install as the place where all your DNS data goes. OK, yeah. Take the hybrid cloud buzzword right there. Private cloud, federating the DNS stuff out to the public clouds. So in that model, you really wouldn't be able to inject additional records via Designate. It would really just be acting as a pass-through. Yeah, it acts as a pass-through. And the API will actually, if you try to do a record update in a secondary zone via the API, it'll give you a forbidden error. Thanks. Any other last questions? OK, thank you guys. And 303, 306. If you want to come tell us what we need to do next.