Using NetBox and Netra Together

The problem

Most infrastructure teams eventually adopt a documentation tool. NetBox is one of the best — it models your racks, cables, IP space, and DNS records in a single source of truth. But documentation is only half the story.

Knowing that app.example.com should resolve to 10.20.30.40 doesn't help if anyone on the team can log into Route 53 and change it without telling anyone. Documentation describes the intended state. It doesn't enforce it.

This is the gap teams hit once their NetBox deployment matures: everything is documented beautifully, but the operational layer — actually making DNS changes safely, with approvals and audit trails — is still a manual, ad-hoc process. Someone SSHes into a server. Someone else clicks through the AWS console. A third person runs a script they wrote last year. The documentation goes stale within days.

How they complement each other

NetBox and Netra solve different problems, and understanding the boundary makes both tools more effective.

NetBox: the source of truth

NetBox is where you document what your DNS should look like. It holds your IP address plans, your intended A records, CNAMEs, MX entries, and the relationships between services and infrastructure. It answers the question: "What is the intended state of our DNS?"

NetBox excels at modeling. It understands that a particular VM runs on a specific host in a specific rack, and that VM has three network interfaces, each with IP assignments, each potentially needing forward and reverse DNS entries. That context is invaluable for planning.

Netra: the operations layer

Netra is where DNS changes actually get executed. It handles the workflow: submit a change request, get it reviewed and approved, apply it to the live DNS provider (AWS, Azure, Cloudflare, Windows DNS — wherever the zone lives), and then continuously monitor for drift.

Netra answers a different question: "How do changes get made, who approved them, and did they actually land?"

The separation

This separation means:

• NetBox doesn't need DNS provider credentials. It's a documentation system, not an execution engine. It shouldn't have write access to your production DNS.
• Netra doesn't need to understand your rack layout. It doesn't care whether the IP it's creating an A record for belongs to a VM in rack 12 or a container in Kubernetes. Its job is to make the change safely.
• Each tool stays focused. NetBox does modeling and documentation. Netra does change management and drift detection. Neither tries to be both.

A typical workflow

Here's how teams commonly run both tools together, step by step:

1. Engineer documents the intended DNS state in NetBox.

   A new service is going live. The engineer creates the IP assignment in NetBox, adds the intended DNS records (an A record for api.example.com pointing to 10.50.0.12), and notes which zone it belongs to. NetBox now reflects the desired state.

2. Change request is submitted in Netra.

   The engineer (or an automated integration) submits a DNS change request in Netra: "Create A record api.example.com → 10.50.0.12 in zone example.com on Route 53." The request includes context — a ticket reference, a link to the NetBox entry, a reason for the change.

3. Approver reviews and approves.

   A second team member gets a Slack notification (or email, or Teams message) with the change details. They review, confirm it matches the documented intent in NetBox, and approve with a single click.

4. Netra applies the change to the live DNS provider.

   Once approved, Netra connects to Route 53 (or Azure DNS, or Cloudflare, or your Windows DNS servers via WinRM) and creates the record. The full operation is logged — who requested, who approved, when it was applied, and the exact API call made.

5. Drift detection confirms the change took effect.

   Netra's continuous drift detection kicks in and verifies that api.example.com now resolves to 10.50.0.12 from the provider's perspective. If anything is off — a failed propagation, a conflicting record, a subsequent out-of-band change — the team gets alerted immediately.

Why this matters

Running both tools together gives you something neither can deliver alone:

Complete audit trail from intent to execution

The chain is traceable: documentation in NetBox shows why a record should exist. The change request in Netra shows who asked for it, who approved it, and exactly when it was applied. If an incident occurs at 3am and the on-call engineer needs to understand why api.example.com changed last Tuesday, both pieces of the story are there.

Separation of concerns

NetBox holds planning and context. Netra holds provider credentials and execution logic. This means:

• Your documentation platform doesn't need secrets (Route 53 API keys, Azure service principal credentials, WinRM passwords). Fewer secrets in fewer places = smaller attack surface.
• Your operations platform doesn't need to understand your physical infrastructure model. It stays lean and focused on the DNS workflow.
• Team members who need read access to documentation don't automatically get write access to production DNS.

Each tool does what it's best at

NetBox is exceptional at modeling complex infrastructure relationships. Netra is purpose-built for DNS change workflows. Trying to force one tool to do both jobs leads to compromises — either your documentation tool has a bolted-on workflow engine that's not great, or your operations tool tries to be a full DCIM/IPAM platform it was never designed to be.

The healthiest setups we see are teams who pick the best tool for each job and run them side by side with clear boundaries.

Integration approaches

Teams connect the two tools at various levels of automation, depending on their maturity:

Manual (most common starting point)

Engineers update NetBox, then manually submit the corresponding change request in Netra. The Netra request includes a link back to the NetBox record for reviewer context. Simple, no integration code needed, works day one.

API-driven

Teams with more automation maturity use NetBox webhooks to trigger Netra API calls. When a DNS record is created or modified in NetBox, a webhook fires, and a small integration script submits the corresponding change request to Netra via its REST API. The change still requires human approval before execution — the automation just removes the manual step of re-entering data.

Reconciliation reporting

Some teams run periodic reconciliation: compare what NetBox says should exist against what Netra sees as the current live state. Discrepancies surface records that were documented but never applied (or applied but never documented). This helps keep both systems in sync over time.

Common questions

Does Netra replace NetBox?

No. They do different things. NetBox is infrastructure documentation — it models your entire data center, network, and IP space. Netra is DNS operations — it manages the change lifecycle for DNS records specifically. Teams that use NetBox generally keep using it; Netra slots in alongside it.

Do I need NetBox to use Netra?

No. Plenty of teams run Netra without any IPAM or documentation tool. Netra works standalone as a DNS change management platform. NetBox is complementary, not a prerequisite.

What about NetBox's DNS plugin?

NetBox has community plugins for documenting DNS records. These are great for recording intended state within NetBox. But they don't provide change approval workflows, they don't actually push records to live providers, and they don't detect drift. That operational layer is what Netra adds.