How best to relate records

[wolfspyre]

There's a few different relationships between things which have records and record types which currently aren't elegantly expressible in netbox-dns.

I'm explicitly NOT going to touch the concept of relating records to devices, or ipam resources, as that's an entirely different can of worms, which, while important, will likely only complicate this discussion.

Exemplars which come to mind

• subdomain zones
• devices with multiple addresses
• devices/services/sprockets with multiple names
• 'profiles'
• zone
• device/host
• service

Subdomains:

If I create the forward domain foo.baz in netbox-dns, and create another domain fuzz.foo.baz, there's no automagic way of expressing the relationship between them.

The process of creating fuzz's NS records, and branch record in zone foo.baz isn't hard to do manually.. so this isn't a HUGE problem, but it feels like it aughtnt be a manual process... also there's no relationship between them from netbox-dns's perspective... they're isolated creatures.

Devices with multiple addresses:

• My pet compendium is an nfs server. He has an interface on every vlan which clients connect to for NFS services, to avoid passing the traffic thru the firewall needlessly.
  Any time I create a new isolation plane, I create a new face to the NFS server, and plumb it up to the newly minted isolation plane to facilitate isolated shared storage.

There's not currently a clean way other than tags to convey that these 'storage records' all relate to the same physical object.

• My webservers each have a few different ip addresses for isolated services. There's currently not a good way aside from tags to relate them.

• My docker hosts each have a 172.x.y.z/24 allocated to them for docker's use, each host's internal subnet relating to the physical host's main address's last octet... I'm not sure how best to describe the relationship between host-22.baz.com : 10.y.z.22 and 172.x.22.0/24

Devices with multiple names:

So... I'm human. I forget things. So I add a few records to make things easier... a contrived example:
a UPS: ups-01 (cnames: ups-1 ups01 ups1 )
a webserver: web-01 (cnames: web1 web_1 web-1)

now... these two different devices provide service to a few different namespaces.... and so they're represented in a few different domains...

so...

ups-01.core.local
ups-01.foo.baz
ups-01.sidehustle.whynot

web-01.foo.baz
web-01.otherservice.com
web-01.sidehustle.whynot
Having an elegant way of relating all of these different hats a device wears would make it a whole lot easier when I'm deprovisioning web94

which brings me to

Profiles

it feels like having a construct which allows one to create a template of related records, and be able to invoke that might be helpful?

it seems like a lot of the plumbing is there, just needs to be wired together elegantly..... what I have currently been doing is just importing a blob of csv that I templatized an mangled in a text editor, but that doesn't feel like it's the most elegant way, long term....

just some stuff I figured I'd toss up for contemplation

[peteeckel]

Hi @WolfSpire,

thanks for bringing this up again, I think it's going to be interesting :-)

I'm explicitly NOT going to touch the concept of relating records to devices, or ipam resources, as that's an entirely different can of worms, which, while important, will likely only complicate this discussion.

In addition to it, it might require the NetBox project to document a few more interfaces for plugin use. Generally that's the problem: There are many things one can do, but I learned the hard way that it's not a good idea to use too many of NetBox' undocumented interfaces. The project is very dynamic, and it's not only 'Do not rely on it, it might change in the next few years or not', it actually will break. Been there, done that.

But now let's look at your ideas ...

If I create the forward domain foo.baz in netbox-dns, and create another domain fuzz.foo.baz, there's no automagic way of expressing the relationship between them.

The process of creating fuzz's NS records, and branch record in zone foo.baz isn't hard to do manually.. so this isn't a HUGE problem, but it feels like it aughtnt be a manual process... also there's no relationship between them from netbox-dns's perspective... they're isolated creatures.

Actually that's an interesting idea, and we could even detect the domain relationship automatically in many cases. When a domain is detected to be a subdomain of another one we could add the NS records for delegation to the super-domain automatically. On the GUI, I would also like the idea of displaying the subdomains of a domain in a separate tab on that domains detail view. At the very least this would be something that makes relationships between domains easier to see (and it would also help with the upcoming RFC 2317 stuff).

My pet compendium is an nfs server. He has an interface on every vlan which clients connect to for NFS services, to avoid passing the traffic thru the firewall needlessly.
Any time I create a new isolation plane, I create a new face to the NFS server, and plumb it up to the newly minted isolation plane to facilitate isolated shared storage.
There's not currently a clean way other than tags to convey that these 'storage records' all relate to the same physical object.

My webservers each have a few different ip addresses for isolated services. There's currently not a good way aside from tags to relate them.

We need to be careful not to confuse infrastructure with DNS data ... but I see what you want to achieve. Would it help you if you could somwhow link DNS records to DCIM devices and/or Virtual Machines? I'm not sure how much we can do at the moment in terms of accessing the NetBox dcim or virtualization objects from NetBox DNS, but if we can add related_device/related_virtual_machine information I think we can get the following bits of information about records without too much effort:

• Link from DNS address/pointer records to Devices/VMs (trivial)
• Links from Devices/VMs to related DNS records (much like the new IPAM feature in 0.16.0)
• Information which other DNS records relate to the same Device/VM

My docker hosts each have a 172.x.y.z/24 allocated to them for docker's use, each host's internal subnet relating to the physical host's main address's last octet... I'm not sure how best to describe the relationship between host-22.baz.com : 10.y.z.22 and 172.x.22.0/24

Not sure if you're maintaining your Docker hosts in NetBox ... but the idea outlined above for Devices/VMs would also work for Docker hosts if you did.

Devices with multiple names:

So... I'm human. I forget things. So I add a few records to make things easier... a contrived example:
a UPS: ups-01 (cnames: ups-1 ups01 ups1 )
a webserver: web-01 (cnames: web1 web_1 web-1)

now... these two different devices provide service to a few different namespaces.... and so they're represented in a few different >domains...

Idea: We could check for any CNAME whether its target is in NetBox DNS as well, and provide that information on its detail view. That shouldn't be too much effort, especially now since I started using more of dnspythons functionality. For performance reasons it will probably require to create a new model field fqdn in the Record model, but once that is in place it would be very easy to find all records that are pointed to by a CNAME, and it would probably improve performance in some other places as well.

it feels like having a construct which allows one to create a template of related records, and be able to invoke that might be helpful?

I'm not sure about that one yet. The idea is intriguing, but I've never come across any reasonable use case for it - apart from yours, obviously.

Just so I get your point, the idea would be to create a template for a set of records, e.g. an A/AAAA record and a bunch of CNAMEs, or a set of A/AAAA records in some domains where you just fill in the name and the records would be created together and linked together by the profile, correct? I can see how that makes sense, though currently my gut feeling is that it might not be a very common use case and the maintenance of that kind of connection can also be done manually without too much effort, especially now that the new global search feature for plugins is available.

it seems like a lot of the plumbing is there, just needs to be wired together elegantly..... what I have currently been doing is just importing a blob of csv that I templatized an mangled in a text editor, but that doesn't feel like it's the most elegant way, long term....

No, certainly not. If I had to do this kind of thing more often that once or twice a year I'd probably hacked together some Python code that uses the NetBox API to get the data in there.

That said, I would be interested if that kind of templating would be of broader interest, so if anyone wants to chime in (or even contribute code :-)), I'm open for discussion!

[wolfspyre]

Subdomains:

I think creating a sub-zone construct, and an interface into that would likely be useful with the RFC2317 work and subdomains, yeah...
That's kinda where I was going with the idea... figuring that it would help give the amorphous RFC2317 challenge a bit more of a structured scaffolding to work within... The same logic (delegations, relationships, auto-population/inheritance etc) SHOULD be relevant in both contexts, and thus gives a little more structure for the design requirements (I think??)

I think it's essentially another flavor of managed records.

Record relationships:

Yeah.... I think if we can relate a record to a netbox device, a lot of the multi-record-relationship issues kinda solve themselves, as they have a unifying 'parent' entity that the relationship can be bound to.... I just didn't want to point to that as THE way forward as I know it's a ...... sore spot? :)

as I've been typing this out, a different way of framing this came to mind....

I think there are broadly two types of relationships.... durable and instantiation/creation...
I think durable fall into this category, while instantiation are kinda solved by profiles...

I think the distinction could be identified by asking where it might be helpful to have this highlighted:

You have declared that these things are related.
You've changed one/some of them, but not all of them recently.
Is that intentional?

or some way of illustrating recent changes to a sibling/parent record... ... and there's more relationships than just CNAME <-> A.... think txt records... but it gets muddy quickly..
so I agree that having a unifying upstream object that any record type could be associated with, and a mechanism to represent those relationships would likely be juice worth the squeeze...

I don't know where the line should be drawn. For example, how should changes to thing which is present in multiple views be thought of?

Profiles:

I'm thinking the idea of a profile/template has many potential use cases:

• Zone scoped profiles: (these are contrived exemplars)

  • split-horizon profile, where you want a set of attributes set for a few zonefiles in a few different views
  • NS record profiles (internal NS| windows domain| external NS)
  • MX record profiles (goog | internal | $othermailhost )
  • DKIM, CAA,

• Host-related-record profiles: (this is a contrived exemplar)

  • "a webFOO host has an A record for itself as webFOO, a set of TXT records for service discovery, and CNAMEs for web-FOO, web_foo, and w-eb-f00.. and these should be added in zones X Y Z"

• Service-related-profiles: (this is a contrived exemplar)

  • an http/https server should have txt records added

and I'd think you'd want to be able to use templates in templates...

(even if not implemented immediately... The idea of having a nameserver bundle template for view A and one for view B .... and a split horizon template which references those bundles makes sense... y'know?)
Basically just trying to think of ways this might meander for the purposes of avoiding problems for future work

[peteeckel]

Yeah.... I think if we can relate a record to a netbox device, a lot of the multi-record-relationship issues kinda solve themselves, as they have a unifying 'parent' entity that the relationship can be bound to.... I just didn't want to point to that as THE way forward as I know it's a ...... sore spot? :)

Not really a sore spot, but something that needs sorting out in terms of it's support state by the NetBox project first ... I fell on my face a couple of times when I used unsupported stuff before, so I needed to be sure. The good news: We can do it. While it is not explicitly mentioned in the plugin developers guidelines, there is even an example where this is done in the plugin development tutorial, so ... looks good for this feature.

[clarksten]

Hi all,

is there an Update on the implementation of some kind of Documentation for Subdomains.
Or is it not even planned to integrate this feature?

[peteeckel]

Hi @clarksten, this repository is dead as a doornail. Its new home is here.

Background: Aurora Research Labs disappeared without a trace and left the repo and the PyPI project in limbo, so I had to fork and move to a new name.

Regarding your question: Yes, it is still planned to implement domain delegation support. Some things (particularly work for other projects and some unforseen actions like the need to fork and relocacte this one) came in between, and RFC2317 is also still on the list - on the other hand RFC2317 and domain delegation have some overlap, so it might be done in one go.