AS

DNS in Linux for Absolute Beginners

Section 1: Overview and learning goals

  • Topic: DNS in Linux for absolute beginners, focusing on basic concepts, how to explore DNS configuration on Linux hosts, and practical tools for testing DNS resolution.
  • Scenario setup:
    • Two hosts, A and B, on the same network with IPs 192.168.1.10 and 192.168.1.11 respectively.
    • Initially, you can ping either host by its IP address.
    • Objective: Resolve host name to IP so you can ping B using the name db instead of the IP.
  • Initial solution using local host file:
    • Edit /etc/hosts on host A to map the IP of host B to the name you want to use (e.g., db).
    • Example line: 192.168.1.11 db.
    • After this, a ping to db succeeds because host A resolves the name via its local hosts file.
  • Important observation about /etc/hosts:
    • Host A trusts its local /etc/hosts as the source of truth for name resolution.
    • Host A does not verify host B’s actual system name; a command like hostname on B may return a different name (e.g., host-2).
    • You can create multiple names for the same IP (e.g., mapping to both db and www.google.com) to reach the same system.
  • Summary takeaway:
    • Local name resolution via /etc/hosts is simple and effective for small networks but becomes hard to manage at scale.

Section 2: The shift to centralized DNS

  • Problem with per-host hosts files:
    • As networks grow, keeping every /etc/hosts updated becomes infeasible.
  • Solution: Centralized DNS server
    • A DNS server maintains mappings from host names to IP addresses for the entire network.
    • Clients query the DNS server instead of relying solely on local hosts files.
  • DNS server in the example:
    • DNS server IP (central resolver): 192.168.1.100.
  • How clients learn to use DNS:
    • Each host’s DNS resolution configuration (/etc/resolv.conf) is updated to point to the DNS server.
    • Example line: nameserver 192.168.1.100.
    • Once configured on all hosts, unknown host names are resolved via the DNS server, not local hosts files.
  • Optional: You can still have entries in /etc/hosts for testing or local-only servers; this does not disable DNS usage.
  • Key takeaway:
    • Centralized DNS reduces the need to maintain multiple hosts files and makes IP changes easier to manage.

Section 3: How name resolution actually works and the resolution order

  • When both local /etc/hosts and DNS exist, the system resolves names using a defined order.
  • Resolution order is configured in /etc/nsswitch.conf via the hosts line.
    • Typical setting: hosts: files dns
    • Here, "files" refers to /etc/hosts and "dns" refers to the DNS server configured in /etc/resolv.conf.
  • Behavior when both places have an entry for the same host:
    • The system will use the entry found in the local /etc/hosts first, then consult the DNS server if not found locally.
    • This order can be changed by editing /etc/nsswitch.conf if needed.
  • What happens if the host is not found in either list:
    • Resolution fails.
    • To reach external sites not known to local DNS, you can configure a public DNS server as a forwarder (e.g., 8.8.8.8).
  • Practical example from the transcript:
    • If you try to reach something like www.facebook.com and it’s not in /etc/hosts and not resolvable via your DNS server, you’ll fail unless you have a forwarder or broader DNS configuration.
  • Forwarders concept:
    • You can configure your DNS server to forward unknown queries to public DNS servers (e.g., 8.8.8.8) to reach external domains.
    • This enables resolution of external domains from within your organization.

Section 4: Domain names, DNS hierarchy, and practical implications

  • What is a domain name?
    • A domain name is a human-readable address that translates to an IP address via DNS.
    • Example: www.google.com.
  • Domain name structure:
    • Root: the root of the DNS namespace is represented by a dot ".".
    • Top-Level Domain (TLD): e.g., .com, .net, .org, .edu.
    • Second-level/domain name: e.g., google in google.com.
    • Subdomains: e.g., in maps.google.com or drive.google.com; these further organize services under a domain.
  • How the resolution chain works on the public Internet (high-level):
    • A request for a domain like apps.google.com first hits your organization's internal DNS server.
    • If unknown, the request is forwarded to the Internet’s DNS hierarchy (root servers → TLD servers → authoritative servers for the domain).
    • An upstream DNS server may cache the answer to speed up future queries (TTL-based caching).
  • Internal corporate DNS example:
    • Organization domain: mycompany.com with multiple internal subdomains (e.g., web.mycompany.com, mail.mycompany.com, drive.mycompany.com).
    • Internal DNS controls these records; internal clients resolve short names inside the organization using internal DNS.
  • Practical hostname aliasing inside an organization:
    • If you want to refer to internal servers by short names (e.g., web instead of web.mycompany.com), add a search domain to /etc/resolv.conf so that short names resolve to the FQDN automatically:
    • Example: search mycompany.com or multiple domains like search mycompany.com prodmycompany.com.
    • With a search domain configured, a lookup for web becomes web.mycompany.com (or among the listed domains).
  • Caveat: appending search domains may exclude the short-name from being used if a domain is explicitly provided in the query; behavior depends on the resolver implementation.

Section 5: DNS record types and what they mean

  • A records: map a hostname to an IPv4 address (the most common type).
  • AAAA records: map a hostname to an IPv6 address (IPv6 equivalent of A).
  • CNAME records: alias one name to another name (name-to-name mapping).
    • Example use: multiple aliases for the same service, such as a delivery app reachable at multiple names (e.g., eat, hungry) all pointing to the same canonical host.
  • Summary:
    • DNS stores mappings in different record types depending on the use case (A for IPv4, AAAA for IPv6, CNAME for aliases).

Section 6: Tools for DNS testing and their caveats

  • ping: can test basic reachability using hostnames if name resolution works (via /etc/hosts or DNS).
  • nslookup: queries a DNS server for a hostname; important caveat: it does not consult /etc/hosts.
    • If you added an entry for a hostname in /etc/hosts, nslookup will not see it (it only queries DNS).
  • dig: another DNS querying tool that provides detailed DNS information similar to what’s stored on the DNS server; also queries the DNS server rather than /etc/hosts.
  • Practical takeaways:
    • Use /etc/hosts for local, static mappings when appropriate.
    • Use nslookup/dig to verify and troubleshoot DNS server configurations and responses.
    • Remember: /etc/resolv.conf and /etc/nsswitch.conf control how name resolution is performed on the host.

Section 7: Practical domain name navigation and real-world implications

  • Public Internet domains vs. internal domains:
    • Public domains (e.g., www.facebook.com) require resolution via the Internet DNS hierarchy or configured forwarders.
    • Internal domains (e.g., web.mycompany.com) are resolved by the organization’s internal DNS server.
  • Internal naming conventions and ease of use:
    • Internal domains often use short hostnames (e.g., web) but map to internal FQDNs (e.g., web.mycompany.com).
    • The resolver’s search settings allow shorthand names to resolve to fully-qualified names within the corporate namespace.
  • The root, TLD, domain, and subdomain metaphor:
    • Root ("."), Top-Level Domain (e.g., ".com"), domain ("google" in "google.com"), subdomain ("maps" in "maps.google.com").
  • Caching rationale:
    • Caching at resolving servers speeds up subsequent lookups by avoiding repeated traversal of the full DNS chain; TTL controls how long an entry is kept.

Section 8: Quick recap and study cues

  • You can create a simple local name resolution with /etc/hosts for a couple of hosts as a starting point.
  • To scale, move to a centralized DNS server and configure all hosts to use it via /etc/resolv.conf.
  • The resolution order is configurable (files vs DNS) via /etc/nsswitch.conf, and the local hosts file takes precedence if present.
  • DNS records types to know: A (IPv4), AAAA (IPv6), CNAME (alias).
  • Testing tools: ping (basic), nslookup (DNS queries; ignores /etc/hosts), dig (DNS queries with detailed output).
  • For external domains, you may configure public DNS forwarders (e.g., 8.8.8.8) on your DNS server to resolve domains on the Internet.
  • Real-world naming: internal domains (e.g., mycompany.com) and public domains (e.g., google.com) interact via a hierarchy of DNS servers, with caching to speed up resolution.

Section 9: Core takeaways for exams and practicals

  • Know how to map a host in /etc/hosts and why you might do so in a small network.
  • Understand how /etc/resolv.conf and /etc/nsswitch.conf influence DNS usage on a host.
  • Be able to describe the purpose of a DNS server in an organizational context and how forwarders work.
  • Distinguish A, AAAA, and CNAME records and their roles in DNS.
  • Use nslookup and dig to troubleshoot DNS, and remember that nslookup does not read /etc/hosts.
  • Recognize the concept of search domains and how they affect short-name resolution within an internal domain.