ZNetLab › Published › Blog post
"It is a DNS problem" usually is not
Four things wear the DNS costume. Two commands tell them apart in under a minute.
"It must be DNS" is the networking equivalent of "have you tried turning it off and on again". Sometimes it is. Usually it is one of four things wearing DNS's clothes, and you can tell them apart faster than you can argue about it.
Ping the IP. If the address works and the name does not, you have a name resolution problem and the rest of this is relevant. If the address does not work either, stop talking about DNS — you have a routing or filtering problem and the name is a distraction.
`nslookup` the name against the configured server, then against a known one. If the first fails and the second works, the configured server is the fault. If both fail, the record is the fault. If both work and the application still cannot connect, DNS was never involved.
The two that catch people: a search domain that silently appends
something, so server1 resolves and server1.corp.example does not; and a
cached negative answer, which is why it starts working ten minutes later
and nobody learns anything.
The DNS and HTTP lab in the simulator is useful here precisely because it is small — one server, one client, one router. Break the record, break the server address, and break the route, and watch how similar the three look from the client and how different they look one command in.
Join the discussion
Replies, likes and bookmarks live in the community half, which needs a free account. Writing here is free too, and everything is reviewed before it is published.
Open this in the communityEverything publishedHow this works