Extract from netbox to zonefiles

[kollross]

I've read the use case, and I have a similar setup. However would it be possible to simply extract that information from netbox and generate regular bind zone text files?

[peteeckel]

Hi @kollross, the easiest way to directly produce zone files from NetBox DNS is to run a custom script like examples/custom-scripts/netbox_dns_exporters.py (you might want to add some more fine-grained adjustments, but the example can be used as boilerplate code).

That requires a bit of Python coding, but on the upside it's much faster than the Ansible method using the netbox collection.

[kollross]

yeah, there in lies the problem, this bit exceeds my skillset...lol.

[peteeckel]

Hi @kollross, did you give the example code a try? It creates valid zone files for BIND, so maybe it's already enough for you to start with - installing it should be quite straightforward.

If there's anything you are missing and it's sufficiently generic to include in the example code I'll enhance it for you.

[kollross]

@peteeckel I haven't got it working. It's barfs on the import for the extra.plugins portion, though I'm not sure why.

Traceback (most recent call last):
  File "./Netbox_DNS_Exporter.py", line 5, in <module>
    from netbox_dns.models import View, Zone, Record
  File "/opt/netbox-3.5.1/venv/lib/python3.9/site-packages/netbox_dns/__init__.py", line 1, in <module>
    from extras.plugins import PluginConfig
ModuleNotFoundError: No module named 'extras.plugins'

The extras should be in that path though

>>> for path in sys.path:
...      print(path)
...

/usr/lib/python39.zip
/usr/lib/python3.9
/usr/lib/python3.9/lib-dynload
/opt/netbox-3.5.1/venv/lib/python3.9/site-packages
>>>

ls /opt/netbox-3.5.1/venv/lib/python3.9/site-packages/extras
__init__.py  __pycache__  tests

[peteeckel]

Did you try to run the script from the command line? That won't work, it needs to run in NetBox' context.

Try the following:

1. Edit configuration.py and remove the comment sign before SCRIPTS_ROOT
2. Copy the file to the directory that is defined as SCRIPTS_ROOT (by default /opt/netbox/netbox/scripts), making sure the NetBox user has the correct permissions
3. See if it turns up in 'Customization/Scripts' in the GUI

If that works you should be able to figure out the rest yourself.

[peteeckel]

Argh ... turns out that doesn't seem to work anymore.

You can, however, select 'Add' from the 'Scripts' view and upload the file. That does work (I just tried).

[kollross]

@peteeckel SUCCESS!!!, that worked. For now all I need is BIND configs (which is what my current IPAM does now). The mechanism you described would be a nice future state though. Maybe someday.

Thanks again.

[kollross]

@peteeckel Out of curiosity, how did you load all your current zone information into Netbox. I have maybe 50 zones, but some of my zones have 14K records?

[peteeckel]

When I transferred my own and my customers' data to NetBox DNS, I actually used AXFR to dump the DNS zones to text files and then converted them to CSV with a little script. NetBox (and so, NetBox DNS as well) can import CSV data directly. Since NetBox 3.4, JSON and YAML will do as well, but CSV might be a bit more straightforward.

Afterthought: Zones with 14k records might be a challenge that could make it necessary to import them in chunks and/or defer the generation of PTR records until after the import. NetBox DNS by default creates PTR records for all A/AAAA records (which is an expensive operation), and with a bulk import of 14k records it will likely run into Django timeouts before the import finishes. That obviously also depends on how powerful the machine you're running NetBox on is.

[kollross]

That's what I figured the approach would be. I threw a dozen or so records into NetBox DNS, thought I don't see it creating any zones for the PTR records. Do I need to manually create those zones prior to have them autogenerated?

[peteeckel]

NetBox DNS does not create the reverse zones - that would not make any sense, because it's not generally the case that one controls both the forward and the reverse zones.

But if the reverse zone for an address exists in NetBox DNS and the 'Disable PTR' flag is not set for an address record NetBox DNS will create the PTR record.

The PTR records will also be generated when the reverse zone is added later. So in the general case (unless you are creating a large number of A/AAAA records) it doesn't matter in which order you create zones - it just takes more or less time.

[peteeckel]

Another reason why it's not really a good idea to generate the reverse zones automatically: It's not self-evident which zone to create for a given IP address.

When you add an A record for the address 10.1.2.3 the pointer could be in 10.in-addr.arpa, 1.10.in-addr.arpa or 2.1.10.in-addr.arpa - and that's not counting RFC2317 reverse zones. Yes, it would be possible to add some kind of ruleset to NetBox DNS that determines how the PTR zones should be created, but it's generally much more transparent to say 'if the zone is there create the PTR, otherwise don't bother'.

[kollross]

Yes I agree, I never understood (well I do technically) why the in-addr.arpa zones are not better defined.

"NetBox DNS does not create the reverse zones - that would not make any sense, because it's not generally the case that one controls both the forward and the reverse zones." I don't think I would agree with that assumption. Netbox seems to be making large inroads into R&E settings (large universities, labs, etc) and those organizations would all control their forward and reverse records.

[peteeckel]

Yes I agree, I never understood (well I do technically) why the in-addr.arpa zones are not better defined.

Well, they're ancient ... when the standard was defined, CIDR wasn't in sight and people thought that the IPv4 address space would be sufficient for a very long time. So using a decimal representation for addresses and octet boundaries for delegation didn't seem to be bad ideas.

I don't think I would agree with that assumption. [...] and those organizations would all control their forward and reverse records.

It's often the case, and for larger organisations (and in most cases for global IPv6 address space) that's true. But look at global IPv4 address space - as a smaller company you're lucky to get a /28 subnet from your provider, so RFC2317 (which is a planned feature for NetBox DNS) is the closest you get to controlling your own reverse resolution zones in that case.

On the other hand it might be an idea to provide auto reverse zone-generation as an option in NetBox DNS. As long as RFC2317 is not used, delegation of /24 subnets can be assumed (/16 and /8 as an option), and for IPv6 probably /64 with options for other prefix lengths with a granularity of one nibble (fortunately there isn't such a think as RFC2317 for IPv6 :-)).

Or maybe no configurable prefix lengths at all, falling back to the 'Create the zones yourself when you want something different from /24 or /64, respectively' approach. Turns out that logic is flawed as well - what when a user controls 10.in-addr.arpa but still wants missing reverse zones below that to be created? One of my customers has a different setup: They control most of there reverse zones, but not all of them (which in my experience is the general case), as they are only running the DNS for a part of their environment and the rest is controlled by the Windows team and their AD, but they have hosts in the AD address space.

As I said, there is no simple general assumpion that can safely be made.