What Is DNS? The Internet Address Book

DNS, the Domain Name System, is the internet address book that turns a hostname like api.example.com into the IP address a client actually connects to.

Computers route traffic using numeric IP addresses, but people and config files use names. DNS bridges the two by resolving names into addresses on demand. Every pipeline that fetches a dependency, pulls an image, or calls an API first does a DNS lookup, which makes DNS a quiet but frequent source of CI flakiness.

How a lookup works

A client asks a resolver for the address of a hostname. The resolver walks the DNS hierarchy from root to top-level domain to the authoritative name server, then returns the answer. Results are cached for a time-to-live so repeat lookups are fast.

Common record types

A and AAAA records map a name to an IPv4 or IPv6 address.
CNAME records alias one name to another.
MX records point to mail servers.
TXT records hold verification and policy data.

Caching and TTL

Each record carries a TTL that tells resolvers how long to cache it. Short TTLs make changes propagate quickly but increase lookup volume; long TTLs are efficient but slow to update.

DNS in CI/CD

If DNS resolution fails, a job cannot even open a connection: it errors before any HTTP request is sent. Switching a deploy target to a new host often requires a DNS change, and the pipeline may fail until that change propagates.

Why DNS errors look flaky

Resolvers occasionally time out or return stale answers, especially right after a record changes. A job that failed with "could not resolve host" may pass on the next run with no code change, which is the classic signature of a transient DNS blip.

Handling it on runners

Reliable runners use stable resolvers and reasonable timeouts. On Latchkey, intermittent resolution failures to common endpoints are retried automatically, so a single flaky lookup does not sink an otherwise healthy build.

Key takeaways

DNS resolves human-readable names into the IP addresses clients connect to.
Records are cached for a TTL, so changes take time to propagate.
A failed lookup blocks a job before any HTTP request, and is often transient.