Split domain and zone information

[maxblome]

Is your feature request related to a problem? Please describe.

Currently, you always have to create a zone whenever you want to document a domain. However, if you have domains whose zones you don't manage, you'll still end up with a zone, which in that case isn't accurate.

In addition, you currently cannot see directly whether a domain has zones in different views.

Describe the solution you'd like

It would be great if there were a new "Domain" (or "RegisteredDomain") model and if the registration information currently linked to the zone were transferred to this model.

It would also be great if all associated zones were linked, regardless of the view.

Model

Domain
    name: str
    nameservers: list[Nameserver]

    ...registration information (currently in the zone)

Describe alternatives you've considered

Additional context

[peteeckel]

Hi @maxblome, thanks for your idea.

I must admit that I don't think NetBox DNS should be extended in such a way. Maintaining registration info is more or less an add-on for DNS zones, not something that is meant to be a core functionality of a plugin designed to store data that you use to provision DNS infrastructure.

For documentation purposes I recently added the status "External" for DNS zones, which essentially means "managed elsewhere". An external zone is basically inactive, although it does have special functionality in the context of RFC2317 and will probably get some more for IPAM DNSsync in the near future - just haven't figured out whether this is actually useful.

I see the issue of still having to provide zone-related stuff such as nameservers, a SOA MName and RName and - although automatically created - an SOA record that is basically meaningless for an external zone. But IMHO it's easier to just ignore that stuff (or provide a zone template with dummy records for the mandatory fields) than it would be to create another model that would resemble a zone for registration purposes, and not really be a zone in all other aspects.

Apart from the modeling stuff, also think about the dynamics - a "Domain" or "RegisteredDomain" would need to have paths to become a "Zone" and vice versa in case a domain registered elsewhere would move to local hosting or management. So the next logical stuff would be to make it a "Zone" with special properties (no mandatory fields etc.), which would further complicate thinks like validation and (bulk) editing - which are, to be honest, complicated and involved enough as they are.

During trainings, it's difficult enough to explain the difference between a zone and a domain as it is - having both in a plugin that is (and IMHO should be) focussed on the provisioning of DNS servers would make understanding the concepts even more difficult ("I've created a domain, how can I add records to it now?" ... that kind of question will inevitably pop up).

So I hope you understand that I will not put any work into this request.