3 DNS Configuration and Troubleshooting

DNS roles and answers

DNS (Domain Name System) maps names to data, most commonly host names to IP addresses. A resolver asks questions on behalf of a client, while an authoritative name server provides answers from the zone data it manages. Resolvers may cache answers, so a change can take time to appear everywhere.

DNS records and zone files

A zone is an administratively managed part of the name space. Its resource records (RRs) store the zone’s data. Common record types include:

• A and AAAA map a name to an IPv4 or IPv6 address.

• CNAME makes a name an alias of another canonical name.

• MX identifies mail servers for a domain and includes a preference value.

• NS identifies name servers for a zone or delegated subzone.

• SOA marks the zone’s start and includes its primary server, contact, serial number, and timing values.

• PTR maps an address to a name in a reverse-lookup zone.

A simplified BIND zone file for example.com illustrates record syntax and the SOA timing fields:

The trailing dot marks a fully qualified name. Without it, a name in a zone file may be interpreted relative to $ORIGIN. When changing a zone, update its SOA serial and reload or publish it using the DNS platform’s procedure.

The TTL controls how long resolvers may cache a record. Lowering it before a planned change can reduce how long old answers persist. A CNAME is an alias, not an address record: do not place other record types at the same name as a CNAME. In particular, use A or AAAA records rather than a CNAME for a zone apex such as example.com. MX and NS records should point to host names with address records, not aliases.

Client name resolution

A client needs the address of a usable DNS resolver. It may receive that address automatically through DHCP or have it configured manually. Check that the client uses the intended DNS server and, when short names are used, the correct DNS suffix.

A suffix search list can turn a short name such as web into a query for web.example.com. Test the fully qualified name separately to distinguish a suffix issue from a missing record. On Windows, ipconfig /all shows DNS server addresses and the connection-specific suffix.

Testing DNS responses

Test from the client toward the server, then query the relevant DNS data directly. These dig examples test specific record types, server behavior, and delegation:

The first command asks a specific resolver for an A record. The second queries a specific server without recursion; an authoritative answer should have the AA flag. The trace follows the delegation path from the DNS root toward the requested name. The NS query requests the name-server records for dept.example.com.

On Windows, nslookup name server-address can query a specified server. It is useful for testing DNS responses, but does not necessarily follow the same local resolution path as ordinary applications.

Interpreting lookup failures

Use the response and the point of failure to narrow the cause:

• Timeout or no response: Check the client’s configured resolver, routing and firewall rules, and whether the DNS service is reachable. DNS commonly uses UDP port 53 and can also use TCP.

• NXDOMAIN: The queried name does not exist according to the responding server. Check spelling, the zone, and whether the response came from the expected authority. A cached negative answer may remain until its negative-cache TTL expires.

• NOERROR but no requested record: The name may exist without the requested type. Query A, AAAA, CNAME, MX, or another relevant type.

• SERVFAIL: The server could not complete the lookup. Check the server’s logs and upstream resolution path, and consider whether a delegation or DNSSEC validation problem is involved.

• Unexpected or stale answer: Query the authoritative server directly and compare its answer with the recursive resolver’s. If the authoritative answer is correct, consider cached data and its TTL before changing records again.

Delegation and glue

A delegation must be configured in the parent zone as well as served by the child zone. For example, to delegate dept.example.com, the parent publishes NS records naming the child’s authoritative servers, and the child zone must contain its own SOA and NS records.

If a name server’s hostname is inside the delegated child zone, the parent generally also needs glue address data so resolvers can find that server without first querying the child. A lame delegation is a parent delegation that points to a server that is not authoritative for the child.

To diagnose a delegation, compare the parent’s NS referral with the child server’s direct response. Confirm the NS names, glue when needed, that the child zone is loaded, and that the server is reachable over the network.

Practical troubleshooting sequence

Use these checks to connect the configuration and troubleshooting steps:

• Query www.example.com for A and AAAA records and check whether each name has the record type you expect.

• Query the zone’s SOA directly from each listed name server. Check whether the responses are authoritative and whether the serial numbers match.

• Run dig +trace for a delegated subdomain. Identify the parent’s referral and verify that each child name server answers authoritatively.

• If a client fails to resolve a short name but resolves its fully qualified name, inspect its DNS suffix settings before changing the zone.

A useful troubleshooting sequence is to check the client’s resolver settings, compare recursive results with direct authoritative answers, verify record type and zone-file syntax, allow for caching, and check both sides of any delegation, including required glue and the child zone’s authoritative service.

• resource record