While I was looking for free public DNS servers the other day, I happened to come across the Google Public DNS. Reading the FAQ I gathered that it was not based upon BIND or NSD but was a proprietary DNS server written by Google.

When you connect to your ISP, most of the time you get an IP address and DNS servers from your ISP’s Dynamic Host Configuration Protocol (DHCP) server.

As per their website, Google Public DNS is a recursive DNS resolver, similar to other publicly available services, but it is not any of the following:

• A top-level domain (TLD) name service. Google is not an operator of top-level domain servers (generic or country-code)
• Google Public DNS is not a third-party DNS application service provider, such as DynDNS, that hosts authoritative records for other domains.
• Google Public DNS servers are not authoritative for any domain. Google maintains a set of other nameservers that are authoritative for domains it has registered, hosted at ns[1-4].google.com.
• A malware-blocking service. Google Public DNS does not perform blocking or filtering of any kind.

To use Google Public DNS, you need to explicitly change the DNS settings in your operating system or device to use the Google Public DNS IP addresses below.

The Google Public DNS IP addresses are as follows:

8.8.8.8
8.8.4.4

You can follow the steps below to change DNS settings in the TCP/IP properties window for the required network connection. (Example below is for Windows XP)

1. Navigate to the Control Panel.
2. Click Network and Internet Connections, then Network Connections.
3. Select the connection for which you want to configure Google Public DNS. For example:
- To change the settings for an Ethernet connection, right-click Local Area Connection, and click Properties.
- To change the settings for a wireless connection, right-click Wireless Network Connection, and click Properties.
4. Under the General Tab. Under This connection uses the following items, click Internet Protocol (TCP/IP), and then click Properties.
5. Click Advanced and select the DNS tab. Note down any DNS server IP addresses already listed there and then remove all of them from this window.
6. Click OK.
7. Select the option Use the following DNS server addresses. If there are any IP addresses listed in the Preferred DNS server or Alternate DNS server, write them down for future reference.
8. Replace those addresses with the IP addresses of the Google DNS servers: 8.8.8.8 and 8.8.4.4.
9. Restart the connection you selected.

I tried to gather more information about the service and noted down the following:

- Servers spread about around the globe (obviously)
- The service uses anycast routing to direct requests to the nearest DNS server
- Google Public DNS can respond to requests for IPv6 addresses (AAAA requests), but it does not yet support native IPv6 transport and cannot talk to IPv6-only authoritative nameservers. Clients should use IPv4 network connections to use Google Public DNS. This is likely to change as the service evolves.
- Google Public DNS is an independent service with no cross product dependencies.
- No technical support is provided by google directly and the only available form of support is Google groups, a Twitter channel and telephone support.
- The service is not bound by SLA at this time. 

The benefits mentioned by Google while using their DNS server are:

- Speed up your browsing experience
- Improve your security
- Get the results you expect with absolutely no redirection

I tried the new DNS settings and was satisfied (without a few domain names not resolving), I have yet to try to calculate the difference in latency of my old DNS servers versus Google Public DNS. I expect the product to improve much more in the long run.

Although BIND is the most popular domain name server software being used today, NSD (“name server daemon”) is another popular alternative open-source server program.

NSD is an authoritative name server (i.e., not implementing the recursive caching function by design) and uses BIND-style zone-files (zone-files used under BIND can usually be used unmodified in NSD, once entered into the NSD configuration).

NSD uses zone information compiled via ‘zonec’ into a binary database file (nsd.db) which allows fast startup of the NSD name-service daemon, and allows syntax-structural errors in Zone-Files to be flagged at compile-time (before being made available to NSD service itself).

The collection of programs/processes that make-up NSD are designed so that the NSD daemon itself runs as a non-privileged user and can be easily be configured to run in a Chroot jail (A chroot environment can be used to create re-root a program to another directory in unix), such that security flaws in the NSD daemon are not so likely to result in system-wide compromise.

Most of the Internet root nameservers use BIND, however a few of them also use NSD. Apart from that several other TLDs use NSD for part of their servers.

When a device on a TCP/IP network starts up and is not configured for a static IP address, it needs to receive an IP address before it can communicate with other devices on the network. A standard computer with a hard disk can be enabled for static configuration but a diskless device that does not have any storage, only has an option to acquire an IP address from the network. This process of getting a new machine up and running is commonly referred to as bootstrapping. To provide this functionality, the TCP/IP Bootstrap Protocol (BOOTP) was created. 

The Bootstrap Protocol, or BOOTP, is a network protocol used by a network client to obtain an IP address from a configuration server. In order to get an IP address the network clients contact other devices on the network. Initially (ages ago) a boot floppy disk had to be inserted to establish the initial network connection, but later on Network Interface card manufacturers embedded the protocol in the ROM of the interface card as well as on motherboards that have onboard network adapters, thereby avoiding the need for floppy disks and allowing for direct network booting.

During the bootstrap process when a computer is starting up, the BOOTP protocol is used. A BOOTP server assigns an IP address to each client from a pool of addresses and based on the configuration of the server. BOOTP generally uses the User Datagram Protocol (UDP) as the transport protocol. Earlier, BOOTP has also been used for diskless workstations to obtain the network location of their boot image in addition to an IP address using protocols like PXE, and also by enterprises to roll out pre-configured client installations to newly installed PCs.

Although BOOTP provides a very important function, it is not used frequently today and has been superseded by DHCP (Dynamic Host Configuration Protocol) which is a more advanced protocol for the same purpose. Most DHCP servers also offer BOOTP support and are the most prevalent method used today to assign IP addresses to diskless workstations and clients that require IP addresses.

The first time you install firefox, both the keyword search in the address bar of the browser as well as the search box at the top right default to using Google as the search engine.

I find using the URL method (typing into the address bar directly) more useful. But since there are tonnes of search engines out there, if you want to explore a new search engine, you can easily change the default search engine that firefox uses.

In this example, the default search engine is changed from Google to Bing. It is very easy to do this and you just need to change a key value in the firefox configuration (the key collection).

Firstly, go ahead and type about:config and you will receive a warning that looks like the image below

Click on “Yes , I’ll be careful , I promise “ button. You will now see a lot of preference names and key values. In the Filter , type in keyword and you will see two options left.

The key which is of interest to us is keyword.url

Click on the keyword.url key in the list and right click and select modify. You will see the default value in it is the google search engine with the value http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q= (this might vary depending on your system)

Replace that with http://www.bing.com/search?q=

You also need to make sure that the keyword.enabled boolean key value is set to true (this is done by default)

After that, press OK and restart the firefox browser (not always necessary, but a good practice). Now you are ready to test your tweak. Try typing in something in the address bar of the browser and press enter. You are taken to the Bing search engine with results. The same thing can be done to change to other search engines. You just need to change the keyword.url value.

Domain Name Servers on the internet use various software to function, the most popular DNS server type on the internet is BIND, which stands for Berkeley Internet Name Domain. BIND is the predominant system on UNIX based systems. 

BIND was originally created at the University of California, Berkeley and is maintained today by the Internet Systems Consortium. It was rewritten to address architectural difficulties and also to support DNSSEC (DNS Security Extensions).

BIND initially supported only flat text files to store and retrieve data. However, recent versions of BIND have allowed zone data storage and retrieval in a variety of database formats including LDAP, PostgreSQL, MySQL, and ODBC.

Since BIND was written a long time back, there were many security vulnerabilities that have been exploited by earlier versions of BIND and hence their use is strongly discouraged. The latest version of BIND should be deployed, although they have also experienced numerous vulnerabilities which can be managed to some extent by using DNSSEC and other technologies

More information about BIND at the ISC website can be obtained from https://www.isc.org/software/bind

Booting your host from the network without the need to rely on the local operating system or hard disks is a technology that is not used very often in the corporate environment today with some people never having heard that such a thing is possible. With the way things are moving today with virtual machines, virtual storage, dynamic infrastructure, I feel that the trend would be reversed with few folks storing data on local hard drives and more moving to virtual environments and booting from remote storage at least as far as the backend infrastructure is concerned because of the advantages of flexibility, backup, deployment, etc.

Preboot eXecution Environment (PXE) or ‘pixie’ as it is popularly called is one of the many technologies that helps in booting hosts using a Network Interface with the help of images stored remotely. PXE consists of a suite of protocols like IP, UDP, DHCP, TFTP and concepts like Globally Unique Identifier (GUID) and Universal Network Device Interface (UNDI). The firmware of the PXE client is extended with the help of API’s. The PXE client refers to any hardware host device (server, notebook, PC) that is included with the PXE boot code.

PXE is an open industry standard developed by a number of software and hardware vendors. It was initially designed by Intel, with input from several other vendors including 3Com, HP, Dell, Compaq, and Phoenix Technologies. PXE works with a USB adapters and network interface card (NIC) in the PC, making the PC boot over the network.

Hosts that support booting from PXE, have a firmware that tries to locate a PXE redirection service (Proxy DHCP) to get a list of PXE boot servers that are available. After going through the reply, the firmware software will request an appropriate boot server for the file path of the network bootstrap program (NBP) like xxx and download it on the local Random Access Memory (RAM) using TFTP generally, verify and execute it.

If a common NBP is used by all PXE clients it could be specified by BOOTP thereby not needing a proxy DHCP, but the TFTP server is still required.

PXE Protocol

The PXE protocol is a combination of modified versions of DHCP and TFTP. DHCP is used to locate the appropriate boot servers and TFTP is used to download the bootstrap program and other files to the PXE client. Initiation of a PXE bootstrap session is done by the PXE firmware broadcasting a DHCPDISCOVER packet with PXE options (extended DHCPDISCOVER) to port 67 UDP (DHCP Server port). The PXE options identify the firmware of the sending host as capable of PXE, but this message is ignored by standard DHCP servers. If the PXE client receives DHCPOFFERS from such servers, it may request for one of the offered configurations.

PROXY DHCP

When a PXE redirection service (Proxy DHCP) receives an extended DHCPDISCOVER, it replies by sending back a broadcast called an extended DHCPOFFER (DHCPOFFER with extended PXE options) to port 68/UDP (DHCP client port). The reason this packet is broadcasts back because the IP address of the PXE client is not included in DHCPDISCOVER message. The client is mainly identified by its GUID/UUID

Extended DHCPOFFER contains mainly:

 - PXE Discovery Control field to decide whether Multicasting, Broadcasting, or Unicasting is to be used for contacting PXE boot servers
- List of IP addresses of each available PXE Boot Server Type
- PXE Boot Menu with each entry representing a PXE Boot Server Type
- PXE Boot Prompt telling the user to press <F8> to see the boot menu
- Timeout to launch the first boot menu entry if it expires.

The Proxy DHCP service may also be run on the same host as the standard DHCP service. Since both services cannot share port 67/UDP, the Proxy DHCP runs on port 4011/UDP and expects the extended DHCPDISCOVER packets from PXE Clients to be DHCPREQUESTs. The standard DHCP service has to send a special combination of PXE options in its DHCPOFFER, so the PXE client knows to look for a Proxy DHCP on the same host, port 4011/UDP.

Boot Server

To contact any PXE Boot Server the firmware must have an IP address and has to consider all information from exactly one extended DHCPOFFER. After choosing an appropriate PXE Boot Server Type the firmware multicasts or unicasts a DHCPREQUEST packet extended with PXE-specific options (extended DHCPREQUEST) to port 4011/UDP or broadcasts it to port 67/UDP. This packet mainly contains the PXE Boot Server Type and the PXE Boot Layer, allowing to run many boot server types with one boot server daemon (or ‘program’). The extended DHCPREQUEST may also be a DHCPINFORM.

If a PXE Boot Server receives an extended DHCPREQUEST as described above and if the boot server is configured for the requested PXE Boot Server Type and client architecture, it must respond by sending back an extended DHCPACK to the source port of the extended DHCPREQUEST.

Extended DHCPACK contains mainly:
- The complete file path to download the NBP via TFTP.
- PXE Boot Server Type and PXE Boot Layer the boot server answered to
- Multicast TFTP configuration, if MTFTP as described in the PXE specification should be used

Additionally the PXE firmware extension was designed as an Option ROM for the IA-32 BIOS so you can get a personal computer (PC) PXE-capable by installing a NIC that provides a PXE Option ROM as can be seen in the figure below

The PXE Client/Server Protocol was designed so:

- It can be used in the same network as an existing DHCP environment without interference
- It can be integrated completely into standard DHCP services

Inverse Address Resolution Protocol (Inverse ARP or InARP), is a protocol used for obtaining Network Layer addresses of other nodes from Data Link Layer addresses. For example, in Ethernet networks InARP would primarily be used to get IP addresses when MAC addresses are known.

It is primarily used in Frame Relay and ATM networks, in which Layer 2 addresses of virtual circuits are sometimes obtained from Layer 2 signaling, and the corresponding Layer 3 addresses must be available before these virtual circuits can be used. In Frame Relay networks InARP is used to get Data Link Connection Identifier (DLCI) mappings to Virtual Circuits and is enabled automatically by default.

InARP operates essentially the same as ARP with the exception that InARP does not broadcast requests but sends them by unicast directly to the destination.  This is because the hardware address of the destination host is already known. The source host that sends the request simply formats it by inserting its source hardware and protocol addresses and the known destination hardware address. It then zero fills the target protocol address field.  Finally, it will encapsulate the packet for the specific network and send it directly to the target station. The diagram below gives us an illustration of how Inverse ARP works

1. Host A wants to send a packet destined to a host with MAC address CC-CC-CC-CC-CC-CC but does not know the IP address of the device
2. Host A then sends a unicast ARP request to the specified destination host
3. Switch A looks at the destination MAC address in the packet and forwards the packet to Host C
4. Host C updates its ARP table and sends a reply back to Host A
5. Host A receives the reply and updates its ARP table and then sends the packet unicast to Host C with its destination IP address

Upon receiving an InARP request, a station may put the source protocol address/hardware address mapping into its ARP cache as it would any ARP request.  Unlike other ARP requests, however, the destination host may assume that any InARP request it receives is destined for it. For every InARP request, the destination host may format a proper reply using the source addresses from the request as the target addresses of the reply.  If the host is unable or unwilling to reply, it ignores the request.

When the source station receives the InARP reply, it may complete the ARP table entry and use the provided address information. The information learned via InARP or ARP may be aged or invalidated under certain circumstances.

InARP (Layer 2 known, Layer 3 unknown) is the inverse of ARP (Layer 3 known, Layer 2 unknown) as they both do just the opposite. In addition, InARP is actually implemented as a protocol extension to ARP. InARP uses the same packet format as ARP; but has different operation codes.

For those of you who have heard of Address Resolution Protocol (ARP) and think that Reverse Address Resolution Protocol (RARP) is its complement, they are totally off track. RARP is a computer networking protocol used by a host computer to request for an IPV4 address from another host computer if it does not have one used (not statically assigned), the Network Interface that is connected to the network would already have a Layer 2 MAC address (hardware address).

This might very well sound like DHCP which is very popular and does the same thing. In fact RARP has been rendered obsolete by two of its successors, the Bootstrap Protocol (BOOTP) and the newer Dynamic Host Configuration Protocol (DHCP), which have better features than RARP.

In an RARP setup, one or more server hosts maintain a database of mappings of Link Layer addresses to their respective protocol addresses (similar to an IP to MAC mapping in Ethernet networks). Media Access Control (MAC) addresses needed to be individually configured on the servers by an administrator (this is where DHCP rules and RARP got kicked out). RARP was limited to serving only IP addresses.

Another misnomer is that Reverse ARP is the same as Inverse Address Resolution Protocol (InARP). But InARP was designed to get the IP address associated with another host’s MAC address. InARP is actually just the reverse of ARP in functionality.

The Address Resolution Protocol (ARP) is a computer networking protocol to find out the MAC address (Physical address) of a device when the IP address (Logical address) is known. This is predominantly used in Local Area Network (LAN) environments as well as routing data traffic based on IP addresses when the next hop router must be known. The diagram below illustrates how ARP functions

1. Host A wants to send a packet destined to 192.168.1.9
but does not know the MAC address of the device
2. Host A then sends an ARP request to all hosts (BROADCAST)
which is forwarded to the Switch A connected to all hosts
3. Switch A looks at the destination MAC address in the packet and broadcasts the packet to all hosts on the LAN except Host A
4. Host B and Host D receive the packet and just update their ARP table with the IP address of Host A and its MAC address
5. Host C updates its ARP table and notices its IP address in the destination IP address field and sends an ARP reply which is unicast back to the source MAC address of Host A
6. Host A receives the ARP reply and updates its ARP table and then sends the required packet unicast to Host C

Originally part of RFC 826 defined in 1982. Although ARP has been used in many types of networks such as IP, DECNET, Token Ring, FDDI and other Ethernet Technologies, today it is predominantly used to translate IP addresses to Ethernet MAC addresses because of the prevalence of IPV4 and Ethernet in general. It is generally reference under layer 2 (data link) and layer 3 (network) of the OSI networking model.

ARP functions as a low level request and response protocol that is sent across the media access level of the underlying network. In case of Ethernet systems, ARP disguises itself in the payload of the Ethernet packet (see below)

ARP announcements 

Sometimes ARP may be used for announcement purposes. For example, if the IP address or MAC address changes due to a changed Network Card, DHCP lease expiring, etc. The host signals that to the rest of the network by sending out a Gratuitous ARP message broadcast. This type of an announcement is just for the information of the other hosts so that they can update their ARP table and is not send with the intention of receiving a reply. It is also used during MAC address change in Network Interface card (NIC) Teaming, High availability clusters.

ARP probe

A host broadcasts ARP probe packets all around the network before it begins using an IPV4 address (manually assigned, DHCP assigned). This is done to test if the address is already in use and is accomplished by sending out an ARP request constructed with a 0.0.0.0 (all-zero) source IP address.

Nslookup.exe (abbreviation for name server lookup) is a command line utility used for testing and troubleshooting DNS servers. It is built into Unix (including Linux and variants) and Windows. The main purpose of the utility is to query DNS servers to find DNS details, MX records for a domain, NS servers of a domain

In Windows, Nslookup.exe is automatically installed along with the TCP/IP protocol installation which is done by default during a new Windows installation or setup. The actual executable lies in the system directory c:\windows\system32 directory by default in Windows XP and most other versions of Windows.

To get started with Nslookup.exe, the following prerequisites need to be present: 

The TCP/IP protocol must be installed on the computer that you want to execute the Nslookup command without which the command will not be available

When you run the ipconfig /all command, at least one DNS server should exist in the list of DNS servers

The Nslookup command always devolves (delegates from) the domain name from the current context (depending on the DNS Server settings listed). If you fail to use a fully qualified domain name, i.e. ending the domain name with a trailing dot (.), the first query will append the DNS settings to your query domain name. For example, if you have your DNS settings listed as xyz.com and you run a query for www.bing.com, the actual query will go out as www.bing.com.xyz.com because of you entering an unqualified query. However, if you were to query for www.bing.com. [with the trailing dot (.)], then the query would rightly go out to www.bing.com only (diagram below). This strange behavior is specific to the Microsoft version of the Nslookup command. I do not know of how Nslookup behaves while run with other vendors.

If the DNS search list is being used in the Domain suffix search order in TCP/IP advanced properties DNS tab (diagram below), devolution will not take place. The query will be appended to the domain suffixes specified in the list. To override the search list, always use the Fully Qualified Domain Name in your query.

The command can be used directly (non-interactive mode) or with subcommands (interactive mode). Using Nslookup.exe in the non-interactive mode is useful when we just need the output of a specific query and only a single value needs to be returned. But when we need to get the output for multiple queries and actions it is better to use the interactive mode

The syntax of Non Interactive Mode is as follows:

nslookup [-option] [hostname] [server]

 nslookup [-opt ...]                          # interactive mode using default server

nslookup [-opt ...] – server          # interactive mode using ‘server’

nslookup [-opt ...] host                 # just look up ‘host’ using default server

nslookup [-opt ...] host server    # just look up ‘host’ using ‘server’

Option refers to the various options that are available covered below

Hostname refers to the query that we need information on

Server refers to the DNS server to be used to search for the host

 Look at the following output from a unix and windows based host

Command line output (without subcommands)

UNIX

unix% nslookup example.com

Server:        192.168.1.1
Address:    192.168.1.1#53

Non-authoritative answer:

Name:    example.com
Address: 202.7.18.16

 

Windows

C:\>nslookup microsoft.com.

Server:  PQRTVXXXXD002DNS076
Address:  210.213.34.3

Non-authoritative answer:

Name:    microsoft.com
Addresses:  207.46.197.32, 207.46.232.182

Using subcommands (unix example)

nslookup

> server ns1.com

Default Server:  ns1.com
Address:  172.204.22.25

> set
> example.com

Server:  ns1.com
Address:  202.7.18.16

example.com   MX preference = 10, mail exchanger = mail.example.com
> exit

After entering the interactive mode, typing ? or help will reveal all the options that are available

To interrupt interactive commands, press CTRL+C. To exit interactive mode and return to the command prompt, type exit at the command prompt. A number of different options can be set in Nslookup.exe by running the set command at the command prompt. A complete listing of these options is obtained by typing set all.

Looking up different data types: type and querytype 

We will discuss the two options, type and querytype that belong to the set command. To look at different query type options within the domain name space, we use the set type or set querytype command at the command prompt. Both of them are exactly the same and are interchangeable. For example, to query for mail exchanger records (mail server details) of a particular domain like yahoo.com, we can type the following:

C:\>nslookup

> set q=mx
> yahoo.com.

Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
yahoo.com       MX preference = 1, mail exchanger = a.mx.mail.yahoo.com
yahoo.com       MX preference = 1, mail exchanger = b.mx.mail.yahoo.com
yahoo.com       MX preference = 1, mail exchanger = c.mx.mail.yahoo.com
yahoo.com       MX preference = 1, mail exchanger = e.mx.mail.yahoo.com
yahoo.com       MX preference = 1, mail exchanger = f.mx.mail.yahoo.com
yahoo.com       MX preference = 1, mail exchanger = g.mx.mail.yahoo.com

The first time a remote host is queried, the local DNS server contacts the DNS server that is authoritative for that domain. The local DNS server will then cache that information, so that subsequent queries are answered nonauthoritatively out of the local server’s cache. The first time a query is made for a remote name, the answer is authoritative, but subsequent queries are nonauthoritative.

Querying another name server directly: server  and lserver

If we wanted to use another DNS server on the internet to send our queries, we can use the server or lserver commands. For example, using the DNS server 8.8.8.8 that is the Google Public DNS server

C:\>nslookup

Default Server:  nameserver1.example.com
Address:  10.1.2.3

> server 8.8.8.8
Default Server:  google-public-dns-a.google.com
Address:  8.8.8.8

The difference between the server and lserver commands is that the server command is uses the current default server to get the address of the server to switch to, whereas the lserver uses the local server to get the same address. For example, if you have a broadband connection and get a DHCP IP address from your ISP, you would also automatically get some DNS servers (assume dns1.isp1.com), the lserver command forces the usage of these local dns servers that were retrieved from your ISP. However, while using the Nslookup.exe command, if you earlier changed the DNS server that is used to query for other domains (assume you changed it to dns1.somefreedns.com), the server command would use the current default server (dns1.somefreedns.com) and not the local dns servers (dns1.isp1.com)

Zone Transfers : LS command

Nslookup.exe can be used to transfer an entire zone by using the ls command. The best use of this command is if you want to store a list of all host names within a particular remote domain into a local file (example below)

The syntax of this command is

ls [opt] DOMAIN [> FILE] – list addresses in DOMAIN (optional: output to FILE)
    -a          -  list canonical names and aliases
    -d          -  list all records
    -t TYPE     -  list records of the given type (e.g. A,CNAME,MX,NS,PTR etc.)

Using ls with no arguments will return a list of all address and name server data. The -a switch will return alias and canonical names, -d will return all data, and -t will filter by type.

>ls example.com

[nameserver1.example.com]

nameserver1.example.com.    NS     server = ns1.example.com
nameserver2.example.com     NS     server = ns2.example.com
nameserver1                            A      10.0.0.1
nameserver2                            A      10.0.0.2

While this is obviously a security issue, zone transfers can be blocked at the DNS Server level and this would be the case most of the time on the internet (unless someone foolish enough would like you to see his internal structure and naming conventions). This command is useful if we want to see the structure of hosts within a LAN environment. If zone transfers have been blocked, we would get output like the following

> ls google.com.
*** Can’t list domain example.com.: Query refused

When we want to send the output to a file (the file will be saved in the location that was mentioned in the command prompt before the nslookup command was started, we can do so as follows

> ls google.com. > lsoutput.txt
Received 0 records.
*** Can’t list domain google.com.: Query refused

In the following example below, we want to view all mail server records within a particular domain and store the output to a file

> ls –t MX google.com. > lsoutput.txt
Received 0 records.
*** Can’t list domain google.com.: Query refused

In this article the Nslookup command was covered. While this was just a brief overview, there are many other issues like troubleshooting and whether using Nslookup itself is recommend which will be covered in future articles