DNS & How URLs Resolve

By the end of this lesson you can:

• Trace how a domain name resolves to an IP through the DNS hierarchy.
• Name the common record types (A, AAAA, MX, TXT, CNAME, NS) and what they reveal.
• Explain DNS security risks: spoofing/cache poisoning, hijacking, and recon.
• Query DNS from Python and understand DNSSEC / DoH as defences.

Computers route by IP, but humans remember names. Every time you visit a site, a hidden lookup turns example.com into something like 93.184.216.34 — and you trust whatever answer comes back. That trust is exactly what attackers target.

The resolution journey

You type "www.example.com". Your resolver asks, in order:

1. cache?        already known recently? → done (fast)
2. root server   "who handles .com?"      → points to .com TLD servers
3. TLD server    "who handles example.com?" → points to its nameservers
4. authoritative "what's www.example.com's A record?" → 93.184.216.34
                 ↓
     IP returned, cached for its TTL, browser connects.

It's a hierarchy: root → top-level domain (.com) → authoritative nameserver. Results are cached for a TTL (time-to-live) so the whole journey isn't repeated for every request.

Record types — and what each reveals

A      name → IPv4 address        (where the site lives)
AAAA   name → IPv6 address
CNAME  alias → another name        (www → example.com)
MX     mail servers for the domain (recon: email infrastructure)
TXT    arbitrary text             (SPF/DKIM, domain verification — leaks tools used)
NS     the domain's nameservers
PTR    IP → name (reverse lookup)

To a defender these are config; to a recon analyst they're a map. MX records reveal the email provider; TXT records often list which SaaS tools verify the domain; subdomains hint at internal systems. This is all public — which is why Lesson 6's passive recon is legal: you're reading published records, not breaking in.

DNS security risks

• Spoofing / cache poisoning — an attacker injects a fake answer so a name resolves to their server. You think you're at your bank; you're not.
• DNS hijacking — compromising the registrar/account to change records, redirecting all traffic.
• DDoS via DNS — DNS amplification attacks, or knocking a provider offline (the 2016 Dyn outage).
• Data exfiltration — malware sneaking data out inside DNS queries (it's often unmonitored).

Defences

• DNSSEC — cryptographically signs records so forged answers are rejected (integrity).
• DoH / DoT — DNS over HTTPS/TLS encrypts the query so it can't be sniffed or tampered (confidentiality + integrity).
• Monitoring — watch for unexpected record changes and unusual query volumes.

Querying DNS from Python

import socket

# basic forward + reverse lookups (built-in, no extra library)
ip = socket.gethostbyname("example.com")          # A record
print("example.com →", ip)

# full info: name, aliases, all addresses
name, aliases, ips = socket.gethostbyname_ex("example.com")
print("addresses:", ips)

# reverse: IP → name (PTR)
try:
    host, *_ = socket.gethostbyaddr("8.8.8.8")
    print("8.8.8.8 →", host)        # dns.google
except socket.herror:
    print("no PTR record")

For richer queries (MX, TXT, NS) use the dnspython library (pip install dnspython) — we'll lean on it for the recon toolkit next lesson. Querying public DNS records of any domain is legal; it's reading the phone book.

Goal: a tool that resolves a domain's key records and explains, from a defender's view, what each reveals. Uses only public DNS — entirely legal.

import socket
try:
    import dns.resolver        # pip install dnspython
    HAS_DNS = True
except ImportError:
    HAS_DNS = False

def inspect(domain: str) -> None:
    print(f"=== DNS inspection: {domain} ===")

    # A records (built-in)
    try:
        _, _, ips = socket.gethostbyname_ex(domain)
        print("A   ", ", ".join(ips), "  (where it's hosted)")
    except socket.gaierror:
        print("A    could not resolve"); return

    if not HAS_DNS:
        print("(install dnspython for MX/TXT/NS records)")
        return

    for rtype, hint in [("MX", "email infrastructure"),
                        ("NS", "who controls DNS"),
                        ("TXT", "verification tokens / SPF — leaks tools used")]:
        try:
            answers = dns.resolver.resolve(domain, rtype)
            for r in answers:
                print(f"{rtype:4} {str(r)[:60]}   ({hint})")
        except Exception:
            print(f"{rtype:4} none")

inspect("example.com")

=== DNS inspection: example.com ===
A    93.184.216.34   (where it's hosted)
MX   none
NS   a.iana-servers.net.   (who controls DNS)
NS   b.iana-servers.net.   (who controls DNS)
TXT  "v=spf1 -all"   (verification tokens / SPF — leaks tools used)

Read the code

Each record is annotated with what it tells an analyst. On a real organisation, the MX records reveal the email provider (Google? Microsoft?), TXT records often list SaaS verification tokens (which CRM, which security vendor), and NS shows who runs their DNS — all public, all useful for both attackers (targeting) and defenders (knowing your own footprint). This is the heart of passive reconnaissance, which Lesson 6 builds into a full toolkit. Nothing here touches the target's servers; it queries public DNS.

DNS resolves names to IPs through a cached hierarchy: root → TLD → authoritative nameserver, with answers held for their TTL. Record types (A/AAAA, CNAME, MX, TXT, NS, PTR) both configure services and publicly reveal infrastructure — which is why DNS is a recon goldmine and reading public records is legal. Security risks include spoofing/cache poisoning (you're silently misdirected), hijacking, DNS-based DDoS, and exfiltration; defences are DNSSEC (signed records), DoH/DoT (encrypted queries), and monitoring. Query it from Python via socket or dnspython — and audit your own footprint to minimise what you expose.