Name Server information: What to do with it?

[peteeckel]

Just today I was thinking about what we can do with the name server information, both in the current release 0.6 and in an upcoming one that will feature views.

Currently we have a list of name servers (by name, no other information), and we can assign them to zones. That's neat functionality, but the question is what we make of the information. I see a couple of use cases that are not exactly compatible:

1. Use them in zones to create NS records and SOA MNAME entries. This was the first thing that came to my mind, and currently makes most sense because we need some way of keeping NS/MNAME information consistent within the database.
2. Use them for third-party tools such as Ansible using the information within NetBox or direct exports from Ansible to distribute zone information and name server configuration (more and more I come to the conclusion that @gellis713 is right and the latter really is beyond the scope of NetBox).

Variant 2 does not make so much sense to me, as that would require more information about the name servers (such as their real host names) that isn't actually in the scope of DNS.

So I tend to Variant 1, and in this case it would make sense to generate NS records from the list of name servers in the same manner as SOA and PTR records are already created. Furthermore, if an NS record is within a zone known to NetBox DNS it would also make sense to verify that the A/AAAA record for the NS name can be resolved (CNAME is not valid here, according to RFC2181, Section 10.3).

To address the resolvability issue of the NS records, I see several possible approaches. We could warn the user if the name of a name server does not resolve to anything (taking stronger measures would create hen-and-egg problems, so we should not do that), we could include the address information within the name server table (which would, however, raise issues with different views having different addresses for the same name server, making it necessary to make the name servers' address information view specific as well), or we could do nothing at all leaving the problem to the user (which is not very user friendly and misses the point of using a tool for DNS maintenance). So probably in the first approach of issuing a warning message in the zone view if the name server record cannot be resolved to A/AAAA would be a good first approach.

[peteeckel]

As a first approach, I implemented the solution sketched as Variant 1 in #68. Please have a look at it.

[peteeckel]

After implementing the automatic generation of NS records in Netbox DNS and some other functions I started rolling out DNS data with Ansible, using nb_lookup for gathering data from the DNS records and zones, which works pretty well.

However, I stumbled across some problems when no NS are defined for a zone, because Bind does (rightfully) not accept a zone without any NS records. There are some possible solutions to the issue which I'd like to discuss, maybe someone has any ideas or preferences that I'm not aware of.

1. Make the "nameservers" mandatory when creating a zone. This would probably be the safest bet because, in real live, at least one NS record is mandatory, and so it would be ensured that zone data extracted from Netbox DNS are valid. It would, however, make importing data via CSV a bit tedious as CSV does not have a sensible way to format structured data such as a list of name servers within a data set.
2. Print a warning message in the zone view when no name server is defined. That is pretty easy to do, but it doesn't really solve the problem that creating such a zone from Netbox DNS data would result in an invalid zone file. So precautions must be taken on that level as well (refuse to create zone files for zones with missing NS records, for instance).
3. Use the SOA MNAME (which is mandatory) as a fallback. I don't like that at all, as in many cases the SOA MNAME is not in the list of authoritative name servers (e.g. with a hidden master), and that way the error of not having any NS defined would be covered and go unnoticed. Probably a very bad idea.

Personally, I tend to implementing variant 2, as it is the least invasive one and creates the fewest operational issues - validating exported zone data before trying to load them into an operational name server is advisable anyway, and Netbox DNS can't possibly catch all possible issues.