Native Split-Horizon DNS Authoring UI & API with Policy Variables and IP/Subnet Group Management

[freedbygrace]

Summary

Introduce a first-class, built-in authoring experience for split-horizon DNS within Technitium DNS Server. This would include a rich Web UI and corresponding API endpoints to define, manage, and deploy DNS policies without relying on manual JSON editing in plugins.

The existing plugin-based approach is powerful and flexible, but authoring and maintaining configurations at scale would benefit significantly from a structured, user-friendly interface and API-driven management.

---

Problem Statement

Currently, split-horizon DNS configurations require:

• Manual JSON authoring within plugin configurations
• Limited visibility into policy relationships and evaluation order
• No native abstraction for reusable components (e.g., IP groups, variables)
• Higher operational overhead for updates, validation, and troubleshooting

While functional and performant, this approach becomes difficult to manage in environments with:

• Multiple subnets / VLANs
• Remote access networks (VPN, Tailscale, etc.)
• Hybrid/internal/external service exposure
• Frequent policy updates or automation requirements

---

Proposed Solution

1. Native Split-Horizon Policy Engine (UI + API)

Introduce a built-in policy system accessible via:

• Web UI (authoring, visualization, testing)
• REST API (automation, integration)

Each policy should support:

• Source matching (IP, subnet, group)
• Query conditions (domain, record type, regex)
• Response behavior (override, forward, block, etc.)
• Priority / evaluation order
• Enable/disable toggle

---

2. IP/Subnet Group Management

Provide reusable objects for defining client sources:

• Named IP groups (e.g., CorporateLAN, VPNClients, IoTDevices)
• Support for:
  • CIDR ranges
  • Individual IPs
  • Nested groups (optional but powerful)
• UI + API management
• Validation and conflict detection

---

3. Variable & Template Support

Allow dynamic reuse of values across policies:

• Define variables such as:
  • ${InternalDomain}
  • ${ExternalIP}
  • ${ServiceEndpoint}
• Use variables in:
  • Domain matching
  • Response records
• Optional environment-style scoping (global vs zone-specific)

---

4. Policy Authoring UI

A dedicated UI section for:

• Creating/editing policies via forms (no JSON required)
• Drag-and-drop or ordered priority management
• Visual indication of:
  • Matching conditions
  • Effective responses
• Inline validation and error handling

---

5. Policy Simulation / Testing Tool

Add a built-in testing utility:

• Input:
  • Source IP
  • Query name
  • Record type
• Output:
  • Matched policy
  • Evaluation path
  • Final DNS response

This would significantly improve troubleshooting and confidence in policy changes.

---

6. API Enhancements

Expose full functionality via REST API:

• CRUD operations for:
  • Policies
  • IP/Subnet groups
  • Variables
• Bulk import/export (JSON/YAML)
• Policy validation endpoint
• Simulation endpoint

---

7. Backward Compatibility

• Existing plugin-based JSON configurations should continue to function
• Optional migration tool to convert JSON configs into native policies
• No breaking changes to current deployments

---

Benefits

Operational Efficiency

• Eliminates manual JSON editing for most use cases
• Simplifies onboarding and day-to-day management

Scalability

• Enables clean management of complex environments with many networks and services

Automation

• API-first design allows integration with:
  • Infrastructure-as-Code workflows
  • Configuration management tools
  • CI/CD pipelines

Reliability

• Built-in validation reduces configuration errors
• Simulation tooling improves troubleshooting

User Experience

• Makes an already powerful feature accessible to a broader audience without sacrificing flexibility

---

Example Use Case

A single domain (app.company.local) could resolve differently based on source:

Source Group | Response -- | -- CorporateLAN | 10.0.0.50 VPNClients | 172.16.160.50 Public | Public IP or blocked

All managed via UI/API instead of editing plugin JSON.

---

Additional Considerations

• Optional export/import of policies for backup and migration
• Role-based access control (RBAC) for policy management
• Audit logging for policy changes
• Performance considerations (ensure policy evaluation remains efficient)

---

Conclusion

Technitium DNS Server already provides powerful split-horizon capabilities through plugins. Elevating this into a native, fully managed feature with UI and API support would significantly enhance usability, scalability, and adoption—especially in modern hybrid and segmented network environments.

[ShreyasZare]

Thanks for the request. All DNS apps have been planned to have GUI support but since this task is quite time consuming to implement (i.e. need to implement for 27 separate apps), and that it is a "good to have" feature, it is not being prioritized and other core features and DHCP related features are planned to be done before it.

Named IP groups

This is already supported and you can create a custom named network in the app's main config and then use the name in the APP record json config.

This post seems to be written by AI and pasted verbatim. Most of the things described are too vague and not feasible to be implemented. It would have been much better if you had described the requirements you have in simple terms explaining your use-case.