What does DNS resolution mean? After typing the URL, press Enter to open the webpage. I ran the steps in the middle using nslookup

last month, I changed the router's DNS to 223.5.5.5. The final step of the tutorial asked me to type ipconfig/flushdns. I have issued this order at least ten times, copying it every time, never thinking about what it was supposed to clarify. Last week, a colleague asked me, "Why is it that after I changed my DNS, the webpage still won't open as usual, and after five or six minutes it fixed itself?" I got stuck. To clarify this, I used nslookup to run the entire parsing process of my website and casually calculated the cache and TTL accounts.

first clarify what DNS is translating

computers only recognize IP addresses, what is IP? I wrote an article here: machines recognize numbers like 49.51.202.150, but people only remember names like www.shunot.com. DNS is all about translation—you enter a URL, it finds the corresponding IP, and the browser then uses the IP to connect to the server. It's like the 114 service desk before making a call—you state your name, and it gives your number.

before DNS existed, the internet's "address book" was a hosts file, where all domain names and IPs were written in one text and synchronized manually by downloading. This file is still lying on your computer: C:\Windows\System32\drivers\etc\hosts. When you open Notepad, you'll see a line of 127.0.0.1 localhost. The first time I encountered it was in the school's computer lab, and many things back then were accomplished by revising this line of documents. Its rules haven't changed to this day: if something is in the hosts, the system uses it directly, without asking DNS at all. So when troubleshooting DNS issues, first glance at the file to see if someone has stuffed it into a strange line—some crack software likes to write something, and after just one line, a website will permanently appear "no one to be found" on your computer.

Who exactly did

analyze in one session

your computer doesn't ask everywhere on its own; it only asks for a "recursive parser"—by default, the DNS is automatically issued by the carrier, because when DHCP sends the address, it casually sends the DNS address as well. I explained this in detail when I wrote about DHCP. My router is set to 223.5.5.5, and all DNS queries for all the devices in the house end up connected to it.

you ask it once, it must provide a final answer, which is called a recursive query. As for how it handles its own errands, you don't need to worry: first, it asks the root server, 'Who knows .com?' The root says, 'This belongs to .com server group.' It then asks .com Who knows shunot.com.com saying, "Go ask the authoritative server of this domain"; Authoritative servers finally hand over their IPs. Asking at each level, each only telling you "who to ask next," is called iterative querying. There are 13 global root servers, each top-level domain has a batch of servers, and each domain has its own authoritative DNS attached. After three layers, it usually takes only a few tens of milliseconds to finish.

the terms recursion and iteration sound awkward the first time. Let me put it in your hand: recursion means you only ask once as a shopkeeper, while iteration is the parser's level one errand asking for directions. When dealing with recursive parsers, you only have a Q&A session; all the errands and work are on its end. Here's another fun fact: this Q&A uses UDP port 53, and the round trip takes only a few dozen minutes. Most of the time, DNS uses UDP instead of TCP, because packets are small, Q&A, and three handshakes are wasteful. For video conferencing and gaming, where reliable transmission is important, only use TCP. Check the house number, and if you lose it, just ask again.

verification step has ready-made commands: nslookup www.shunot.com 223.5.5.5, meaning "Don't use the default one, specify 223.5.5.5." The top two lines of the return result state which server you're asking about, and the address below is the answer. The most common way to play nslookup is to assign different servers to check and compare the answers.

answer isn't always the same: a three-layer notebook

if every webpage opens runs through the root, top-level domain, and authority layers, no matter how fast the site is, it won't handle it. So the answer is recorded in a small notebook, with three layers: the browser has its own cache; The system has its own cache, so ipconfig/displaydns can be retrieved in the entirety, listing domain names and IPs one by one; At the outermost point, the 223.5.5.5 recursive parser held the largest notebook, shared by everyone who had asked.

Each record is accompanied by a TTL (Time To Live) in seconds, which is the domain owner's "freshness period" set in their DNS backend. I tested my website's TTL of 120 seconds—answers are cached for at most two minutes, and when the countdown hits zero, you have to ask the authorities again. Staring at this number is especially interesting: I checked twice. The first time it returned a TTL of 95, and after ten seconds, it returned 120. 95 means the cache has 95 seconds left; Ten seconds later, the old account expired. The parser asked the authorities again and got back a fully powered 120. A single tick of a number reveals both "cache" and "countdown" clearly.

searching www.qq.com different servers is more interesting: 223.5.5.5 gives me TTL 44, 119.29.29.29 gives 86, 8.8.8.8.8 gives 120. For the same domain, the countdown times of the three parsers are different—because each of them copied the answer into their notebook at different moments, and what you find is always "How many seconds are left on my file?" Once, a colleague used two tools to check the mismatched times, thinking their DNS was broken, but it was just that each company's cache was different in old and new levels—everything was working normally.

a common phenomenon: after clearing the cache, the first webpage opens a text half a beat slower than usual, but the second time is faster. This isn't an illusion—the local laptop is empty, and this time I really have to go to the parser layer to get the answers; Take it back and make a note—the last few hits are all true hits in the book. I want to see with my own eyes how many pages my computer has recorded. Typing ipconfig /displaydns, my old laptop can't flip through all the pages in one screen, full of the names of websites I've visited these past few days and the seconds left on them, like a drawer full of expired sticky notes.

Why doesn't changing DNS take effect immediately

back to the colleague's question: after changing the DNS, it took five or six minutes for the problem to work, because the cache was stuck. Changing DNS only means changing "who will be asked in the future," unclear about "already remembered answers." Each of the three layers has its own fate:

• system layer is the easiest to handle; ipconfig/flushdns clears everything with a single tap. That's why the tutorial tells you to type it;
• browser is the most stubborn. The new Chrome has even closed the cache clearing entry point, and the easiest way is to exit and reopen the entire cache;
• the parser layer is out of reach; the old answers stored in the 223.5.5.5 laptop can only wait for its own TTL to reset — this is the whole truth of "wait a few minutes and fix it on its own."

After the change, if you want to confirm it's not effective, don't just stare at the webpage and wait around. Still type nslookup: nslookup www.shunot.com (no second parameter), and see who the top two lines of "Server" are displaying. If it shows as your new address, it means the system layer has been replaced; The old address still shows up, most likely because the network card hasn't been reconfigured and just disconnected and reconnected to WiFi once more. The time I did it remotely for a colleague, he got stuck here—DNS changed, but the computer was still asking for old servers with old configurations.

another easily missed feature: apps like WeChat and QQ don't go through the system's cache and keep separate records. Sometimes when the webpage is fully finished, it just spins around; restarting the app is more effective than anything else. By the way, a classic symptom—WeChat can send messages but web pages won't open, 80% likely DNS issues: WeChat remembers its server address and doesn't rely on check-up; The web page is searched on the spot; only when you can't find it do you circle around. How to distinguish packet loss from DNS—I've written in one sentence: ping public IPs works, ping domain names doesn't work, and DNS is the fault.

two computers find different IPs, it's not hijacking

I ran into something while checking www.qq.com: 223.5.5.5 returned two IPs (121.14.77.221 and 121.14.77.201), and 119.29.29.29 also returned these two IPs, but in reverse order. This isn't about someone being hijacked; it's the big site's CDN strategy—multiple servers are attached to a single domain name, DNS sorts by 'who's closest to you,' and devices usually use it first. It's perfectly normal for your home and mine to find different IPs on the same video website, so don't rush to call the police.

real hijacking looks different: the detected IPs can't be opened at all, or you enter only with ad pages. Verification still relies on nslookup, requiring both 8.8.8.8 and carrier to check; only when the answers are ridiculously different is there suspicion. Behind this is the old topic of "carriers rushing to answer UDP port 53"—you clearly asked about 8.8.8.8, but the carrier answered halfway through, I fell into a complete pitfall in the article about changing DNS for the optical modem. Also, if your router's DNS is changed back every few days, you should first suspect the device has been tampered with. the self-check has a checklist.

which symptoms should you suspect DNS, follow this order

the order of closure is set for you: if the webpage won't open, ping the gateway first, then the public IP to distinguish whether it's a disconnection or DNS issues; nslookup specifies 223.5.5.5 to check again; if it works, flush DNS clears the local cache; if not, change DNS in the router's backend, my Xiaomi device is in 31.1; If that doesn't work, check the level of the light modem. By the way, IPv6 also has its own DNS query system, which checks AAAA records. The on v6 addresses described how both coexist. After this setup, you can basically level the DNS pitfalls yourself.