DNS configuration explained: Server settings, client setup, and validation

Listening interfaces and ports

DNS normally uses port 53 over both UDP and TCP. UDP is commonly used for standard DNS queries, while TCP is required for zone transfers and is also used when DNS messages cannot be carried in a single UDP response. Modern DNS implementations must support both transports.

Many DNS servers can listen on multiple network interfaces. Rather than accepting DNS queries indiscriminately on every interface, configure the server to listen only where DNS service is required.

• Internal recursive resolvers: Restrict DNS access to interfaces and networks used by authorized internal clients. Do not expose an internal recursive resolver directly to the public internet.
• Authoritative nameservers: Public authoritative servers need to accept queries from the networks that require access to the public zone. They should not unnecessarily provide recursive service to those clients.
• Loopback: Local applications and administrative tools may use the loopback address for queries to the DNS service itself.

In BIND, listening interfaces can be configured with listen-on and listen-on-v6 in the options block of named.conf. In Windows Server DNS, listening interfaces can be configured under DNS Server Properties → Interfaces.

Restricting DNS listening interfaces reduces the server's exposed attack surface and helps prevent an internal recursive resolver from being unintentionally operated as an open resolver.

Recursion policy

DNS recursion determines whether a DNS server resolves names on behalf of a client by querying other DNS servers, or limits responses to information it is authoritative for or already has available.

A public authoritative nameserver generally should not provide unrestricted recursive resolution. If recursion is enabled for an authoritative server, access should be limited to explicitly authorized clients.

Internal recursive resolvers, by contrast, need recursion to resolve names outside the zones for which they are authoritative. Recursive access should be restricted to trusted client networks rather than being available to arbitrary sources.

In BIND, recursion and recursive access can be controlled using directives such as recursion and allow-recursion. In Windows environments, recursion settings and network access controls can be configured through DNS Server settings and firewall rules.

For more on the security implications of unrestricted recursion, see the DNS security guide.

EDNS0 and UDP payload size

EDNS0 (Extension Mechanisms for DNS), defined in RFC 6891, extends DNS so that clients and servers can advertise support for UDP payloads larger than the original 512-byte DNS limit. This is particularly important for larger responses containing DNSSEC data, multiple address records, or large TXT records.

Without EDNS0, a DNS response that exceeds the traditional UDP limit can be truncated, requiring the client to retry over TCP. Modern DNS implementations therefore need to support both EDNS0 and TCP to handle large responses reliably.

The appropriate EDNS0 UDP payload size depends on the DNS implementation and network path. A value such as 1232 bytes is widely used as a conservative operational setting, but it should not be presented as a universal RFC 6891 requirement. RFC 6891 instead emphasizes choosing a value the requester can actually receive and avoiding fragmentation where possible.

EDNS0 should generally remain enabled in modern DNS environments. If large DNS responses are being truncated or DNSSEC queries are failing, inspect EDNS0 support, advertised payload sizes, and whether firewalls or other network devices are interfering with DNS traffic.

In BIND, an EDNS UDP size can be configured with:

edns-udp-size 1232;

You can inspect EDNS information with:

dig +edns example.com

Look for the OPT PSEUDOSECTION in the response.

DHCP option 006: DNS server assignment

DHCP option 006 provides clients with the IP addresses of DNS servers available to them. When a device receives a DHCP lease, the DHCP server can include one or more DNS server addresses in the lease information.

For enterprise networks, provide at least two reachable recursive resolvers where redundancy is required. Clients can then use the configured resolver addresses according to their operating system and resolver implementation.

Both resolvers should provide consistent access to the internal DNS namespace and have compatible forwarding or upstream resolution policies. Otherwise, a client switching between resolvers can receive different results.

Review DHCP option 006 whenever DNS infrastructure changes. A DHCP scope that continues distributing the IP address of a retired or incorrectly configured resolver can cause newly provisioned devices to inherit broken DNS settings.

DNS suffix and search domain

A DNS suffix or search domain allows clients to resolve short hostnames without requiring users or applications to specify the complete FQDN. For example, a client configured with corp.example.com as a search domain can attempt to resolve:

intranet

as:

intranet.corp.example.com

DHCP option 015 can provide a client's domain name, while DHCP option 119 can provide a DNS search list containing multiple domains.

When configuring DNS suffixes, consider the following:

• Single suffix: A single internal suffix is appropriate for many enterprise environments.
• Multiple search domains: A search list can support environments with multiple internal namespaces, but long lists can increase resolution time because clients may try several suffixes before finding a match.
• Avoid overly broad suffixes: Broad search domains can cause unnecessary queries and, in some circumstances, unintended resolution against public namespaces. Search-domain behavior varies by operating system and resolver implementation, so validate the actual query sequence on representative client devices rather than assuming every platform processes search lists identically.

Why use split-horizon DNS?

Split-horizon DNS allows internal users to access services through private network paths while external users continue to use public endpoints.

Without split-horizon DNS, internal clients may resolve a service to its public address and send traffic through an external firewall or NAT path before returning to the internal network. Depending on the network architecture, this can create unnecessary routing, firewall complexity, or NAT loopback requirements.

With split-horizon DNS, internal clients can receive private addresses and connect directly to internal resources.

How to configure split-horizon DNS

A common split-horizon design maintains separate internal and external DNS data:

• Internal DNS zone: Contains records intended for internal clients, such as private IP addresses and internal service endpoints.
• External DNS zone: Contains publicly reachable records and is hosted on public authoritative DNS infrastructure.

Internal recursive resolvers are configured to answer queries for the internal namespace using the internal DNS data. External clients receive answers from the public authoritative DNS infrastructure.

The main operational challenge is keeping the two DNS views intentionally aligned. A change made to the public zone does not automatically update the internal zone, and vice versa. DNS changes therefore need to identify whether both views require modification.

In BIND, split-horizon DNS can be implemented with view configurations that provide different responses based on the source of the query. Other DNS platforms implement the same concept using mechanisms such as views, policies, or separate zones.

1. Define the DNS server role

Determine whether the server will act as an authoritative DNS server, a recursive resolver, a forwarding resolver, or more than one role where the architecture permits it. Avoid combining roles unnecessarily, particularly when a public authoritative server would also become an unrestricted recursive resolver.

2. Configure DNS zones

Create or configure the authoritative zones the server needs to host. Verify the zone's NS and SOA records, zone file structure, and primary/secondary relationships.

3. Configure listening interfaces

Bind the DNS service to the interfaces that should accept DNS traffic. Confirm that UDP and TCP port 53 are reachable from authorized clients and that unnecessary interfaces are not exposed.

4. Configure recursion and forwarding

Enable recursion only where the server is intended to provide recursive service. Restrict recursive access to authorized client networks.

For external resolution, configure appropriate forwarders or root-hint resolution according to the network design.

5. Configure DNS client settings

Distribute resolver addresses through DHCP option 006 or the appropriate endpoint-management mechanism. Configure DNS suffixes and search lists where short-name resolution is required.

6. Validate the configuration

Test resolution locally, from representative client networks, and against secondary servers. Verify both forward and reverse lookups and confirm that zone data is synchronized where secondary DNS is used.

1. Verify the DNS service is listening

Confirm that the DNS service is running and listening on the expected interfaces and port.

# Linux - check for DNS listeners on port 53
ss -ulnp | grep :53
# Windows - verify DNS service status
Get-Service DNS

Also verify TCP port 53 where the DNS server is expected to support TCP DNS traffic.

2. Test forward resolution from the DNS server

Query the local resolver for both internal and external names:

# Query the local server for an internal hostname
nslookup intranet.corp.local 127.0.0.1
# Query the local server for an external hostname
dig example.com @127.0.0.1

A successful internal query helps confirm that the relevant zone is loaded and answering correctly. A successful external query can confirm that recursion or forwarding is functioning, provided the server is configured to provide that service.

3. Test DNS from a client

Query the DNS server from a client on the network using the server's network address rather than loopback:

nslookup intranet.corp.local 10.1.1.10

This tests network reachability as well as the server's listening-interface and access-control configuration.

4. Verify zone synchronization

For primary/secondary DNS, compare SOA serial numbers:

# Check SOA serial on primary
dig SOA corp.local @primary-ns-ip
# Check SOA serial on secondary
dig SOA corp.local @secondary-ns-ip

Matching serial numbers provide evidence that the secondary has the current version of the zone. If they differ, investigate zone-transfer status, SOA serial updates, connectivity, and transfer permissions.

5. Validate forward and reverse DNS

Test both directions for important hosts:

# Forward lookup
nslookup server01.corp.local
# Reverse lookup
nslookup 10.1.2.50

The reverse lookup should return the expected hostname for environments where forward and reverse DNS are intended to correspond. A mismatch can indicate a stale or incorrectly configured PTR record.