DNS Server Configuration

---

DNS Server Types

• DNS server is usually configured to listen for queries on UDP port 53
  • some are also configured to allow connections over TCP port 53
    • allows larger record transfers (over 512 bytes)
      • may be required for IPv6 or for DNSSEC
• name server can maintain primary and/or secondary zones:
  • primary zone
    • the zone records held on the server are editable
    • zone can be hosted by multiple primary servers for redundancy
    • zone records are editable on all primaries
      • changes must be carefully replicated and synchronized
      • very important to update the serial number for each change
  • secondary zones
    • the server holds a read-only copy of the zone
    • maintained through a process of replication known as a zone transfer from a primary name server
    • typically provided on two or more separate servers to provide fault tolerance and load balancing
    • serial number is critical process of the zone transfer process
• a name server that holds complete records for a domain is authoritative
  • means that a record in the zone identifies the server as a name server for that namespace
  • both primary and secondary name servers are authoritative
• servers that don’t maintain a zone are cache-only servers
  • a non-authoritative answer from a server is one that derives from a cached record
    • rather than directly from the zone records

DNS Caching

• each resource record can be configured with a default time to live (TTL) value
  • measured in seconds
  • instructs resolvers how long a query result can be kept in cache
  • setting low TTL allows records to be updated more quickly but increases:
    • load on the server
    • latency on client connections to services
  • common TTL values:
    • 300 (5 min.)
    • 3,600 (1 hour)
    • 86,400 (1 day)
    • 604,800 (1 week)
• DNS caching is performed by both servers and client computers
  • each application on a client computer might be configured to manage its own DNS cache
    • e.g., separate web browser applications typically maintain their own caches rather than relying on a shared OS cache
  • if a resource record changes, server and client caching means that the updated record can be relatively slow to propagate around the Internet
    • changes need to be managed carefully to avoid causing outages
    • planning for a record change involves:
      • reducing the TTL in the period before the change
      • waiting for the change to propagate before updating
      • then reverting to the original TTL value when update has safely propagated