nslookup 'Non-authoritative answer' explained

What does "Non-authoritative answer" mean in nslookup?

"Non-authoritative answer" in nslookup output means the server that replied is not an authority for the name you asked about. It is a recursive resolver. It got the answer from its cache, or by asking other servers for you. This is the normal result for almost every lookup. It is not an error, and it is not a sign that someone changed the answer.

The line comes from one bit in the DNS reply. RFC 1035, the base DNS specification, defines the AA (Authoritative Answer) bit. The bit says that the responding name server is an authority for the domain name in the question. In the BIND source code for nslookup, the tool prints Non-authoritative answer: when that bit is clear. Your laptop or VPS almost never talks to the authoritative servers directly. It asks a resolver, so the bit is clear and the line appears.

If DNS terms are new to you, start with how DNS resolution works, from resolver to authoritative nameserver. The rest of this guide walks through one lookup on Ubuntu Server line by line. Then it shows how to get an authoritative answer on purpose, with nslookup and with dig.

Install nslookup and dig on Ubuntu

First check whether the tools are already there:

command -v nslookup dig

If that prints nothing, install the package. On Ubuntu 24.04 and 26.04, the package that ships /usr/bin/nslookup and /usr/bin/dig is bind9-dnsutils, described as "Clients provided with BIND 9". The older name dnsutils still exists, but it is no longer the real package. On 24.04 it is a transitional package that depends on bind9-dnsutils. On 26.04 it is only a virtual package name. Ubuntu Server's own DNS how-to still tells you to install dnsutils, so you will meet that name in many guides. Install the real package by name and the question goes away:

sudo apt update
sudo apt install -y bind9-dnsutils
dpkg -S /usr/bin/nslookup

The last command should print bind9-dnsutils: /usr/bin/nslookup. The same package also ships delv and nsupdate, among others.

Read one nslookup lookup line by line

Run a plain lookup, with no server argument:

nslookup example.com

This is illustrative output from an Ubuntu 24.04 server. The addresses are documentation examples, and yours will differ:

Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	example.com
Address: 192.0.2.10
Name:	example.com
Address: 2001:db8::10

Here is what each part means.

• Server: is the DNS server that nslookup asked. In the BIND source, this line prints the server exactly as it was given. Here it is 127.0.0.53, the local systemd-resolved stub. The next section explains why.
• Address: is the same server written as a socket address. The #53 part is the port. Port 53 is the standard DNS port.
• Non-authoritative answer: means the AA bit in the reply was clear. The stub at 127.0.0.53 is a local resolver. It does not hold the zone for example.com.
• The Name: and Address: pairs are the records. By default nslookup asks for A records (IPv4) and then AAAA records (IPv6), which is why one name can return two addresses.

If the name does not exist, you will not see the line at all. The source prints ** server can't find followed by the name and the error, for example NXDOMAIN, and it stops before it checks the AA bit. So the "Non-authoritative" line being absent does not, on its own, mean the answer is authoritative. Read the lines around it.

Why does nslookup show 127.0.0.53 and not my real resolver?

Ubuntu uses systemd-resolved. It runs a local DNS stub listener on 127.0.0.53 (and on 127.0.0.54). The file /run/systemd/resolve/stub-resolv.conf lists 127.0.0.53 as the only DNS server. When /etc/resolv.conf points at that file, programs that read /etc/resolv.conf send their queries to the stub. The stub then asks the upstream servers. nslookup and dig come from the same BIND package, and the dig manual says that when you do not name a server, dig tries the servers in /etc/resolv.conf. So the tools only see the stub, and the Server: line shows the stub.

Check what your /etc/resolv.conf really is:

ls -l /etc/resolv.conf
grep nameserver /etc/resolv.conf

On a typical Ubuntu Server install, the first command shows a symbolic link to ../run/systemd/resolve/stub-resolv.conf. The second prints nameserver 127.0.0.53. Ubuntu's DNS how-to says the same thing: the nameserver line should point at 127.0.0.53. systemd-resolved supports other modes for this file. If your nameserver line names a different address, nslookup asks that server directly, and the stub is not involved.

Find the real upstream resolver with resolvectl status

resolvectl status shows the global and per-link DNS settings currently in effect. Running resolvectl with no subcommand does the same thing. This is where you see the upstream servers behind the stub:

resolvectl status
resolvectl dns

This is illustrative output. The layout and the field names depend on the systemd version, and your values will differ:

Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (enp1s0)
    Current Scopes: DNS
Current DNS Server: 203.0.113.53
       DNS Servers: 203.0.113.53 198.51.100.53

resolvectl dns is the short form. It prints the DNS servers for each network interface.

Know the limit of this command. resolvectl status reports configuration. It does not tell you which server answered a given query, or whether a reply came from the cache. To ask one upstream server directly and skip the stub, give it as the second argument to nslookup:

nslookup example.com 203.0.113.53

Replace 203.0.113.53 with a server from your own resolvectl output. The Server: line now shows that address. You will still see Non-authoritative answer:, because that server is a resolver too.

This direct query is a useful test. If lookups through the stub fail but the direct query works, the record is fine and the problem is in the local resolver setup. This can happen with a VPN that sets its own DNS servers on its own interface, and fixing DNS over a WireGuard tunnel walks through that case.

How to get an authoritative answer with nslookup

An authoritative answer comes only from a nameserver that holds the zone. First, find those nameservers. The nslookup manual says you can put options on the command line if they come before the arguments and start with a hyphen. The type= keyword sets the record type, so this command asks for NS (name server) records:

nslookup -type=ns example.com

Illustrative output, with placeholder nameserver names:

Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
example.com	nameserver = ns1.example.net.
example.com	nameserver = ns2.example.net.

The stub answered this query too, so you will usually see the line here as well. Run it and compare with your own output. Now query one of those nameservers directly, as the second argument:

nslookup example.com ns1.example.net

Illustrative output:

Server:		ns1.example.net
Address:	198.51.100.1#53

Name:	example.com
Address: 192.0.2.10
Name:	example.com
Address: 2001:db8::10

The Non-authoritative answer: line is gone. The nameserver holds the zone, so it set the AA bit in its reply, and nslookup skipped the line. The Server: line now shows the hostname you typed, because nslookup prints the server argument as given.

One detail matters here. ns1.example.net is a hostname, so it must be resolved before the query can go out, and that lookup goes through the stub. If you suspect the stub itself, look up the nameserver's address once, then use the IP address as the second argument.

The authoritative answer may differ from the one your resolver gives. A common cause is an old record in a cache, for example right after you changed the record. A resolver keeps an answer until its TTL (time to live) runs out. You can wait for the TTL to expire, or clear the local cache: flushing the DNS cache on Ubuntu covers the systemd-resolved stub.

Does "Non-authoritative" mean the answer is wrong or tampered with?

No. The line tells you who answered. It says nothing about whether the data is correct. A resolver that fetched the record a minute ago gives you the same data the authority would give. An answer marked authoritative is not proof either. The AA bit is only a flag in the reply, so anything that can forge a reply can also set the flag. To prove that a record was not changed on the way, you need DNSSEC (DNS security extensions) validation, which is a separate topic.

Encrypted DNS is also a separate question. Private DNS and encrypted DNS transport protects the path between you and the resolver. The resolver still answers from its cache or by recursion, so its replies are still non-authoritative.

Two more header bits complete the picture. RD (Recursion Desired) is set by the client in the query and copied into the response. RA (Recursion Available) is set or cleared by the server in its response. A recursive resolver sets RA, because recursion is the service it offers.

The dig equivalents, and when dig is the better tool

dig ships in the same bind9-dnsutils package. It sets the RD bit by default, so it normally sends recursive queries. Unless you name a server, it tries the servers in /etc/resolv.conf, which on Ubuntu means the stub.

dig example.com A

Illustrative header lines from the reply:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4242
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

Read the flags: line. qr marks the message as a response. rd is the recursion bit you sent, copied back. ra means the server offers recursion. There is no aa, so this is the dig version of "Non-authoritative answer".

Now ask an authoritative nameserver directly, with recursion turned off:

dig +norecurse @ns1.example.net example.com A

Illustrative flags line:

;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

aa in the response is the AA bit. The @server part is the name or IP address of the server to query. If you give a hostname, dig resolves that name first through the stub, just as nslookup does. +norecurse clears the RD bit in the query. An authority does not need recursion to answer for its own zone. Clearing the bit also means that a server which does not hold the zone will not go and look the record up for you. If you queried the wrong server, the missing aa shows it.

Do not confuse this with the dig option +aaonly (also written +aaflag). That option sets the aa flag in the query you send. The aa you want to read is the one in the response header.

dig is the better tool when you need more than the address:

• It shows every header flag, so you can read aa and ra directly instead of a single line of text.
• The header shows the response status, such as NOERROR or NXDOMAIN. Each answer record shows its TTL, so you can watch a cached record count down between two runs.
• +short prints only the answer, which is easier to use in scripts. The default is the verbose form.
• +trace follows the delegation path from the root name servers for the name you look up. dig turns recursion off by itself when you use +trace, so each step is a direct question to the next authority.

nslookup is fine for a quick check. It is also the tool you will find on Windows, which the next section covers.

nslookup on the Windows command prompt

Windows has its own nslookup. It is a different program from the BIND one on Ubuntu, but the basic syntax matches. In non-interactive mode, the first argument is the name or IP address to look up, and the second is the DNS server. If you leave out the second argument, nslookup uses the default DNS name server. These forms appear in Microsoft's documentation:

nslookup example.com
nslookup example.com 1.1.1.1
nslookup -type=AAAA example.com

To find the authoritative servers, run nslookup -type=ns example.com, then query one of them with nslookup example.com ns1.example.net. If your output shows Non-authoritative answer:, read it the same way as on Ubuntu. The AA bit is part of the DNS protocol, not of one tool.

Microsoft documents a list of error messages. These are the ones you are most likely to meet:

• Nonexistent domain: the computer or DNS domain name does not exist.
• No records: the name is valid, but the server has no records of the type you asked for.
• timed out and No response from server: two separate entries, and neither gives you an answer to read. Check the server address and the network path first.
• Refused: the server refused to answer the request.

The BIND nslookup on Ubuntu prints different text for these problems. A name that does not exist gives ** server can't find followed by the name and NXDOMAIN.

What does "Server: UnKnown" mean in Windows nslookup?

Microsoft's nslookup reference does not explain this line. It is commonly caused by a missing reverse (PTR) record for the resolver's own address. A PTR record maps an IP address back to a name. Without one, nslookup has no name to print for the server. You can test it by looking up the resolver's address:

nslookup 192.0.2.53

Use the address from your own Address: line instead of 192.0.2.53. If that lookup finds no name, that is the likely reason. Either way, if Name: and Address: lines for your query follow, the lookup itself worked.

FAQ

What does "Non-authoritative answer" mean in nslookup?

It means the server that replied is not an authority for the name you asked about. In DNS terms, the AA (Authoritative Answer) bit in the reply was clear, and the BIND nslookup prints the line when that bit is clear. Almost every lookup goes through a recursive resolver, which answers from its cache or by asking other servers, so the line is normal. It is not an error, and it does not mean the answer was changed.

Why does nslookup show Server 127.0.0.53 on Ubuntu?

Ubuntu runs systemd-resolved, which listens as a local DNS stub on 127.0.0.53. On a typical install, /etc/resolv.conf points at the stub, so nslookup and dig ask it first and it passes the query upstream. The #53 in 127.0.0.53#53 is the DNS port. Run resolvectl status or resolvectl dns to see the upstream servers the stub uses.

How do I get an authoritative answer from nslookup?

Find the zone's nameservers with nslookup -type=ns example.com. Then query one directly with nslookup example.com ns1.example.net, using a name from the first output. The authoritative server sets the AA bit, so the Non-authoritative answer: line disappears. With dig, run dig +norecurse @ns1.example.net example.com A and look for aa in the flags: line of the response.

Is dnsutils still the package that provides nslookup on Ubuntu?

The real package is bind9-dnsutils, which ships both /usr/bin/nslookup and /usr/bin/dig on Ubuntu 24.04 and 26.04. On 24.04, dnsutils is a transitional package that depends on it. On 26.04, dnsutils is only a virtual package name. Run sudo apt install bind9-dnsutils and confirm with dpkg -S /usr/bin/nslookup.

What does "Server: UnKnown" mean in Windows nslookup?

Microsoft's nslookup reference does not explain it. The usual cause is a missing reverse (PTR) record for the DNS server's own IP address, so nslookup has no name to show for it. To test this, run nslookup followed by the server address from the Address: line. If the Name: and Address: lines for your query appear below it, the lookup itself worked.