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 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