TechOps Examples

Hey — It's Govardhana MK 👋

Welcome to another technical edition.

Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.

Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.

While you were debating if AI would take your job, other people started using it to print money. Seriously.

Top engineers at Anthropic and OpenAI say AI now writes 100% of their code. If you're not using AI, you're spending 40 hours doing what they do in 4.

THE CODE found 100+ Claude Code hacks regular humans are using to turn AI into income. Subscribe to THE CODE for the full guide and practical ideas to help you ship 10x faster.

Start making AI money

Looking to promote your company, product, service, or event to 50,000+ Cloud Native Professionals? Let's work together. Advertise With Us

DNS resolution is the process of translating a human readable domain name into the IP address a computer needs to actually open a connection. Every request on the internet, whether it is loading a website, calling an API, or connecting to a database over its hostname, starts with this translation step. A misconfigured record here does not throw a clean error either. The application just times out, or worse, silently connects to the wrong server, which is why understanding this chain in depth matters far more than most engineers assume. Let us start with the Fully Qualified Domain Name (FQDN) breakdown, which is the foundation of how DNS resolution works.

When you type a URL like https://data.www.techopsexamples.com., each part has a role:

This is how a DNS query travels through multiple servers to resolve a domain into its IP address.

The local DNS server here is doing what is called recursive resolution, meaning it does all the work of walking down the chain on the client's behalf. The root and TLD servers, by contrast, only perform iterative resolution, meaning they never chase down the answer themselves; they simply say "I don't know, but ask this other server." This distinction matters operationally because recursive resolvers are the ones vulnerable to cache poisoning attacks and are the ones you configure DNSSEC validation on, while root and TLD servers are read only referral engines with effectively zero attack surface for that particular class of exploit.

Each hop in this chain also has its own response caching behavior governed by TTL, time to live, a value attached to every DNS record specifying how long a resolver may reuse that answer before re-querying. A record with a 3600 second TTL means any resolver caching that answer keeps serving it for up to an hour after the authoritative server changes it, which is precisely why teams lower a record's TTL to something like 60 seconds ahead of a planned migration, then raise it back afterward once the new IP has propagated, trading off cache efficiency for faster rollback capability during the risky window.

DNS queries also travel over UDP port 53 by default, falling back to TCP only when the response exceeds 512 bytes in the original protocol, or when the resolver explicitly requests TCP, which happens for zone transfers and for DNSSEC responses carrying signature data. A firewall blocking outbound UDP 53 while allowing TCP 53 produces the particularly confusing symptom of some lookups succeeding and others failing intermittently, depending on response size.

With this basic understanding, let us visually explore the different types of DNS resolution in a VPC.

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)