What Is DNS and How Does It Work? Records and TTL

DNS (the Domain Name System) is the system that translates the domain names people use into the IP addresses machines use. You type sercebilisim.com in the browser, your computer actually connects to a number like 203.0.113.42, and DNS does the translation in between. When it fails, it looks like the internet is down: sites won’t open, mail won’t send, the in-house app won’t start. Yet the line is fine and you have an address; the place you’d ask who is where just isn’t answering.

Think of directory assistance, the operator you’d call to get a number. You knew the person’s name but not their number; you called the operator, gave the name, and got the number back. Then you’d save that number in your phone and never ask again. When the person changed their number, your saved copy kept showing the old one for a while; you were dialling the wrong place and didn’t know it. The whole thing rested on those three facts: knowing the name but not the number, saving the answer somewhere, and that saved answer one day going stale.

DNS is exactly that service, and we’ll come back to the same operator throughout this article. Below we’ll first look at what DNS does, then at the stops a query passes through from the root server to the authoritative server. Then we’ll reach the part most people confuse: the party that sells the domain name is not the party that holds the records. After that we’ll cover the record types (A, CNAME, MX, TXT, SRV), why a change doesn’t show up immediately, who answers the query on a corporate network, and which command to reach for when something breaks. If you have a name that won’t resolve right now, jump straight to the diagnosis order.

This article is part of the network segmentation guide: DNS is the directory link in the chain of protocols that keep an organisation running. Measurements come from the author’s lab; names and addresses are left exactly as they were captured.

What Is DNS, and What Does It Do?

DNS is a distributed database that translates a name into an address, and it uses port 53. Its job in one sentence: you say sercebilisim.com, it tells you which number that name sits at today. A job that simple is the one the whole internet is built on.

From Name to Address: What DNS Actually Resolves

The problem DNS solves is not memory, it’s change. Anyone can memorise a few IP addresses; the real trouble is that those addresses change. You move your server to another provider, you switch your mail service, your hosting platform rebuilds its own infrastructure. In all of these the IP changes. The name does not.

That’s why the directory existed too. Not because people couldn’t memorise numbers, but because numbers change as things move. The name stays fixed, the number shifts underneath, and a record is kept that binds the two.

The practical takeaway: DNS is an answer, not a redirect. It sends nobody anywhere, it only tells you the value of the name you asked about. The party that makes the connection is your device. That distinction pays off in diagnosis; later, when we separate “the name resolves correctly but the connection won’t form,” we’ll come back here.

What Stops When DNS Stops?

When DNS fails the network stays up but almost nothing works, because there’s nothing in an organisation that isn’t called by a name. Websites won’t open, mail can’t be delivered, the file server is unreachable, the licence server can’t be contacted, the backup job can’t find its target.

On the corporate side there’s one more layer, and it’s the one usually forgotten. In a domain environment the client learns which Domain Controller to contact from SRV records in DNS. So DNS isn’t just a “name-to-address” service, it’s the directory of the identity infrastructure itself. A large share of the Active Directory faults I’ve seen in the field are actually DNS faults, and nowhere in the error message does the word DNS appear.

The symptom not naming itself is a recurring theme in this article. The user tells you “the internet’s gone,” “I can’t sign in to the domain,” “my mail lands in spam.” The same layer can sit under all three.

Where Does a DNS Query Go? Root, TLD and Authoritative

A DNS query doesn’t go to one server. First it reaches a resolver that will look for the answer on your behalf; that resolver then walks a chain from the root down, visiting three stops in turn. Knowing the chain is the only way to tell which link a fault sits in.

The Chain Works in Four Stops

When your device asks for sercebilisim.com, it goes like this. First the query goes to a recursive resolver: your internal DNS server, your ISP’s server, or a public resolver like 1.1.1.1. Finding the answer is now its job.

If the resolver doesn’t have the answer cached, it asks the root servers. The root doesn’t know the answer; it only says who handles the .com suffix. Then the TLD server is asked, and it doesn’t know the address either; it only says which servers hold the records for sercebilisim.com. At the last stop that server, the authoritative server, is asked, and the real answer comes from there.

That’s exactly what happened with the operator too. They didn’t know your number by heart; they knew which region’s, which organisation’s record to check, and they took you all the way to where the record was actually held. You called one place, three tiers worked behind it.

The chain’s most important property: the one true source is the authoritative server. The root and TLD never give an address, they only point the way. If you want to know whether a record change was made correctly, you have to ask the authoritative server directly; every tier in between can hand you a saved, stale answer.

Recursive vs. Iterative Queries

There are two query types, and the difference is who takes on the work. The query your device makes to the resolver is recursive: “bring me the final answer, I don’t care about the intermediate steps.” The queries the resolver makes to the root, TLD and authoritative servers are iterative: each one means “if you don’t know it, tell me who to ask next.”

This is the same relationship as the caller and the operator. You made one request and waited; the party doing the running around was the operator.

The practical upshot is a security matter that will come up in a later section. Serving recursion is expensive work and isn’t left open to everyone. A resolver that’s open to the internet and accepts anyone’s query (an open resolver) lets the organisation’s own bandwidth be used in other people’s attacks. An organisation’s internal DNS server should serve recursion only to its own network.

Who Owns the Domain, Where Are the Records? Registrar, Nameserver and Zone

The party that sells the domain name and the party that holds its records can be different, and in practice they usually are. If this were the only thing you learned in this article, it would still be worth it: most of the DNS confusion in the field starts here.

The Registrar Sells the Name and Doesn’t Have to Manage DNS

The registrar is the party that allocates the domain name on your behalf and records that allocation with the relevant registry. On the .com side that authority is a global registry. The registrar’s core job is exactly this: recording that the name belongs to you.

Managing the DNS records is a separate service. Registrars usually offer it as a free extra, but it isn’t mandatory, and most organisations delegate it elsewhere: to a hosting platform, a CDN provider, or their own server.

Think of it like your number and your phone company. The company that assigned you the number is known. But which directory your number appears in, and with what details, is a separate decision, and a completely different place may hold that record.

The most expensive thing to neglect on the registrar side isn’t technical, it’s calendar-based: a domain name is not property, it’s a timed allocation. When it expires, the site and mail stop at the same moment, because the name can no longer resolve. Most extensions then give a grace period of about a month, after which a redemption period begins, and recovering the name at that stage costs many times the normal renewal fee. Finally the name is released and someone else can take it.

The corporate answer to this is a two-line precaution, and neither line is technical. Keep auto-renew on, but don’t trust it: the thing that usually stops a renewal is an expired credit card. Second, make the contact address at the registrar a corporate, permanent address. Renewal warnings sent to a departed employee’s personal address tie the organisation’s domain to a mailbox nobody reads.

Nameserver Delegation: Which Directory Holds Your Records?

Which servers hold a domain’s records is set by the nameserver information, and that information lives in the registrar’s panel. The moment you change the nameservers, the place that manages all of that domain’s records changes too. This is called delegation: you’ve handed authority over the zone to a set of servers.

The most common confusion in the field is right here. You bought the domain from a registrar, then entered the nameservers your hosting platform gave you. Now the record list you see in the registrar’s DNS Management panel is not the list actually in use. You change an A record there, save it, and nothing happens. The panel works, the record was written; it’s just that nobody in the world is asking that server.

The directory equivalent is identical. If your number’s record is now kept in a different directory, nobody sees the correction you made to the card in the old one. The card was filled in correctly, but nobody is looking where that card is any more.

When you move to a hosting platform the way records are written changes a little too. For the root domain (that is, for sercebilisim.com) you write an A record the platform gives you; for subdomains like www you use a CNAME. Why the two differ is the subject of the next section, and it has a technical reason.

A Domain Transfer Is Not the Same as a Nameserver Change

These two operations are constantly used interchangeably, and a large share of outages come from that confusion. A transfer changes the domain’s registrar: billing, renewal and the ownership record move to the new party. A nameserver change changes where the domain’s records are held. One is ownership, the other is content.

Think of number portability. When you change carriers your number stays the same and people calling you notice nothing. The only things that change are who bills you and who runs the line. Nobody touched your directory record.

The practical result: a transfer itself causes no outage, a nameserver change does. The cause of outages during a transfer is almost always the same: the nameservers are switched on the same day and the zone was set up incompletely on the new side. The most-often-forgotten records are MX and TXT, that is, mail flow and verification. The site keeps opening, mail quietly stops, and it goes unnoticed for a few hours.

The right order is simple and separates the two steps:

1. Build the zone on the new side exactly: read every record from the current nameserver and enter it in the new panel, skipping none as “not needed.”
2. Verify by asking the new server directly: check every critical record one by one with Resolve-DnsName sercebilisim.com -Server new-ns.example.com.
3. Only then switch the nameservers. And don’t delete the zone at the old provider for at least a week.

There are a few rules to know on the transfer side itself. The domain is unlocked, an authorization code (EPP or Auth Code) is obtained from the registrar, and the new party starts the request with that code. Most extensions run two separate 60-day locks: a newly registered domain can’t be transferred for the first 60 days, and a transferred domain can’t be transferred again for the next 60. So the “let’s buy the name, then move it to where we’ll really use it” plan won’t work for the first two months. That’s why a transfer isn’t scheduled onto an outage window or a campaign period.

DNS Record Types: A, AAAA, CNAME, MX, TXT, NS and SRV

DNS record types hold the answers to different questions under the same name. A domain name doesn’t point at one thing: web traffic goes one place, mail another, the verification info somewhere else entirely, and they all sit inside the same zone.

The record card in the directory wasn’t one line either. Under the same name, home phone, work phone, fax and address were written separately. Whichever one you asked for, that’s what you got.

A and AAAA: The Address Behind the Name

An A record binds a name to an IPv4 address, an AAAA record to an IPv6 address, and it’s the most basic DNS record. It’s the minimum record a site needs to open.

Two subtleties. First, more than one A record can be defined for the same name, and the order in the answer can change on each query; both the authoritative server and the resolver in between do this. This gives a primitive load distribution but does no health check. As long as a shut-down server’s address stays in the list, some visitors keep going there. Second, adding an AAAA record opens the IPv6 side, and if that address isn’t actually serving, IPv6-preferring clients can’t open the site. A half-finished IPv6 migration produces more faults than one never started.

CNAME and the Root-Domain Limit

A CNAME record binds one name to another name; it holds no address, it defines an alias. When you write a CNAME for www.sercebilisim.com, the query is handed off to the target it points at, and the address is read from there. That’s why hosting platforms want a CNAME for subdomains: the platform can change its own address whenever it wants, without touching your record.

There’s a hard limit the standard imposes here, and everyone hits it in practice: you can’t put a CNAME on the root domain. The reason is technical and clear. A CNAME record requires that no other record exist under the same name. But the root domain necessarily holds SOA and NS records, and in most organisations MX and TXT are there too. Putting a CNAME on the root shadows those records; the most visible result is that mail flow stops.

Providers get around this limit two ways. Either they give a plain A record for the root, or they offer a provider-specific record type called ALIAS or ANAME; this record looks like an A to the outside and follows the target behind the scenes. Because it isn’t a standard record type, it isn’t available at every provider.

MX: Which Server Accepts the Mail?

An MX record says which server will accept mail sent to that domain, and it carries a priority number alongside. The smaller the number, the higher the priority: a server with value 10 is tried before one with 20. If several servers share the same priority, load is spread among them.

The most common corporate setup is this: the site sits on a hosting platform, the mail is at a cloud provider. So the A record points one place and the MX record another, and the two live side by side in the same zone. This isn’t a contradiction, it’s the normal setup.

In the panel the process goes like this. Your cloud provider gives you an MX list; each line has a server name and a priority value. In your DNS panel you create a separate record for each line, choose MX as the type, leave the name field empty for the root domain, put the server name in the target, and the provider’s number in the priority field.

How many lines you enter depends on the provider and the age of the setup, so don’t blindly follow an old guide you found online. Google Workspace is the best example: accounts opened before April 2023 wanted five separate records with different priorities, and for accounts opened after that date a single record (smtp.google.com, priority 1) does the same job. Redundancy and load distribution are now handled behind that one name. The old five-record setup keeps working, so seeing five lines in an existing zone isn’t an error. Look at the provider’s current documentation and enter as many lines as it gives you; entering half and stopping doesn’t complete the setup.

The most common mistake is here: adding the new MX records without deleting the old provider’s. When two sets of MX records sit side by side, some mail lands in an old mailbox nobody watches. The lost-mail complaint arrives days later, and while the cause is being hunted nobody thinks of DNS.

Like the home phone on the record card being changed but the old one not deleted. Some callers are still trying the old one, and there’s nobody to tell you they can’t reach you.

The rule that follows: keeping two addresses side by side on an A record gives a primitive load distribution, but the same thing on the MX side means splitting the mail. So when changing mail providers, change the old and new records in the same operation; if the panel allows bulk editing, save the list in one go.

Never say “let me delete them all first, then enter the new ones,” because having no MX record is more dangerous than having the wrong one. When a domain has no MX record the sending server doesn’t discard the mail: by the standard it falls back to the A record and tries to deliver the mail directly to your web server. With no mail service there, the messages are either rejected or lost. Those few minutes with no record can cost more than the hours with two sets side by side.

TXT: SPF, DKIM and DMARC

A TXT record holds free text, and today its main job is proving mail identity. Three records work together, and all three sit in your zone.

SPF lists who may send mail on your behalf. It’s written as a single TXT line, and there are two strict rules here: a domain may have only one SPF record, and when there are two the record is treated as invalid and the check fails. Second, the number of DNS lookups an SPF evaluation may make is limited to ten; when you chain several providers with include, that limit is silently exceeded and the record is again invalid.

DKIM puts a signature on outgoing mail and publishes the signature’s public key in a TXT record. The record sits under a selector the provider gives you.

DMARC says what to do based on the first two: do nothing, quarantine, or reject. It’s held under the _dmarc subdomain and you can define a report address.

The practical diagnosis that follows: if your outgoing mail lands in spam on the other side, the problem is usually not in the mail server but in your DNS zone. Before poking at the mail server, read these three records; reversing that order is one of the most time-wasting habits.

SRV: The Corporate Network’s Own Record

An SRV record says which server and which port a service runs on; what sets it apart from an A record is that it also carries the port and priority. On the internet side you meet it in SIP and VoIP setups. On the corporate side it’s the backbone of Active Directory.

When a domain-joined computer starts, it doesn’t know which Domain Controller to contact. It makes an SRV query like _ldap._tcp.dc._msdcs.ad.sercebilisim.com and learns a suitable Domain Controller. These records are created in internal DNS; they have no counterpart on an external DNS server.

And the result comes back to what we said at the start: when the client’s primary DNS is set to an external address, the internet works fine, pages open, and domain sign-in fails. This is exactly the most-often-misdiagnosed fault in the field, because the symptom the user describes and the layer the fault sits in never point at each other.

CAA: Who May Issue the Certificate?

A CAA record specifies which certificate authority may issue a certificate for a domain, and today nearly every authority is required to check this record before producing a certificate. Its purpose is to prevent maliciously or mistakenly issued certificates.

A domain with no CAA record has no restriction, so anyone may issue a certificate; that’s why the absence of CAA produces no fault. The fault appears in the opposite case, and it’s hard to diagnose: there is a CAA record in the zone, only your old provider’s authority is listed, and your new platform can’t issue the certificate. The symptom is “the site went live but HTTPS just won’t come up,” and the error talks about the certificate, not DNS.

Because hosting platforms issue certificates automatically, put this check on your setup list: if you’re moving to a new platform, read your CAA record, and if there’s a restriction, add the new authority to the list.

When You Write a Record: The Name Field, the Root Domain and the Trailing Dot

Knowing the record type isn’t enough; you also have to know what the panel wants from you, and the same record being written differently at different providers is the most annoying part of this work. Three fields are constantly confused.

The name field. Here you write not the whole domain but only the prefix. The value for www.sercebilisim.com is www. For the root domain itself the field is either left empty or filled with @; the two mean the same thing, and which one it wants depends on the provider. Writing the full domain here is the most common mistake, and it produces a record like www.sercebilisim.com.sercebilisim.com. The panel gives no error, the record is saved, and it does nothing.

The trailing dot. In zone-file logic a name ending in a dot is taken as absolute, while a name that doesn’t end in one has the zone name appended. Most modern panels handle this for you, but some expect the trailing dot in the target field. If CNAME and MX targets don’t work as expected, this is one of the first places to look.

The TTL field. Every record has its own TTL value, usually entered in seconds in the panel. The default that comes in is on the order of hours at most providers; what it means and when to change it is the subject of the next section.

After writing a record, don’t close the panel and call it done. Verify every critical record by asking the authoritative server directly; we show how in one command in the diagnosis section. Seeing the record in the panel is not proof that the world reads it.

Annotate the Record: A Year Later Nobody Remembers

The most-often-left-blank field in a DNS record isn’t the value, it’s the comment field next to it. On Vercel every record has a Comment field, and Cloudflare has the same. Neither affects resolution in any way, and that’s exactly why it gets skipped.

The cost lands on the next person. When you open the zone a year later, in front of you sit a few TXT records: one is the ownership verification of a service still in use, one is the residue of a tool tried and dropped two years ago, one is something nobody remembers. Nobody knows which can be deleted. The result is bad either way. Either nothing is touched and the zone bloats over the years, or someone does a cleanup and drops a working verification. The bill for the second usually arrives as mail landing in spam, and nobody connects it to the DNS cleanup two weeks earlier.

I have an observation about why this goes wrong so often, and it has nothing to do with blaming anyone. I’ve seen plenty of people who call themselves mid or senior hesitate over a simple TXT or MX edit. The reason isn’t ignorance, and it isn’t one thing: two things stack up.

First, the way we learn. In the field most of us skip the theory and learn straight from practice. You log into the panel, fill the box shown, the job’s done, and this method works fine in familiar situations. But when the chain isn’t built in your head, the first surprise leaves you nothing to hold on to. Someone who wrote the record and saw nothing change doesn’t know where to look, not out of incompetence, but because they’ve had to build a map on their own that nobody ever drew for them.

Second, contact frequency. A system administrator touches dozens of group policies a week but goes into the DNS zone a few times a year. A task that’s done rarely, slow to undo, and stops the whole organisation’s mail when done wrong naturally breeds unease. Add “what was this record” ignorance on top and nobody wants to touch it, and the work drags.

The fix isn’t training, it’s record-keeping. Write three things on every record: what it does, who requested it, and the date. A one-line note like Google Workspace domain verification, 2026-03, HR request lets you decide in seconds a year later whether that record can be deleted. If your panel has no comment field, document the zone elsewhere; where you keep it doesn’t matter, that you keep it does.

Back to the record card: a card where it’s unclear who wrote it and why is one nobody dares to change even when it carries the right number. Most of the records that never get deleted in organisations stay not because they’re wrong, but because their owner is unknown.

TTL and Caching: Why a DNS Change Doesn’t Show Up at Once

A DNS change is made instantly but doesn’t appear instantly. What sets the wait isn’t the server’s speed, it’s how many places the old answer is stored. The name of that duration is TTL (Time To Live), and every record has its own TTL value.

The same thing happened when you saved a number from the directory into your phone. Even if the person changed their number, the copy in your book stayed; you dialled the old one and only learned it was wrong when someone told you.

Caching Sits in Three Layers

A DNS answer is stored not in one place but in three stacked layers, and for a change to appear all three have to refresh.

The browser. Modern browsers have their own DNS cache, working independently of the operating system. Clearing the OS cache and still getting the old answer is usually because of this.

The operating system. On Windows the DNS Client service holds answers. You see the contents with ipconfig /displaydns and clear it with ipconfig /flushdns or Clear-DnsClientCache. In the same layer sits the hosts file, but that isn’t a cache and belongs in a separate place in diagnosis; we cover it shortly.

The recursive resolver. This is the layer that really decides, and it isn’t yours. It might be the organisation’s internal DNS server, the ISP’s server, or a public resolver. You clear your own two layers in a second; this third one keeps giving the old answer until the TTL expires, and you can’t touch it.

The organisation running its own internal DNS server brings a side benefit: because every name query passes through it, the server can also keep a record of which services are being reached in the organisation, which is useful for auditing.

There’s a direct consequence, seen constantly in the field: “it opens for me, not for you” isn’t a quirk, it’s cache behaving normally. If two users are behind different resolvers, getting different answers is the expected state.

“Propagation” Isn’t Spreading, It’s Caches Emptying

The term propagation, used for DNS changes spreading, actually paints the wrong picture. There’s no update spreading across the world. The moment the record on the authoritative server changes, the new answer is ready; it’s just that every resolver holding the old answer in its cache won’t ask again until its own TTL expires.

So what you’re waiting for isn’t a spread, it’s a timeout. If the TTL is 300 seconds it takes five minutes, if 86400 up to a day. The “it takes 24-48 hours” line has this behind it: high-TTL records and some slow-behaving resolvers.

There’s another layer, little known but very useful in diagnosis: negative cache. When a name is queried, the “no such record” answer is cached too, and its duration is set by the minimum value in the zone’s SOA record. The practical upshot: if you query a name before adding a record, the negative answer you get is cached, and after you add the record you keep getting “not found” for a while. The record is right, the panel is right; what you’re waiting on is the negative-cache duration. An admin who doesn’t know this deletes and rewrites the same record three times.

Lowering the TTL Before a Migration

The way to make a server or provider migration seamless is in the preparation, not the migration itself: lower the TTL of the records to be moved 24-48 hours before the migration. Pulling the value down to 300 seconds is enough.

The logic is simple. Even if you lower the TTL today, resolvers won’t learn it until the TTL of the old record they hold expires. So the lowering itself also waits out the old TTL. For the short TTL to be in effect on migration day, you have to spend that wait beforehand.

After the migration is complete and everything has settled, raise the TTL back to its old value. A permanently low TTL isn’t free: every query goes to the authoritative server more often, resolution latency rises, and when your authoritative server has a brief outage many more visitors feel it.

Corporate DNS: Who Answers the Query?

On a corporate network the real question isn’t what DNS is, it’s who answers the query. The same device, for the same name, can get different answers depending on where it asks, and nearly all corporate DNS faults hide inside that sentence.

Internal DNS, the ISP’s Server, and a Public Resolver

The DNS server a client uses usually comes to it via DHCP; it’s one of the four pieces handed out with the address. Which address goes here depends on the organisation’s structure, and there are three options.

In a domain environment the answer is beyond debate: the internal Domain Controller. The client finds the Domain Controller from SRV records, and those records live only in internal DNS. Writing an external address here ends domain sign-in. Resolving the outside world is the internal DNS server’s problem, not the client’s; it forwards queries it doesn’t know to an upstream source. The name of that forwarding setting is forwarder, and its configuration is covered in the Active Directory DNS guide.

In a small non-domain setup the ISP’s resolver or a public resolver like 1.1.1.1 or 8.8.8.8 is enough. The difference between them is less about speed than about filtering: the ISP’s server applies your country’s access decisions, some public resolvers don’t, and some apply their own malware filter. So there’s no such thing as an “unfiltered” resolver; which filter applies is what changes.

When the organisation runs its own resolver there’s one rule: that server should serve recursion only to its own network. A resolver left open to the internet lets the organisation’s bandwidth be used in attacks aimed at others.

Where local resolution records are held isn’t only a technical matter, either. Because every query passes through the internal resolver, it can keep a record of which services devices reach, which is what an audit of internal name resolution rests on.

What Changes If Your Own Server Is Inside?

If you host a server that serves the outside world on your own network, the same name needs two different answers. A user coming from the internet should get the server’s public IP; a user asking the same name from the office should get the server’s internal IP, because the server is right next to them.

When an internal user is given the public address, the packet leaves the network, goes all the way to the firewall, and comes back in. This is called hairpin NAT. Some devices don’t support it at all and the connection drops; on ones that do, traffic passes needlessly through the edge device.

The same name being answered differently inside and outside is called split-brain DNS. Its design on a corporate network, its step-by-step configuration and its maintenance cost (the internal zone must be updated on every public record change) are a separate subject: you can go straight to the split-brain section of the Active Directory DNS guide. The forwarder configuration above is in the same guide.

What to take from here is the mechanism itself: a name isn’t doomed to a single answer. It can change depending on who asks, and on corporate networks it usually does.

From the Field: Opens Outside, Won’t Open Inside

The classic shape of this fault is a site that opens from home and won’t open on the corporate network. I’ve told one such case in full, a purchasing portal and an internal A record left behind for years, in the Active Directory DNS guide; here only its two lessons matter.

First, “nothing changed on our side” proves nothing in DNS. A stale record sits silently for years and turns into a fault the day the other side changes its address. Second, the fastest move on this kind of complaint isn’t to dive into server logs, it’s to ask the question of someone else. Ask the same name from a different network, a different resolver. If the answers diverge, you learn which side the fault is on in a minute; if they don’t, you drop DNS from the list and move to another layer.

The Diagnosis Order for a DNS Fault

When solving a DNS fault there are three questions, and the order matters: does the name resolve, who gave the answer, is that answer correct? The tool for all three is the same, and the second question is the most-skipped. When you get a wrong number you first establish not the number but who you asked; the operator and your own notebook don’t have to give the same answer.

Three Questions, Three Commands

On Windows Resolve-DnsName gives a more reliable result than nslookup; nslookup appends the machine’s domain suffix to the query, which can return unexpected names in some environments.

# 1. Which address the name resolves to
Resolve-DnsName sercebilisim.com

# 2. Who holds this domain's records (ends the wrong-panel hunt)
Resolve-DnsName sercebilisim.com -Type NS

# 3. Ask the authoritative server DIRECTLY, skip every cache in between
Resolve-DnsName sercebilisim.com -Server ns1.example-provider.com

# 4. Are the mail and verification records in place
Resolve-DnsName sercebilisim.com -Type MX
Resolve-DnsName sercebilisim.com -Type TXT

# 5. Read and clear the client cache
Get-DnsClientCache
Clear-DnsClientCache

On the command line nslookup, and dig on Linux and macOS, do the same job:

dig sercebilisim.com
dig sercebilisim.com NS
dig @ns1.example-provider.com sercebilisim.com
dig sercebilisim.com MX +short

In dig output you look at three places, and the three answer different questions. ANSWER SECTION shows the record you asked for. The ;; SERVER: line at the very bottom says which server the question was asked of; when discussing an answer you read this line first, because the same query can give different answers on different servers. If you see aa in the flag list at the top, the answer came from the authoritative server; if not, it came from a resolver in between. AUTHORITY SECTION lists not who answered you but the zone’s authoritative servers; the two are often confused.

On the nslookup side the same information is given by the Non-authoritative answer label: the answer didn’t come from the authoritative server but from a resolver in between, and that resolver may be handing you an old value from its cache. The only way to know a record is really updated is to ask the authoritative server directly.

The last point is worth showing with a real measurement, because on a corporate network the server that answers isn’t always the one you named. Preparing this article I asked for the lab domain controller’s own name from a workstation, naming the server explicitly. Over the default transport the answer was 216.150.16.129: our own public website’s address, which the public zone returns for any name under the domain because it has a wildcard record. Forced onto TCP, the same question reached the domain controller and came back with its real address:

# Default (UDP): came back with 216.150.16.129, the public site's address
Resolve-DnsName dc01.ad.sercebilisim.com -Server 192.168.1.10

# Forced onto TCP: reached dc01 and returned 192.168.1.10
Resolve-DnsName dc01.ad.sercebilisim.com -Server 192.168.1.10 -TcpOnly

With query logging on, the UDP queries never appeared in the domain controller’s log; the TCP one did. So something on the local network was answering UDP port 53 before the query reached the server named in the command, and it answered from the public zone. The lesson isn’t that particular setup, it’s how you read the result: a command returned an answer, the answer looked plausible, and it didn’t come from the server I asked. When an internal name resolves to a public address, “an answer came back” isn’t success; check that the address is in the range you expect, and ask over TCP as well. (One aside worth noting: the DC’s DNS debug log is buffered, so the lines lagged the live query by around twenty seconds; don’t conclude “nothing was logged” from a log that simply hasn’t flushed yet.)

The hosts File: Answering Without Ever Asking DNS

A name can be answered without DNS being asked at all. Before the operating system starts resolving it looks at the local hosts file, and if it finds a match there it skips the whole chain: root, TLD, authoritative server, cache, none of it engages.

It’s worth stressing that this isn’t a cache, because the two are constantly confused. A cached record came from somewhere and drops on its own when its TTL expires. A line in the hosts file came from nobody, has no duration, and stays until you delete it.

The file is at C:\Windows\System32\drivers\etc\hosts on Windows and /etc/hosts on Linux and macOS, and it has no extension. The classic trap is exactly that: open it with Notepad and save, and the file is quietly written as hosts.txt. Nothing reads the new file, the old one stays as it was, and the change you thought you made never existed. When saving, put the filename in quotes, or open the editor as administrator and overwrite in place.

The distinction that helps in diagnosis: nslookup doesn’t read this file. It sends the query straight to the DNS server. The browser, ping and Resolve-DnsName in its default form do read it. So “nslookup shows the right address but the browser goes somewhere else entirely” usually has a hand-written hosts line underneath.

# Normal path: includes the hosts file and client cache
Resolve-DnsName sercebilisim.com -Type A

# DNS only: skip the hosts file and cache
Resolve-DnsName sercebilisim.com -Type A -DnsOnly -NoHostsFile

In the field these lines are almost always written with good intent: for a test during a migration, as a temporary fix while a server is moved. Then nobody deletes them. A temporary hosts entry that’s become permanent quietly cuts that machine off from the rest of the network; the fault is found months later, while a completely different cause is being hunted.

From Symptom to Cause

The last two rows are where this table saves the most time. The second-to-last rests on the distinction at the start of the article: DNS makes no connection, it only answers. If the name resolves to the right address, DNS has done its job and you have to move the hunt to another layer. The last is the subject of the next section.

DNS Security: Cache Poisoning, DNSSEC and Encrypted DNS

DNS is one of the internet’s oldest protocols and was designed without authentication in mind. That the answer to your question really came from the authoritative server is something the protocol itself doesn’t prove. Every addition on the security side came to close that one gap.

Cache Poisoning and DNSSEC

Cache poisoning is placing a fake answer into a resolver’s cache. If an attacker gets ahead of the real answer and gives a made-up address, the resolver stores it and hands the same wrong address to everyone who asks for the length of the TTL. The user types the right name, sees the right name in the browser, and connects to a completely different server.

Like a fake directory. The name is right, the place you asked looks trustworthy, and the number you’re given belongs to someone else.

There are two defences on the protocol side. First, resolvers making the query hard to predict: using a random source port and a random query ID raised the cost of the attack considerably. Second, DNSSEC: it signs the records to prove the answer came from the authoritative server and wasn’t altered in transit. A common misunderstanding to correct here: DNSSEC doesn’t encrypt, it signs. It doesn’t hide your queries; it only verifies the answer isn’t forged. Support depends on both the extension and the registrar, and once enabled it has to be maintained together with the signing information on the registrar side.

Open Resolver: Your Own Server Becoming an Accomplice

Leaving an internal DNS resolver open to the internet turns that server into a tool for attacks aimed at others. The mechanism is simple, which is why it’s common: the attacker sends a query to your server but writes the target’s address as the source. You produce the answer and send it to the target. Because a small query gets a much larger answer back, the traffic the attacker sends grows on the way; this is called amplification.

The result is two-sided harm. The target is flooded with traffic coming from your server. You, without even noticing, spend your line, your server and your reputation; when the incident is investigated, the address the traffic came from belongs to your organisation.

Think of it through the two query types we separated earlier. Your server should keep giving authoritative answers for its own zone, because the outside world asking for those records is normal. What it should not give is recursive service: going off to find and fetch an answer for a name it doesn’t know is a service to be offered only to its own users. In the directory analogy: you show your record cards to those who ask, but you don’t go searching other directories to collect a number on behalf of a stranger.

The practical version is a one-line check: is port 53 of your internal DNS server reachable from the internet? If yes, restrict recursion to internal network ranges only.

DoH and DoT: A Privacy Gain, a Corporate Cost

Encrypted DNS stops the query being read in transit, and it has two forms. DoT (DNS over TLS) uses port 853; encrypted though it is, using a separate port makes it visible on the network and blockable when needed. DoH (DNS over HTTPS) buries the query inside ordinary web traffic on port 443; from the network’s view it’s indistinguishable from an ordinary HTTPS connection.

For the end user this is a gain. For a corporate network it means three separate problems, and all three appear at once. DNS-based filtering is disabled, because the browser goes to its own provider without ever asking the organisation’s server. Internal names can’t resolve, because an external resolver knows no zone called ad.sercebilisim.com; the symptom is “some internal apps won’t open in the browser, everything else works.” Resolution records come up short, because a query that never passes through the organisation’s server is written nowhere.

The right intervention is on the device, not the network. Manage the browser by policy: turn the encrypted-DNS feature off on corporate devices. On the Firefox side there’s an extra mechanism: if your internal DNS server returns “no such record” for use-application-dns.net, Firefox disables its own encrypted DNS. Trying to solve it by closing a port only works on the DoT side; you can’t block DoH without closing port 443, and you can’t close that port.

Conclusion: Knowing Who Gave the Answer

In this article we walked the chain of a DNS query from the root down to the authoritative server, why the party selling the name and the party holding the records differ, what each record type carries, why a change doesn’t show up at once, and which command to reach for when something breaks. The one sentence to keep: in DNS the real question isn’t what the answer is, it’s who gave it.

Seeing the right record in the panel doesn’t mean the world reads it. An answer looking right doesn’t mean it came from the authoritative server. Something working for you doesn’t mean it works at the next desk. The answer to all three is in one place: who did you ask, and where did they look?

That’s also the real thing to say at the end of a “what is” article. In the field most of us skip the theory and learn by practice, and that works for a long time; logging into the panel and filling the box shown gets the daily job done. But that method only works in familiar situations. When you wrote the record and nothing changed, when mail isn’t reaching some recipients, or when the site opens outside and won’t open inside, what carries you forward isn’t panel knowledge, it’s the chain in your head.