nameserver to zone relation enriched

[LuPo]

I am thinking of a possible implementation of an intermediate model that adds information specific to a zone in combination with a given name server.

At the moment I can use custom fields on the single models: e.g. specify DNS provider on a given NS, so I can deploy the zone to an on-premise bind/pdns or cloud based provider. I would like instead to specify for a zone it's mode of operation as either primary, secondary or native (pdns) on a name server basis.

I am wondering if it is enough to introduce the intermediate model to the existing many to many relationship between the zone and NS. There are potentially other options that could be added in the future - I think here of the binds allow-querry, allow-update and others that can be specified on a zone statement. Although some of them might be server specific there are functionalities common to different server providers.

I see that there is some additional thought to be made. Some of those configurations that can be specified on a zone while differ between other authoritative servers for the zone, can also be specified on a NS level as default for the server instance. In this case, would it also be desirable to extend the NS model with some additional fields?

It seams to me that this is relevant to what @peteeckel mentioned in the discussion in #63 the use of the third-party tools for deployment of name servers. While it is difficult to think of possible options to configure all aspects of a zone or NS, the mode of operation setting I started the discussion is a nice to have it stored in the netbox-dns.

[peteeckel]

Hi Lukasz,

welcome to the jungle :-)

I think you are quite correct in your assessment of the options that might make sense to integrate into NetBox DNS. There is some information that would find a rightful place in the data model, e.g. the DNS provider for nameservers. I would actually think that adding a separate model such as "DNS Provider", creating a many-to-one relation with NameServer objects, would be a good way to do that. That way you could control which provider which zones are deployed to, and maintain the provider specific information in the provider model.

I thought about your other ideas what could be incorporated into the NetBox DNS data model, and regarding all the stuff that's specific to name servers - as you anticipated - I'd advocate against that. Main reason is complexity, and testability, as which every dimension we add to the data model the number of things that need to be tested (automatically!) multiplies. I'm just trying to contain that issue with the RFC2317 sub-project, and it's not easy to do.

On the other hand I see in my own practice that having a model for the name server infrastructure itself, be it BIND, PowerDNS or some cloud service, would be great as well. While putting it all into NetBox DNS might make the whole thing a bit unwieldy, I could imagine creating some server or provider specific module that interacts with NetBox DNS and abstracts away the name server specifics. So, for instance, there could be netbox-dns-bind, netbox-dns-powerdns etc. plugin that covers all name server specifics and connects to the NetBox DNS data model. The idea is to abstract away everything that is not strictly part of the common base of DNS data. Actually this kind of module could be used to cover even the "DNS provider" information mentioned above: You could configure which name servers are run on a provider's platform in the platform specific module, and link to the NameServer object in NetBox DNS.

That way we would get the best of both worlds (provided it can be done in a reasonable and NetBox-conformant way): Have a clear, server-agnostic and stable model for the DNS data and still all the mechanisms we need to model the DNS infrastructure depending on what server software is targeted. And both can be tested independently, so testing effort does not increase exponentially with each new platform. That of course requires a stable data model in NetBox DNS.

There is already the https://github.com/jcollie/octodns-netbox-dns plugin that (I believe) follows that idea, so I think it would make sense to expand that approach to other name servers - or even use or expand on that model to cover all use cases. I'm sorry I didn't look more deeply into it as it looks quite interesting and it's been on my list for a while now, but that could be a first approach to this task.

Cheers,

Pete.

[LuPo]

Hi Pete. I am glad to get your thoughts on this issue. I'll try to unpack what I understand and explain better what I meant starting this conversation.
First and foremost it is important to focus on the netbox-dns data model and nail the properties common to zone deployments across multiple servers. We should not be focused here on the specifics of different DNS providers, as these should be handled by third-party provider-specific modules. I'll expand on it in a while.
We already have a fearly robust zone and record models that make us generate and store RRs and populate a zone in the DNS. However, it is not sufficient alone to configure a given DNS server/provider.

I like your idea to include a "DNS Provider" model because you can store in it certain attributes that can differ between providers. For instance: an API endpoint to manage the instance could be one of these. We do not have to provide many attributes on the model, but it could be very useful that one can add custom fields that represent specific needs. In such a way it could be possible to use data stored in netbox-dns to push the zones to the infrastructure. With this, I do not mean to model the entire DNS service e.g.: who is allowed to query or transfer a given zone, never mind other hundreds of possible knobs.

I am not sure what you mean here with "platform specific module": is it about some piece of external software that could model and hold the data that makes you configure every aspect of zone confguration on a given DNS server? However it is, it seems out of the scope of netbox-dns, am I right?

My proposal here was to create an intermediary model - like the one described in django extra field on many-to-many relations, that adds an attribute which is bind to both the zone and the nameserver:

class Zone(models.Model):
    name = models.CharField(max_length=128)

class Nameserver(models.Model):
    name = models.CharField(max_length=128)
    members = models.ManyToManyField(Zone, through='ZoneOnNS')

class ZoneOnNS(models.Model):
    zone = models.ForeignKey(Zone, on_delete=models.CASCADE)
    nameserver = models.ForeignKey(Nameserver on_delete=models.CASCADE)
    mode_of_operation = models.ChoiceField()    # ["master", "slave", "native"]

Netbox-dns should document the entire DNS fleet one owns. If we define all the authoritative servers on a zone definition, those can be primary/secondary or even ones not offering zone transfer. Your external tool after retriving a zone from netbox-dns data model needs to know to which serwers the zone needs to be doployed. And one NS can be primary for a pool of zones and secondary for another.
On this model one can also specify some of the already cited attributes (even as custom fields).

Lastly you have mentioned jcollie netbox-dns provider for octoDNS. The latter relies on other "providers" that share Record and Zone data model so you can daploy the zones between different DNS vendors. It allows you to create a zone if it does not exist and update it with the records sourced from configurred providers. E.g. netbox-dns to pdns and route53, or Azure to NS1 ecc.
In order to automate the deployment I am using netbox export templates on netbox-dns zone model to build octoDNS configuration file for the queried zones. I retrive the source of data (netbox-dns) and destination nameservers along with some RR ownership definition (you can ad example include or skip certain records based on defined criteria). It compleates the configuration file with the authoritative nameservers definition for the queried zones. I maindly deploy to multiple powerdns configurred without zone transfer, but some of the servers rely on AXFR. Hence I need to differentiate between the authoritative NS to which I am pushing the given zone

Hope this lights up a bit the jungle I have entered. :D