This is how DNS works, traced through a single lookup from your laptop to the answer, so every production DNS problem you have hit suddenly makes sense.
Highlights
- DNS translates names into addresses through a chain of four participants, and knowing which one is answering you is the whole skill of troubleshooting it.
- A single lookup can touch a stub resolver, a recursive resolver, a root server, a TLD server, and an authoritative server, and each of those hops is a different place for things to go wrong.
- TTL is the most consequential number most engineers never think about, because it decides how long the internet keeps believing something that is no longer true.
- DNS propagation is a myth worth unlearning, since nothing is pushed anywhere and what you are really waiting for is caches expiring on their own schedule.
- Kubernetes runs its own DNS through CoreDNS, and a default setting called ndots quietly turns one external lookup into five queries.
- The
digcommand answers almost every DNS question you will ever have, and three of its flags cover the vast majority of real incidents. - Dangling DNS records are a genuine security risk, because a record pointing at infrastructure you no longer own can be claimed by somebody who does.
On 20 October 2025, an outage at Amazon Web Services became one of the most damaging the company had seen in years, starting before dawn in its largest region and spreading outward to services across finance, retail, and communications. The trigger was DNS resolution, which is why a phrase that engineers have repeated as a joke for a decade keeps turning out to be true: it is always DNS. Three months earlier, Cloudflare's public resolver at 1.1.1.1 went dark for 62 minutes, and as Cloudflare's own write up put it, for many users that meant essentially every internet service became unavailable at once. Not slow. Unavailable.
Here is what makes DNS unusual as a thing to learn. You already use it hundreds of times a day, you have almost certainly edited a DNS record, and there is a good chance nobody ever sat you down and explained the mechanism. That gap is comfortable right up until the afternoon a deployment succeeds, the health checks pass, the pods are running, and users still report the old version, and you have no mental model for where to look. This guide closes that gap by following one single lookup from beginning to end, then showing you exactly where that journey breaks in real infrastructure.
How DNS works in one paragraph
The Domain Name System is a distributed, hierarchical database whose main job is translating human readable names such as api.example.com into machine routable addresses such as 192.0.2.45, using a chain of servers where each one either knows the answer or knows who to ask next.
Two words in that sentence carry most of the weight. Distributed means there is no single machine holding a master list, and the data lives spread across millions of servers operated by different organisations. Hierarchical means the system is organised as a tree, read right to left, so the answer for api.example.com is found by starting at the very top and walking down one level at a time.
That right to left reading is worth pausing on because it feels backwards the first time. A fully qualified domain name is actually api.example.com. with a trailing dot, and that final dot represents the root of the entire system. Your browser hides it, but every resolver treats it as real.
Did you know
The root of DNS is served by 13 named server addresses, from a.root-servers.net to m.root-servers.net, and that number has not changed since the 1990s because it was limited by how much data fits in a single UDP packet. There are not 13 physical machines though. Through a routing technique called anycast, those 13 addresses are answered by well over 1,500 physical servers spread across the world, and your query reaches whichever one is closest to you on the network.
The four participants
Almost every DNS problem becomes tractable the moment you can name which of these four is misbehaving.
The critical distinction, and the one that trips up beginners most, is between the recursive resolver and the authoritative server. The recursive resolver is the one asking questions and remembering answers. The authoritative server is the one that actually owns the truth. When you change a DNS record, you change it on the authoritative server, and every recursive resolver in the world carries on repeating the old answer until its cached copy expires.
That single sentence explains most of the DNS confusion you will encounter for the rest of your career.
The journey of one lookup
Now the spine of this guide. Somebody opens a browser and requests api.example.com, and here is every stop that request makes.
Stop one is the browser's own cache. Browsers keep a small internal DNS cache, typically for a minute or so, which is why a page can start working in a new tab before it works in the tab you already have open. If the answer is here, nothing else in this list happens.
Stop two is the operating system's stub resolver and its cache. On Linux this is often systemd-resolved or nscd, on macOS it is mDNSResponder, and on Windows it is the DNS Client service. The stub resolver also consults local overrides first, which on Linux means /etc/hosts and the rules in /etc/nsswitch.conf. An entry in the hosts file wins over the entire internet, which makes it both a useful testing tool and an occasional source of profound confusion.
Stop three is the recursive resolver. Your machine sends the query to whatever address is configured in /etc/resolv.conf, which in a cloud environment usually points at the VPC resolver, and in Kubernetes points at the cluster DNS service. This resolver is where the real work begins, and it is also where most caching that matters to you happens.
Stop four is the root. If the recursive resolver has nothing useful cached, it asks a root server about api.example.com. The root does not know the answer and does not pretend to. It replies with a referral, meaning a list of the servers responsible for .com.
Stop five is the TLD server. The resolver now asks a .com server the same question. That server also does not know the address, but it does know which name servers are authoritative for example.com, so it returns another referral listing those.
Stop six is the authoritative server. The resolver finally asks the name server that actually holds the zone. This one answers properly, returning an A record with the address and a TTL saying how long the answer may be cached.
Stop seven is caching on the way back. The recursive resolver stores the answer for the duration of the TTL, then hands it to your stub resolver, which caches it too, and the browser caches it as well. Three separate caches now hold this answer, each with its own idea of when to let go.
Stop eight is the connection. Only now does your browser open a TCP connection to the address it received. Everything above happened before a single byte of your actual request was sent.
That entire journey usually takes between 20 and 120 milliseconds the first time and effectively zero milliseconds afterwards, because step three or earlier answers it from cache. Understanding that the fast path and the slow path are wildly different is what makes DNS latency problems intelligible.
In the wild
A team once reported that their API was "randomly slow for the first user every morning". Their resolver cached answers for 300 seconds, their traffic dropped to zero overnight, and so the first request of the day always paid the full recursive lookup cost while every subsequent request was served from cache. Nothing was broken. They were simply watching the difference between a cold cache and a warm one, and they had never had a reason to notice it before.
The record types you will actually touch
DNS defines dozens of record types. In practice a DevOps engineer works with about ten, and knowing what each one can and cannot do prevents a surprising number of outages.
The CNAME row deserves expansion because it causes more real incidents than any other record type. A CNAME says this name is an alias for that other name, and the rules say a name holding a CNAME cannot hold any other record. That is fine for www.example.com, but it becomes a genuine problem at the apex of a domain, meaning example.com itself with no subdomain, because the apex must already hold NS and SOA records.
Watch out
You cannot put a CNAME on the apex of a domain, which is exactly what you want to do when your load balancer gives you a hostname rather than an IP address. Providers solved this with proprietary record types that behave like a CNAME but return an address, called ALIAS at some providers, ANAME at others, and simply an alias record in Route 53. They work well, but they are provider specific, so a migration between DNS providers will need this translated rather than copied.
TTL, the number that decides everything
If you take one operational lesson from this guide, take this one. Time to live is a number attached to every DNS answer that says how many seconds a resolver may keep using it before asking again. It is measured in seconds, it is set on the authoritative side, and it is the single biggest factor in how quickly a DNS change takes effect.
A TTL of 3600 means resolvers may cache that answer for an hour. If you change the record now, some resolvers will keep handing out the old address for up to a full hour afterwards, and there is nothing you can do to make them stop.
Read that again, because it is the part people find hardest to accept. You cannot flush somebody else's cache. Not your users' ISP resolvers, not their corporate resolvers, not the browser on their laptop. Once an answer is out there with a TTL, you wait.
Watch out
There is no such thing as DNS propagation, and the word does real damage to people's mental models. Nothing is being pushed anywhere. Your authoritative server updated instantly the moment you saved the record. What you are waiting for is thousands of independent caches around the world reaching the end of their own TTL countdowns, each one having started at a different moment. That is why a change appears to roll out gradually and unevenly, and why checking from one location tells you almost nothing about what everyone else sees.
The pre migration ritual
Because TTL governs how long the old answer survives, the professional habit is to lower it before you need to change anything.
Suppose you plan to move a service to a new address on Saturday. Your record currently has a TTL of 3600. The day before, you change nothing except the TTL, dropping it to 60. You then wait a full hour, which is the length of the old TTL, so that every cache holding the old copy has expired and picked up the new short lived one. By Saturday, every resolver is refreshing its answer every 60 seconds, so your actual change takes effect within a minute rather than an hour. Once the migration is finished and stable, you raise the TTL back to 3600 to reduce query load and improve resilience.
That sequence, lower, wait, change, raise, is the closest thing DNS has to a universal operational ritual, and skipping it is behind a large share of migration incidents.
Choosing a TTL
There is a genuine tradeoff here rather than a correct answer.
A short TTL is not free, and this is where the tradeoff gets interesting. If every resolver refreshes every 60 seconds, your authoritative servers handle far more traffic, and more importantly, your service becomes more sensitive to your DNS provider having a bad day. A long TTL means resolvers can keep serving your old answer for a while even if your DNS provider goes down entirely, which is an accidental form of resilience.
Negative caching, the sneaky one
Resolvers cache failures too. When a lookup returns NXDOMAIN, meaning the name does not exist, that non answer is also cached, and its duration comes from the minimum field in the zone's SOA record rather than from any TTL you set on the record itself.
This catches people out constantly. You create a new subdomain, you check it a moment too early, you get NXDOMAIN, and now your resolver has cached that failure for however long the SOA minimum says, often 300 or 900 seconds. You create the record correctly, you check again, and it still fails, so you assume something is broken and start changing things. Nothing was broken. You simply asked before it existed and got told no, convincingly, for a while.
The practical habit is to create the record first and check afterwards, rather than checking first out of curiosity.
Learn the networking layer under all of this
DNS makes far more sense once you are comfortable with the layers beneath it, including how a resolver is configured, how TCP and UDP differ, and how routing gets your packets to the right place. The DevOps Pre Requisite Course on KodeKloud covers networking fundamentals, Linux basics, and the supporting concepts this guide assumes, which makes it a good place to shore up anything above that felt shaky.
Reading DNS with dig
The dig command is the tool that answers DNS questions honestly, and learning four of its forms covers nearly everything you will need.
Its simplest form asks your configured resolver for a record and prints a full report including the answer section, the query time, and which server responded.
dig api.example.comAdding +short strips everything except the answer itself, which is what you want inside scripts or when you just need the value quickly.
dig +short api.example.comPutting an @ followed by a server address asks that specific server instead of your configured one, which is how you compare what different resolvers believe. Asking the authoritative server directly tells you the truth as it stands right now, while asking a public resolver tells you what a cached copy still says.
dig @ns1.provider.net api.example.com
dig @8.8.8.8 api.example.comThe +trace flag is the one worth memorising, because it performs the entire recursive walk yourself, printing every referral from root to TLD to authoritative. When a name resolves for some people and not others, this shows you exactly which level of the hierarchy is disagreeing.
dig +trace api.example.comBeyond those four, a handful of forms come up regularly enough to keep in your notes.
dig api.example.com MX
dig -x 192.0.2.45
dig example.com NS +short
dig example.com SOA +short
dig api.example.com +noall +answerThe first requests a specific record type rather than the default A record. The second performs a reverse lookup, turning an address back into a name. The third and fourth reveal a domain's name servers and its zone metadata, which is where you find the SOA minimum controlling negative caching. The last trims the output to just the answer section while keeping the full record format, which is the most readable form for troubleshooting.
Quick tip
Read the TTL value in dig's answer section as a countdown rather than a setting. If a record has a configured TTL of 300 and dig shows 47, that means the resolver you asked cached this answer 253 seconds ago and will refresh it in 47 seconds. Run the same command twice a few seconds apart and watch the number fall. When it resets to 300, you have just witnessed the cache expiring and a fresh answer arriving, which is a genuinely useful thing to be able to observe during a migration.
DNS in the deployment path
Now the part that makes DNS a DevOps concern rather than a networking curiosity. DNS sits in front of nearly every deployment strategy, and its caching behaviour shapes what those strategies can actually promise.
Blue green deployments often switch traffic by repointing a DNS record from the blue environment to the green one. This works, and its weakness is exactly the TTL problem, because some users keep reaching blue until caches expire. That means you cannot decommission blue the moment you flip the record, and the safe pattern is to keep the old environment running for at least the length of the previous TTL, ideally longer.
Failover through DNS uses health checks at the DNS provider, which stop returning an address once a target is failing. The response time depends on the health check interval plus the TTL, so a 30 second health check with a 300 second TTL gives you a worst case of well over five minutes before all traffic moves. If you need faster failover than that, DNS is the wrong layer and you want a load balancer or anycast handling it instead.
Weighted routing returns different addresses to different queries according to weights you set, which is how DNS based canary releases work. The catch is that weights apply to queries rather than users, and because of caching, one resolver serving thousands of corporate users may cache a single answer and send all of them to the same place. Your 10 percent canary can very easily become 40 percent of real traffic or zero percent, depending on whose resolver cached what.
Latency and geolocation routing return different answers depending on where the query came from. The subtlety is that the provider sees the resolver's location rather than the user's, so a user on a public resolver in a different country may be routed by that resolver's location instead of their own. The EDNS Client Subnet extension exists to pass a truncated client address along and improve this, though support varies.
In the wild
A team ran a DNS weighted canary at 5 percent and saw error rates that made no sense against their traffic estimates. The cause was a single large enterprise customer whose corporate resolver cached the canary answer and sent every employee to the new version for the full TTL. The lesson is not that weighted DNS is broken. It is that DNS distributes across resolvers rather than across users, and if your traffic is concentrated behind a few big resolvers, the distribution you get will not resemble the distribution you asked for.
DNS inside Kubernetes
Kubernetes runs its own DNS, and once you know how it works, a whole category of confusing cluster behaviour becomes obvious.
Every cluster runs CoreDNS, usually as a Deployment in the kube-system namespace, exposed through a Service typically at 10.96.0.10. Every pod gets a /etc/resolv.conf pointing at that Service, so all name resolution inside the cluster goes through CoreDNS first, including lookups for external names, which CoreDNS forwards upstream.
Kubernetes gives every Service a predictable name following a fixed pattern of service, namespace, svc, and the cluster domain. A Service named payments in the namespace prod is reachable at payments.prod.svc.cluster.local, and because of search domains you can usually shorten that to payments from a pod in the same namespace or payments.prod from anywhere in the cluster.
Those search domains are configured in every pod's resolv.conf, and this is where the interesting behaviour begins.
kubectl run tmp --rm -it --image=busybox:1.36 --restart=Never -- cat /etc/resolv.confThat command starts a throwaway pod, prints its resolver configuration, and deletes it. The output shows a nameserver pointing at CoreDNS, a search list containing several cluster suffixes, and an options line containing ndots:5.
Watch out
The ndots:5 setting means any name containing fewer than five dots is treated as possibly relative, so the resolver tries it against every search domain before trying it as written. Looking up api.github.com, which has two dots, produces attempts at api.github.com.prod.svc.cluster.local, then api.github.com.svc.cluster.local, then api.github.com.cluster.local, and only then the name itself. That is four failed lookups before the one that works, and each failure is a real query with real latency. Adding a trailing dot, so api.github.com., marks the name as fully qualified and skips the search list entirely, which is a genuinely useful trick for external calls in hot paths.
Two more Kubernetes DNS behaviours are worth knowing.
A headless Service, meaning one with clusterIP: None, returns the addresses of the individual pods behind it rather than a single virtual address. This is what StatefulSets use so that each pod gets a stable, individually addressable name, which is essential for databases and clustered applications where members need to find each other specifically.
DNS caching inside pods is often weaker than people assume. Many application runtimes cache DNS results in process, and some JVM configurations historically cached them forever, which means a pod may keep talking to an address long after the Service behind it has changed. When a pod stubbornly connects to something that no longer exists, in process DNS caching is a strong suspect.
Practise this against a real cluster
Reading about CoreDNS and search domains is one thing, and running dig from inside a pod while you watch the search list expand your query is quite another. The Certified Kubernetes Administrator (CKA) course on KodeKloud covers cluster networking, Services, and DNS troubleshooting through hands on labs, and the KodeKloud playgrounds give you a live cluster where you can break resolution deliberately and watch what happens.
A troubleshooting ladder
When something does not resolve, work down this ladder rather than guessing. Each rung eliminates a specific participant.
Rung one asks whether it is DNS at all. Try the address directly with curl or ping and see whether the service responds. If connecting to the address works and connecting to the name does not, you have confirmed a DNS problem rather than a network or application one, which is worth thirty seconds because it eliminates most of the possibilities.
Rung two checks what your machine is asking. Look at /etc/resolv.conf to see which resolver you are using and what search domains apply, since a wrong resolver or an unexpected search suffix explains a lot of strange behaviour.
Rung three separates cache from truth. Query the authoritative server directly and compare its answer with what your normal resolver returns. If the authoritative server has the right answer and your resolver has a stale one, you are simply waiting for a TTL and there is nothing to fix.
Rung four walks the hierarchy. Run dig +trace and read the referrals. A break here usually means an NS record problem, a delegation that points at name servers which no longer serve the zone, or a registrar level misconfiguration.
Rung five checks the local overrides. Look at /etc/hosts for an entry that is silently overriding the world, which is embarrassingly often the answer on a developer machine that somebody used for testing months ago.
Rung six considers the negative cache. If a newly created record still returns NXDOMAIN, check the SOA minimum, wait it out, and resist the urge to keep changing things while a cached failure expires on its own schedule.
curl -sS -o /dev/null -w '%{http_code}\n' http://192.0.2.45/healthz
cat /etc/resolv.conf
dig @ns1.provider.net api.example.com +noall +answer
dig +trace api.example.com
grep -n example.com /etc/hosts
dig example.com SOA +shortThose six commands map one to one onto the six rungs above, and running them in order will identify the cause of the overwhelming majority of DNS incidents faster than any amount of speculation.
DNS as a security surface
DNS is not only an availability concern, and a few security ideas are worth carrying even at a beginner level.
DNSSEC adds cryptographic signatures to DNS records so a resolver can verify that an answer really came from the zone owner and was not tampered with in transit. It solves a genuine problem, and it also adds operational complexity, because an expired signature takes your domain offline just as effectively as deleting the records.
DNS over HTTPS and DNS over TLS encrypt the query between the client and the resolver. They protect user privacy against network observers, and they are worth understanding because they can complicate your internal network monitoring, since DNS queries that used to be visible in plaintext no longer are.
Cache poisoning describes an attacker convincing a resolver to store a false answer, and it is the reason source port randomisation and DNSSEC exist. Modern resolvers are much harder to poison than they were, though research keeps finding new angles.
Subdomain takeover is the one that most often affects DevOps teams directly, and it comes from a mistake that feels harmless.
Did you know
A dangling DNS record is one that still points at infrastructure you no longer control. If status.example.com is a CNAME pointing at a cloud storage bucket or a hosting provider account, and somebody deletes that bucket without removing the DNS record, an attacker can create a resource with the same name at that provider and start serving content on your subdomain, complete with a valid certificate. Regular audits of what your DNS records point at, especially after decommissioning anything, are the fix. It is a cheap habit that closes a genuinely dangerous gap.
A full scenario, start to finish
Here is everything above applied to one realistic afternoon.
A payments team migrates their API from an old load balancer to a new one. The change is made at 14:00 by updating an A record. At 14:05, monitoring shows traffic arriving at both the old and new load balancers. At 14:20, a customer reports intermittent failures, describing requests that sometimes work and sometimes hit an error page.
The on call engineer starts at rung one and confirms the new load balancer serves correctly when called by address, so the application is fine. At rung three, they query the authoritative server and see the new address, correct and in place. They then query a public resolver and see the old address still being returned, with a dig TTL countdown showing 2,340 seconds remaining.
There it is. The record had a TTL of 3600 and nobody lowered it in advance, so caches around the world will keep handing out the old address for up to another 39 minutes. Meanwhile the customer's intermittent failures are explained by their having several resolvers, some of which had refreshed and some of which had not, so their requests were splitting between old and new.
The correct response is now clear, and notably it is not to keep changing DNS. The team leaves the record alone, keeps the old load balancer running and healthy so that cached clients continue to work, lowers the TTL to 60 for next time, and communicates a window rather than an instant cutover. By 15:00 all traffic has moved on its own.
Nothing here required deep expertise. It required knowing that caches exist, that TTL governs them, and that dig will tell you exactly how much longer you have to wait.
Where to start
- Run
digagainst a domain your team owns, read every section of the output, and identify the TTL, the answer, and which server responded. - Run
dig +traceon the same name and follow the referrals from root to TLD to authoritative until the path makes sense to you. - Audit the TTLs on your production records and write down which ones would slow down an emergency change.
- Add lowering the TTL 24 hours in advance to your migration checklist, because it costs nothing and saves entire incidents.
- Inside a cluster, print a pod's
/etc/resolv.conf, find thendots:5line, and try an external lookup with and without a trailing dot. - Review your DNS records for anything pointing at infrastructure you no longer own, and delete what is dangling.
- Write the six command troubleshooting ladder into your team runbook so the next person does not have to remember it under pressure.
Conclusion
DNS has a reputation for being mysterious, and almost none of that reputation is deserved. It is a hierarchical lookup with caching at several layers, and the two ideas that explain nearly every problem are that the authoritative server holds the truth while resolvers hold copies, and that TTL decides how long those copies survive after the truth changes.
Everything else follows from there. Migrations need a TTL lowered in advance because caches cannot be flushed remotely. Weighted canaries distribute across resolvers rather than users. Kubernetes lookups pick up extra queries because of a search domain setting. Newly created records appear to fail because a negative answer was cached before they existed.
So spend twenty minutes with dig this week against names you actually own, and watch a TTL count down until it resets. That single observation, seeing a cache expire in real time, converts DNS from something you tolerate into something you can reason about. The next time somebody says it is always DNS, you will be the person who can say precisely why, and fix it.
Ready to Build the Fundamentals Underneath This?
DNS sits on top of networking, Linux, and cluster concepts that reward proper study rather than accumulated guesswork. The DevOps Pre Requisite Course on KodeKloud covers the networking and Linux foundations this guide assumes, the Certified Kubernetes Administrator (CKA) course covers cluster networking and DNS troubleshooting in depth, and the KodeKloud playgrounds give you environments where you can break resolution on purpose and watch exactly what happens. Start with one this week.
FAQs
Q1: What is the difference between a recursive resolver and an authoritative name server?
The recursive resolver is the server that does the searching on your behalf, and the authoritative name server is the one that actually holds the records. When your machine needs an address, it asks a recursive resolver, typically run by your ISP, your cloud provider, or a public service. That resolver then walks down the hierarchy, asking a root server, then a top level domain server, then the authoritative server for the domain, and it caches everything it learns along the way so the next request is much faster. The authoritative server is the source of truth, meaning it holds the actual zone data that a domain owner configures and it sets the TTL on every answer it gives. The distinction matters enormously in practice, because when you change a record you change it on the authoritative server, while every recursive resolver in the world continues serving its cached copy until that copy expires. Almost every moment of DNS confusion comes from forgetting that these are two different machines with two different jobs.
Q2: Why do my DNS changes take so long to appear, and can I speed them up?
Your change already took effect instantly on your authoritative server, and what you are waiting for is caches elsewhere expiring. Every answer DNS gives carries a TTL, which tells resolvers how many seconds they may keep using it, so if your record had a TTL of 3600 then resolvers that fetched it just before your change will keep serving the old value for up to an hour. You cannot flush somebody else's cache, which means there is no way to accelerate a change once it is made, and this is why the term propagation is misleading since nothing is being pushed anywhere. What you can do is plan ahead. Lower the TTL to 60 seconds at least one full old TTL period before the change, so that every cache picks up the short lived version first, then make your actual change and watch it take effect within a minute. Afterwards, raise the TTL back to something sensible to reduce query load and keep some resilience if your DNS provider has problems.
Q3: What do I need to know before working with DNS in a DevOps role?
You need less than people expect, and the essentials are conceptual rather than technical. Understand the hierarchy and how a lookup walks from root to TLD to authoritative, because that model makes troubleshooting systematic instead of speculative. Know the common record types and specifically why a CNAME cannot live at a domain apex, since that limitation shapes real architecture decisions. Understand TTL deeply, including negative caching through the SOA minimum, as that single concept explains most of the surprises you will encounter. On the practical side, be able to use dig with +short, +trace, and the @server form, and be comfortable reading /etc/resolv.conf and /etc/hosts. If you want structured grounding in the networking and Linux layers underneath, the DevOps Pre Requisite Course on KodeKloud covers those foundations, and the KodeKloud playgrounds give you machines to experiment on safely.
Q4: Why does DNS resolution behave differently inside Kubernetes?
Because Kubernetes runs its own DNS server and configures every pod to use it with settings tuned for internal service discovery rather than internet lookups. CoreDNS runs in the cluster and answers queries for Service names following the pattern of service, namespace, svc, and the cluster domain, so a Service called payments in namespace prod resolves as payments.prod.svc.cluster.local. Every pod's resolver configuration includes search domains that let you use shorter names, plus an option called ndots:5 which means any name with fewer than five dots is tried against each search domain first. That is why looking up an external name such as api.github.com from inside a pod generates several failed queries before the successful one, adding latency you would not see outside the cluster. Appending a trailing dot to make the name fully qualified skips the search list entirely. It is also worth knowing that headless Services return individual pod addresses rather than a single virtual address, and that many application runtimes cache DNS in process, which can make a pod keep talking to an address long after the cluster has moved on.
Q5: What is the difference between a CNAME and an A record, and when should I use each?
An A record maps a name directly to an IPv4 address, while a CNAME maps a name to another name, so the resolver must then look that second name up as well. Use an A record when you know the address and it is stable, such as a fixed server or an assigned static address, since it is one lookup and one answer with nothing else involved. Use a CNAME when you want to point at something whose address may change without your involvement, which is the usual case for cloud load balancers, content delivery networks, and managed services, because the provider can change the underlying addresses freely and your record keeps working. Two rules matter in practice. A name holding a CNAME cannot hold any other record type, which is why you cannot place one at the apex of a domain where NS and SOA records already live, and providers work around this with proprietary alias record types that behave similarly while returning an address. The other is that each CNAME adds a lookup step, so chaining several of them together adds latency and creates more places for something to break.
Q6: How is DNS actually used to attack systems, and what should I watch for?
Three patterns are worth knowing at this level. Subdomain takeover is the one most likely to affect your own infrastructure, and it happens when a DNS record still points at a provider resource that has been deleted, letting somebody else claim that name at the provider and serve content on your subdomain, which makes auditing records after any decommissioning genuinely important. Cache poisoning involves persuading a resolver to store a false answer so that users are sent to an attacker controlled address, which is the threat DNSSEC and source port randomisation were designed to reduce. DNS is also widely used as a covert channel, since queries often flow freely out of networks that block other traffic, which makes DNS logs a valuable source for detecting data exfiltration and malware beaconing. On the defensive side, the highest value habits are keeping an accurate inventory of what your records point at, removing dangling entries promptly, using CAA records to limit which certificate authorities may issue for your domain, and monitoring your DNS query logs the same way you would monitor any other traffic.
Discussion