DNS
Overview
The platform includes a powerful authoritative DNS service built on BIND, one of the most widely-used DNS server implementations. This service allows you to host authoritative DNS zones for your domains directly within your tenant, providing complete control over domain name resolution.
Unlike simple DNS forwarding, authoritative DNS makes your network the definitive source for DNS records in the domains you control. This capability is essential for organizations that need to manage their own domain name resolution, implement split-horizon DNS configurations, or provide DNS services as part of their infrastructure offerings.
Service Architecture
BIND Integration
The platform implements authoritative DNS through BIND, providing enterprise-grade DNS capabilities including:
- Full Zone Management: Complete control over DNS records and zone configuration
- DNS Views: Advanced access control allowing different responses based on client location
- Zone Transfers: Built-in support for primary/secondary DNS configurations
- Performance Optimization: Integrated caching and query optimization
- Security Features: Access controls and query filtering capabilities
Network-Level DNS Selection
DNS services are configured at the network level, giving you granular control over which networks provide DNS services. When editing a network, you can select from several DNS options:
- Bind: Enables full authoritative DNS capabilities on the network
- Simple: Provides DNS forwarding without authoritative capabilities
- Other Network: Forwards DNS requests to another network
- Disabled: No DNS services provided by this network
Default Behavior and Recursion
When you enable BIND on a network, it becomes an authoritative DNS server by default with no recursion enabled. This means:
- The entire system (core network, internal networks, VMs) will use the network's default route for recursive DNS queries
- The authoritative DNS server will only respond to queries for domains it hosts
- For internet DNS resolution, queries are forwarded to upstream DNS servers via the default gateway
This design ensures clean separation between authoritative and recursive DNS functions while maintaining system-wide DNS connectivity.
DNS Views
Understanding DNS Views
DNS views are a powerful BIND feature that allows you to provide different DNS responses based on who is making the query. In your tenant, views act as intelligent traffic processors that determine how to handle DNS requests based on:
- Client IP Addresses: Match specific networks or IP ranges
- Query Type: Different handling for different DNS record types
- Access Policies: Enable or disable recursion per view
Common View Configurations
- LAN View (Private/Internal)
- Matches RFC1918 internal network IP ranges (10.0.0.0/8, 192.168.0.0/16, etc.)
- Recursion enabled for internal clients
- Provides both authoritative answers and internet DNS resolution
- Used by VPN clients and internal systems
- WAN View (Public/External)
- Matches all other traffic (typically internet-facing)
- Recursion disabled for security
- Provides only authoritative answers for hosted domains
- Protects against DNS amplification attacks
View Processing Order
DNS views are processed in order, with the first matching view handling the request. This allows you to create specific rules for internal clients while having a catch-all rule for external traffic.
DNS Zones
Zone Basics
A DNS zone represents a domain or subdomain for which your tenant is authoritative. Each zone contains:
- Domain Name: The domain being served (e.g., company.com)
- Name Server Records: Identifies this server as authoritative for the domain
- Administrative Contact: Email address for zone administration
- Timing Parameters: TTL values, refresh intervals, retry periods
Name Server Configuration
When configuring zones, you'll specify name servers that are authoritative for the domain. You have two main approaches:
- External Name Servers
- Name servers outside your domain (recommended)
(Example: ns1.dnsprovider.com for domain company.com)
- Avoids circular dependency issues
- Simpler for public DNS delegation
- In-Domain Name Servers
- Name servers within the domain being served
(Example: ns1.company.com for domain company.com)
- Requires "glue records" at your domain registrar
- Provides complete control but increases complexity
Glue Records & Domain Delegation
When using in-domain name servers, you must configure glue records at your domain registrar. These A records tell the world the IP addresses of your name servers, breaking the circular dependency where someone needs to resolve ns1.company.com to find the authoritative server for company.com.
Domain Name Formatting
The platform follows standard DNS conventions for domain names:
- Fully Qualified Domain Names (FQDN): End with a period (e.g., mail.company.com)
- Relative Names: Automatically appended with the zone name
- Consistency: Use FQDNs throughout to avoid confusion
Record Management
Record Types
The platform supports all standard DNS record types:
- A Records: IPv4 address mappings
- AAAA Records: IPv6 address mappings
- CNAME Records: Canonical name aliases
- MX Records: Mail server priorities
- TXT Records: Text data for verification and policies
- NS Records: Name server delegations
- SRV Records: Service location records
Record Ordering
Within zones, record order can affect resolution, particularly when using relative names or special characters. Best practices include:
- Use fully qualified domain names for clarity
- Place zone apex records (bare domain) first
- Maintain consistent formatting throughout the zone
Zone Transfers & Redundancy
Primary/Secondary Configuration
The platform supports standard DNS zone transfer mechanisms for redundancy.
- Primary Server Configuration
- Hosts the master copy of zone data
- Configured through the user interface
- Sends notifications when zones change
- Secondary Server Configuration
- Receives zone data via transfer
- Can be another region's instance or external DNS server
- Automatically updates when notified of changes
Transfer Security
Zone transfers occur over TCP port 53 and should be restricted to authorized secondary servers. The platform allows you to specify which IP addresses can request zone transfers, preventing unauthorized access to your DNS data.
Notification System
When records change on the primary server, the platform automatically sends notifications to configured secondary servers, ensuring rapid propagation of DNS updates across your infrastructure.
Network Requirements
Authoritative DNS requires specific network access.
- Port Requirements
- UDP Port 53 - Standard DNS queries from clients worldwide
- TCP Port 53 - Zone transfers and large DNS responses
- Firewall Configuration
- Allow UDP 53 - from anywhere, for general DNS queries
- Restrict TCP 53 - to authorized secondary DNS servers only
ℹ️ Consider rate limiting to prevent abuse
Authoritative DNS is typically configured on external networks to provide public accessibility. However, you can run authoritative DNS on internal networks for private domains or split-horizon configurations.
Security Considerations
Query Restriction
- By default, authoritative DNS within the platform:
- Provides authoritative answers to any client
- Disables recursion for external clients
- Allows recursion only for specified internal networks
Access Control
- DNS views provide granular access control:
- Internal clients get full DNS services (authoritative + recursive)
- External clients get authoritative answers only
- Prevents your DNS server from being used in amplification attack
Zone Transfer Security
- Limit zone transfers to:
- Known secondary DNS servers
- Specific IP addresses or networks
- Authenticated transfer mechanisms where available