Card 04/ 09

ExampleDifficulty: Intermediate2 min

Debugging Example: The Site Works by IP Address but Not by Name

curl to the address returns the page and curl to the name hangs; follow the tools to the cause.

Troubleshooting top down, from the one thing that works, finds a DNS fault in four commands here. After a shop moved to a new server, curl https://shop.example.com/ hangs, but the team knows the new server's address, 203.0.113.10. Addresses are from documentation ranges, and the output is described, not captured.

Each command, its result, and what it rules out

Inputshop.example.com hangs; the new server is 203.0.113.10

  1. curl -v --resolve shop.example.com:443:203.0.113.10 https://shop.example.com/

    1. 200 OKworks
    2. server, TCP, TLS and HTTP work

    --resolve forces the address while keeping the name for the certificate check.

  2. curl -v https://shop.example.com/

    1. Trying 198.51.100.4:443 and waitingfault
    2. the name gives another address

    The first line of verbose output shows the address curl chose.

  3. dig shop.example.com

    1. A 198.51.100.4, TTL 86400fault
    2. the resolver serves the old address

    The old server was switched off, so connections to it time out.

  4. dig @ns1.example.com shop.example.com

    1. A 198.51.100.4cause
    2. the authoritative record itself is old

    Not a stale cache: the record was never changed.

ResultThe DNS record still points at the old server. Updating it fixes new lookups, and resolvers that cached it drop the old answer within its one-day TTL.

Why start at the top. The forced-address request returned a page, which proved at once that the new server, its port, its certificate and its application were all fine. Everything below HTTP was cleared in one command, leaving only the step that differs: turning the name into an address.

Why ask the authoritative server. A public or company resolver can hold an old answer until its TTL runs out. Asking ns1.example.com directly shows what the domain itself says. Had it returned 203.0.113.10, the fix would have been to wait out the TTL rather than to change anything.

What it would look like on another layer. If the forced-address request had also hung, DNS would be cleared and the fault would be the new server's port or firewall, the next layer down, checked with nc -vz 203.0.113.10 443.

The lesson is to start from something that works, change one thing at a time, and let the difference name the layer.