Continuing with the theme, I decided to continue the networking utilities by covering nslookup. I’ll finish this week off by covering dig and doing a comparison between the two. Just like host, nslookup was developed by the Internet Systems Consortium and is released with BIND9. At one point the ISC has stated that nslookup is deprecated and when using the utility it gave this:

Note: nslookup is deprecated and may be removed from future releases. Consider using the dig or host programs instead. Run nslookup with the -sil[ent] option to prevent this message from appearing.

but that’s since been redacted. The most recent change to the nslookup source code was commited on Valentines day of this year. So I’m guessing it’s not entirely dead.

I’m going to break away from the normal convention and really just dive into nslookup as it offers most of the same functionality as host and dig however, the output is a bit less verbose. There is also one major difference between the normal DNS resolution tools and nslookup, and it is clearly stated in the man page on macOS in a disclaimer:

The nslookup command does not use the host name and address resolution or the DNS query routing mechanisms used by other processes running on macOS. The results of name or address queries printed by nslookup may differ from those found by other processes that use the macOS native name and address resolution mechanisms. The results of DNS queries may also differ from queries that use the macOS DNS routing library.

Basically, be careful, and be a bit skeptical of the results returned by nslookup as they may not be the most accurate.


What I like about nslookup is the limit amount of text returned in the results. It is a quick and easy way to get some data back that is easily grepable or can be piped into other commands.

Just like before, lets run a basic lookup. The big difference you might notice is that it shows a Server and Address result, which on my machine points to a local IP address.


Non-authoritative answer:

To get more specific records, we can use the -q option.

nslookup -q=mx

Non-authoritative answer:	mail exchanger = 20	mail exchanger = 10

Authoritative answers can be found from:

Let’s grab the NS records. I like how the default also returns both authoritative and non-authoritative results when possible.

nslookup -q=ns

Non-authoritative answer:	nameserver =	nameserver =	nameserver =

Authoritative answers can be found from:	internet address =	internet address =	internet address =	has AAAA address 2400:cb00:2049:1::c629:dead	has AAAA address 2400:cb00:2049:1::adf5:3b29	has AAAA address 2400:cb00:2049:1::adf5:3a33

Used in the Wild

When working at a company, they ran into an issue where their Sender Policy Framework record was causing an error. According to the SPF specification, it can only resolve 10 DNS lookup requests, and that includes lookups within lookups. A quick an easy fix is to add IP addresses directly into SPF record as they don’t need to be resolved. The G Suite documentation gives examples using nslookup. With that I was able to write up a quick and dirty script (I’m not proud, but it get’s the job done).

nslookup -q=TXT | grep spf1 | cut -d '"' -f2 | cut -d ' ' -f2- | rev | cut -d ' ' -f2- | rev
ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4:

To be fair, the same result can be achieved with host -t TXT.


While it’s not my first choice, nslookup has been around for a long time and still usable. There have been a lot recommendation to switch over to host or dig (because of the deprecation), but I’m glad I dove into it as it still might be floating around in some older systems or scripts. Need something quick and dirty, give nslookup a try.