 So I'm Michael Johnson. I'm a principal software engineer at Red Hat and I'm also the project team lead for designate And today I'll be talking about a new feature that we worked on for antelope So it did ship an antelope Called shared zones if you're not familiar with designate. It's the DNS of the service component of OpenStack Let's get started So starting with shared zones, this is like I said new an antelope so 2023.1 Just a little review quickly. So DNS zones and designate they represent part of the DNS hierarchy This is how you add and manage your record sets So for example in the URL, I had it in green example comm is part of that DNS hierarchy that would be represented as a zone in designate each zone is owned by one project in designate and That has been a problem historically and that's why we've implemented shared zones Essentially, it means there is one project that has ownership can add remove record sets Etc. of that zone and create sub zones below it if you wanted to have maybe multiple projects have access to that zone You really couldn't do that historically So if you had like a marketing team that needed access to your top level domain as well as your IT support team That became a problem So why do we need shared zones? There's a couple different use cases here as I mentioned kind of the sharing across different departments that may have a zone that they manage You may delegate sub zones to different departments. So in the second case Delegating marketing engineering Having their own sub zones or finally in the cloud environments You may be allocating zones and domains per product or per customer In that environment and so if one project owned example comm that becomes very problematic As you go down that tree And then finally one of the other cases that becomes a real problem is the pointer record So the reverse domain lookup. So where you look up a IP address expecting to find the server name Those are quite large blocks and again if only one project can own it you get into some interesting issues with delegation there So in antelope, how do you share a zone? So we've created new CLI Commands for this Pretty straightforward open sack zone share create You'll say what zone you're gonna share and then the truck target project ID so You can have as many shares as you want of a zone So it's not just sharing with one project. You can share it with multiple if you have a use case for that The commands with an API is that we've implemented our create delete list and show for the shares And we extended the zone delete command to have a kind of helper function So if you just do a zone delete on a zone that's shared by default It will say sorry you need to get rid of the shares before you delete it But we've added a modifier that lets you say nope I know what I'm doing I'm gonna blow away all the shares when I blow away the zone at the same time You can kind of look at the data model for a zone share record pretty simple and straightforward Somebody's gonna own that zone share and that's typically gonna be the parent zone owner Again, that's the project ID listed there the target project ID is who you're sharing with And you'll have multiple records of like this, you know, if you share with multiple projects And then of course the zone that you're sharing with that other project So let's dig a little bit into What can you do when you have a zone shared with you? So you can obviously see information about that parent zone You're gonna need to know some details that TTL etc You can list all the zones that are shared or visible to you And Then the most important piece is when a zone is shared with you you have control over those record sets in that zone So you can see the other record sets that other people have created or the zone owner Create new ones update delete. You are essentially a co-owner of that zone Things we don't allow At least today we don't allow them to delete the parent zone. Only the zone owner should be able to do that Of course You can't change the zone properties. So you can't modify the TTL or the name servers associated with it that kind of thing You can't share it yourself. So if somebody shares the zone with you, you can't reshare it to other people That would get a little interesting Can't do his own export so dump the whole zone you can't create his own transfer request obviously giving ownership of that zone to somebody else that would Kind of make the parent zone owner a little unhappy And then finally we made this decision and at this point to not allow Folks to create subzones and this is something that may change in the future if people have a need for that or a use case for That I'd recommend you open a bug and let us know kind of what your use case is and how you would like that to look So right now if you need a subzone The zone owner will need to create that and then share that subzone with the appropriate projects It gets a little interesting when you're Delegating subzone creation who has ownership and how that that ownership change looks like so one of the nice features this enables is Doing classless in at our ARPA delegation Using designate. So this is actually RFC 2317 and this lets you slice and dice your reverse lookup zones and delegate out arbitrary blocks to Other projects so again a little quick review of what an adder ARPA zone is This is reverse lookups in DNS If you look at the zone file or the zone represent representation, it's the IP address in reverse order under the in adder ARPA namespace in DNS And so a pointer record if we had an IP address of 192 02.5 It would be in this zone and the pointer record would be address five maps to WWW example comm and so you can see kind of an example using gig if you use the reverse lookup That's the response you would get based on this zone configuration so the big challenge with IPv4 is These reverse lookup zones are on octet boundaries. So essentially the smallest Chunk of that reverse lookup space that you can delegate to somebody else is a 254 address Block that's not great considering we're out of IPv4 addresses right around most of the world So we're all trying to conserve how we allocate and delegate IPv4 addresses To various projects or customers and And as I mentioned at the bottom especially with edge sites where we have a lot of deployments with very small sets of endpoints required So how do we work around this challenge? That's what RFC 2317 is all about We use a CNAME alias to point to those Pointer records in the delegated zone. So essentially you have your normal parent zone You'll create a child zone that is essentially defined for what range of addresses you want to Delegate to some other project. So in this case, I'm saying One two and three is being delegated to Somebody else potentially and the nice thing here is that's an arbitrary block So you don't have to do Slash 26 block of addresses or something like that As you can see, it's not an octet bound boundary either. It's three addresses. So it's very untypical In the parent zone, you'll create a CNAME record that points to the record that will be created in the child zone and Address one so in this case you do one two and three and that essentially aliases from the parent zone into this child zone that we're going to let other projects have management over Then finally in that child zone once we've shared it with the other projects They can go ahead and create and manage their pointer records in that zone as they would like So let's kind of look at how that actually works and designate So we're going to create a normal Reverse zone and designate for that address space. You should pretty simple. We've done that for a while Then we're going to go ahead and create that child zone So the one that's just for the the three addresses that we want to delegate to a particular customer Again straightforward zone creation This is the new feature that we've enabled So now you can share that child zone with the project or your customer that will have management over those reverse pointer records I Discuss that earlier and here's kind of where the trick comes in we create that C name alias So your record will be the dot one address in the child zone It's a C name alias record the parent zone and then finally The address that we're aliasing Then once we've done that I In the previous slide I shared with the demo project in this example So now demo has ownership of that Reverse lookup zone and they can go ahead and create their pointer records or update their pointer records to create that Reverse lookup for the one address Very similar to a normal pointer record that you would create and designate except you're using that child zone as the parent so when we Implement this and use dig You'll see that instead of getting back one record when you ask for the full answer You'll get the C name and the C name will point to the actual pointer record in the child zone Most DNS servers will provide this in the extra information so you'll get that all back in one answer response It doesn't actually have to do a dual query to get that resolution But I will note Your resolver will need to have recursive turned on or it won't return both of those responses It'll only return the first response And again, if you look with the short dig look up you'll see kind of what you would expect It resolves to www example.com so These are great new features Where can we go with it in the future? And this is kind of where I'm interested to hear feedback from the community and maybe even contributors that are interested in working on this So if we think about integration with neutron right now There's a number of extensions and neutron that work on floating IPs and creating reverse pointer records One opportunity that we could do is in neutron when you have Subnets from a routable subnet pool So you're essentially allocating Like slash 26 blocks from an address pool You could have some kind of integration with designate that would create those child pointer zones for the slash 26 blocks and again just using Standard pointer records that would have to be a slash 24 block To be functional This is one integration point that makes a lot of sense when you're using smaller subnet pools the other question is around the floating IPs and When you create a floating IP You could have an integration that would create that child zone and delegate it to the project that created the floating IP Unfortunately in neutron It doesn't have an IPAM model that allows you to allocate blocks to a to a particular project at a time But if you have other IPAM integrations that might also be an opportunity where you could Have some automation that would Set up that reverse domain for you based on whatever block of addresses you want to allocate to a particular project So that's my presentation. I have about a minute if anybody has any questions Happy to answer them. Did you step up to the mic? So, hello, curious if we get full read of the zone and all the records set. Why do you disallow export? It was just a It's interesting question. I mean really we wanted to limit the scope of this feature and so there were things that You know like export and transfer and subzones that we thought Yeah, definitely because there are actually new rights over the read, but here it's like replacing For each on the list. So, okay, you just didn't do it. Yeah, I understand It is a little weird when you know, somebody else owns a zone, but you're dumping the whole zone But if you do have a use case for it open a bug and we can certainly look into Enabling that as well. All right. I'm out of time. Thank you