Allow the same zones within different "views"

[hiddenman]

We use external and internal views in BIND for the same zones, as many other people do.

For example, when we are inside the LAN, a host record like 'host1.example.com` points to a some local IP like 192.168.1.1.
The same record 'host1.example.com' when it get queried from external network, points to some real external IP like 195.XXX.XXX.XXX

https://www.cyberciti.biz/faq/linux-unix-bind9-named-configure-views/

Please allow the same zones but with different "view" types or something like that.

[jcollie]

Also known as split DNS. And doesn't necessarily need to be implemented via Bind's 'views'. I have one set of nameservers in the cloud that serve external DNS records, and a set of nameservers that run on the internal LAN that serve internal records.

[peteeckel]

This will probably be the next thing I am planning to give some attention after/if #52 will be merged. It does not make much sense to implement it on the basis of the "development" branch, as it will greatly affect forward/reverse zone relations as well.

One interesting part is how to handle environments with or without views. In BIND, if there is any view all zones must be assigned to a view, while when there is no view defined all zones by default end up in an implicit default view. So the best way of mapping this to NetBox-DNS is probably to make views entirely optional. On the other hand, if there is a view all zones must belong to one, so on creation of the first view all records currently in the implicit default view need to be assigned to it.

Then there is the question what should happen when the last explicit (non-default) view is deleted. That should be easy as the zones are already unique in that case and only lose their "view" relation, so they silently drop back to the default view - at least that is what I would expect to happen.

Moving zones between views is pretty straightforward provided the zone is not already present in the target view. Deleting and creating zones is also a non-issue.

The challenging question is what happens when a view is deleted from NetBox and that view is not the last one. There is a uniqueness constraint on zones that includes the view: There can, for example, be a zone zone.example.com both in view external and internal, while deleting the two views will result in two zones with the same name in the remaining default view.

I think the best way of avoiding this situation would be to restrict deletion of views to empty views, so the user must move zones out of the view or delete them before the view can be deleted. That restriction, however, has the exception of the last view that is defined, which can be deleted even if it contains zones and will then drop the zones back to the implicit default view (-> no view property defined).

Any thoughts?

[peteeckel]

Just a quick sign of life: This has not been forgotten.

Currently there is a major revamp of the Netbox plugin interface in the works, and that will make it much easier, more stable and more comfortable to develop plugin code. After Netbox 3.2 will be released I'll probably very quickly start with implementing views (I need them for my own environment, but not for my current customer, so it slid a bit down the priority list).

[peteeckel]

Another quick sign of life: After NetBox 3.2 and subsequently NetBox 0.10 has been released, I now started implementing the "Views" feature this weekend.

Nothing presentable yet, just the basic Django/NetBox stuff (Models, Views, Forms, Tables, API, Tests etc.) to use as a vehicle for the real business logic. Much easier now that the NetBox plugin API is in place.

[peteeckel]

If anyone would care to test PR #164 I would really welcome it, and if I can be of assistance I'd gladly help with any problems.

I'd be particularly interested in creative ways to break the feature - I slowly run out of ideas, but I suspect that at least a few interesting edge cases are lurking somewhere :-)

[peteeckel]

I did the first deployment of the "Views" feature with real data today. Works for me, I'm interested about your experience as well, though, as this is a major addition affecting almost all other features. PR is ready for review now.