nslookup Says Server Unknown: It Is Only a Label

Connect the VPN, run nslookup, and the header shows the resolver's address with the name field filled in as Unknown. That word sits above the answer, and most people stop reading before the part that matters. The label describes whether the resolver has a reverse name of its own; it says nothing yet about whether the hostname you asked for resolved. Closing that window early is the whole skill here.

Two different queries can produce that display, and only one of them is about your problem. Separating them takes one extra command and saves an afternoon of editing DNS settings that were never wrong.

What the tool does before it answers you

nslookup may try to find a name for the server address it is about to use, which is a reverse lookup in the in-addr.arpa or ip6.arpa domain. If that PTR record is missing, filtered by policy, or simply not published, the tool prints Unknown and moves on. Forward resolution is untouched by that failure, because it is a different question sent to the same server.

This is why a private resolver can answer every corporate name correctly and still appear anonymous in the tool's header. The address is known; the name behind it is not, and the tool is honest about that while remaining slightly theatrical about the word it chooses.

Run the two queries deliberately

Ask about a host you care about, then ask about the resolver's own address. The first request carries the name you need; the second asks the server whether it can name itself. Written out, they look like this: nslookup app.corp.example 10.77.0.53 for the host, and nslookup 10.77.0.53 10.77.0.53 for the reverse name of the resolver.

Both examples are illustrative, so substitute your own names and addresses. The point is not the exact syntax but the separation: the two commands ask different questions and are allowed to produce different results without either one being a malfunction.

Three outcomes that look similar and are not

A timeout means no answer arrived at all, which points at reachability, filtering or the wrong server address. A negative answer means the server replied and said the name does not exist, which points at the zone or the suffix. A missing reverse name means the server answered the second question with nothing useful, and the forward answer may still have been perfect. Three results, three owners, and only one of them is about the hostname you needed.

Only the first two describe a DNS path that is failing for your application. The third describes a record that was never published, and treating it as a fault leads to changes that cannot fix it, such as rewriting the search suffix until the header looks friendlier.

Read the sections, not the header

Below the header, the tool prints the answer, the authority and any additional records. A correct address in the answer section is the result you wanted, even when the header name is Unknown. An empty answer with an authoritative denial is a different outcome and deserves its own investigation.

Keep both objects explicit in anything you send to support: which name was queried, and which server was asked. Reports that mention only that DNS is broken over the VPN force the next person to reconstruct a test you have already run.

When a reverse name genuinely matters

Some services do care about PTR records: logging that resolves client addresses, mail reputation checks, or administrative tooling that displays names. If one of those is failing, publish the record or fix the zone that should hold it. That work is legitimate and separate from the question of whether the VPN forwards queries correctly.

The narrow point stands: one missing resolver label does not prove that forward resolution over the tunnel is broken, and one working forward lookup does not prove that every name in the zone resolves. Test the name you actually need, then decide what the header word is worth.