Can Netra handle 10 zones? What about 10,000?

Yes to both. The Professional license supports up to 10 zones and 2 DNS providers — ideal for teams managing a focused set of production domains. The Enterprise license removes all limits: unlimited zones, unlimited providers, unlimited users.

There's no architectural ceiling. Netra uses SQLite (default) or PostgreSQL for storage, and the zone sync and drift detection systems are designed to handle large zone counts with configurable intervals and per-domain backoff on failures. Teams managing hundreds of zones run Enterprise without issues.

Does Netra support Active Directory DNS?

Yes. Windows DNS — including AD-integrated zones — was the original Netra backend and remains a first-class provider. Netra connects to your Windows DNS servers via WinRM and executes PowerShell commands (Add-DnsServerResourceRecord, Remove-DnsServerResourceRecord) to manage records.

Supported configurations

  • Windows Server 2016 through 2025
  • AD-integrated and standalone zones
  • Multi-DC environments with failover
  • Zone transfers
  • WinRM over HTTP or HTTPS (with self-signed cert support)

You point Netra at your Windows DNS server (or a WinRM proxy), provide service account credentials, and it handles the rest. Credentials are encrypted at rest with AES-256-GCM.

Can I import existing zones?

Yes. There are three ways to bring existing zones into Netra:

  1. Automatic import via WinRM — For Windows DNS servers, Netra pulls all records from a zone using Get-DnsServerResourceRecord. One click in the UI or one API call.
  2. BIND zone file import — Paste or upload a standard BIND zone file and Netra parses it into records. Useful for migrations from other DNS platforms.
  3. Cloud provider import — For AWS Route 53, GCP Cloud DNS, Azure DNS, and Cloudflare, Netra queries the provider API and imports the full zone contents.

After initial import, zone sync keeps records current automatically. It runs on a configurable schedule (default: after each health check) and uses exponential backoff if a sync fails. This means your zone browser always reflects current reality — which is essential for drift detection and conflict checking.

How does zone discovery work?

Discovery depends on the provider type:

  • Windows DNS: Netra runs Get-DnsServerZone via WinRM to list all zones on a server. You see every zone the server hosts and pick which ones to manage. This discovers both AD-integrated and file-backed zones.
  • Cloud providers: Netra queries the provider API (Route 53 ListHostedZones, GCP managedZones.list, Azure DNS zones list, Cloudflare zones list) and shows you what's available. You select which zones to add.

Discovery is read-only. It never creates, modifies, or deletes anything — it just shows you what exists so you can choose what Netra should manage.

Is anything modified automatically?

No. This is a deliberate design decision. Netra never writes to your DNS providers unless a human (or an explicitly configured automation) approves the change.

What happens automatically (all read-only)

  • Health checks — probes DNS servers for reachability (configurable interval, default 5 minutes)
  • Zone sync — re-imports the current zone state to keep records up to date (never writes)
  • Drift detection — compares live DNS against the last approved state and alerts if there's divergence
  • Scheduled applies — if a change was approved and scheduled for a specific time, it applies at that time — but it was already approved by a human

The only path to a DNS write operation is: submit request → get approval → apply. No exceptions (unless explicitly configured for CI/CD bypass, which is audit-logged).

Can I integrate Netra with Terraform?

Yes. Netra has native Terraform support through its REST API. When Terraform submits a DNS change, the request is created, applied, and fully audited with the source tagged as terraform.

Two modes

  • Auto-apply — Terraform changes are treated as pre-approved (common for IaC workflows where the Terraform plan/apply is the approval process)
  • Approval-required — Terraform submits the request but a human must still approve before it applies (for environments where DNS changes need separate sign-off)

All Terraform-originated changes appear in the audit log with full attribution, including the pipeline run that triggered them.

Does Netra support role-based access control?

Yes. Netra has three roles:

  • Admin — Full access. Can manage servers, domains, settings, users, and approve/reject requests.
  • Approver — Can submit DNS change requests and approve/reject other users' requests. Cannot modify system settings.
  • User — Can submit DNS change requests only. Cannot approve their own requests (enforces separation of duties).

Role assignment

  • LDAP/Active Directory — group-based mapping (e.g., "DNS-Admins" AD group → admin role)
  • SSO (Okta, Microsoft Entra ID, generic OIDC) — group claims in the JWT token map to roles
  • Local accounts — role assigned manually at account creation

The two-person rule is enforced at the system level: a user can never approve their own request, regardless of their role.

Can I automate DNS changes via API?

Yes. Netra exposes a full REST API for every operation the UI performs:

  • Submit change requests programmatically
  • Approve or reject requests via API
  • Query zones, records, and drift alerts
  • Trigger zone imports
  • Manage API tokens and sessions

Authentication uses named API tokens (prefixed with dnsf_) that are SHA-256 hashed in storage. Each token has a name, an assigned role, an optional expiry date, and can be revoked at any time. All API actions are audit-logged the same as UI actions.

CI/CD integrations (GitHub Actions, GitLab CI/CD, Bitbucket Pipelines, Azure DevOps) use native webhook handlers that accept pipeline payloads directly — no scripting required.

How are credentials stored?

All sensitive credentials are encrypted at rest using AES-256-GCM. This includes:

  • WinRM passwords for Windows DNS servers
  • Cloud provider API keys and secrets (AWS, GCP, Azure, Cloudflare)
  • SMTP credentials
  • SSO client secrets
  • Webhook signing secrets
  • SIEM forwarding tokens

The encryption key is derived from your APP_SECRET environment variable using PBKDF2 with 100,000 iterations and a fixed application-specific salt. The raw secret is never used directly as a key.

Credentials are never logged, never returned by the API (the UI shows a redacted placeholder), and cannot be extracted from the database without the APP_SECRET. If APP_SECRET is changed, credentials must be re-entered.

What DNS record types are supported?

Netra supports all standard record types: A, AAAA, CNAME, MX, TXT, SRV, PTR, NS, and SOA. The exact types available depend on what the underlying DNS provider supports — for example, Route 53 supports alias records, which Netra handles natively.

What happens if my DNS provider is unreachable?

If a DNS provider is unreachable during an apply, the request status is set to failed and the team is notified through configured channels (Slack, Teams, email). The request stays in the queue and can be retried once the provider is back. No partial state is created — the apply is atomic per request.

Health checks detect provider outages proactively and send state-change notifications so you know before someone tries to make a change.