[#dnsclint]:

DNS Client Software

A whole lot of Internet-aware software

A lot of software can perform some types of domain name lookups. Generally these programs use a common, shared library of computer code that lets programs easily look up domain names. For example, using ping can cause that program to show the resolved IP address that the software will attempt to contact. (The command can therefore be useful even if the communication is expected to fail. For instance, if a firewall blocks the type of traffic used by this program's main communication, but if DNS traffic is allowed through, then using ping can result in a hostname being looked up.) This sort of technique is namely just useful for the most common record types: AAAA (and A6 if supported) and A.

[#dnsrslvr]: Resolver / “DNS cache”

Most software will likely use the DNS “resolver”. This may be the first thing that is checked. Many people may be unfamiliar with the name “resolver”, but do know that DNS results can be cached. The software that handles this cache may be called “resolver”.

Interacting with Resolver in Microsoft Windows

With new-enough versions of Microsoft Windows, IPConfig/? will show that /displaydns will “Display the contents of the DNS Resolver Cache.” Also, the program's help may show that the /flushdns command line option “Purges the DNS Resolver Cache.

Interacting with Resolver in Unix

This may be configured using /etc/resolv.conf and similar files.

(This might be similar/identical to what is being discussed by OpenBSD's manual page for resolv.conf: section documenting bugs, which makes an un-hyperlinked reference to “resolver”. Earlier in the document, though, is a reference to the OpenBSD manual page for “resolver”.)

Note that not all software uses the operating system's general DNS code. For example, nslookup might return different results than ping and most other software. Such occurrences are pretty rare; an example may be if the operating system uses cached DNS results and nslookup is looking up details more recently queried from the server. (In such a case, flushing the DNS cache will help programs like ping to start using the newer information.)

Configuring system-wide DNS
Unix
Unix and similar operating systems which may initially rely on a configuration in a /etc/resolv.conf* file. (Specifically, the most commonly supported location is the /etc/resolv.conf file, although in OpenBSD, a /etc/resolv.conf.tail may exist, and be used to commonly override whatever settings go into the /etc/resolv.conf file.) That file may have a line such as “nameserver 8.8.8.8” which may cause the specified system to be used as a name server. However, that file may also have other lines of text, such as a line that starts with the word “lookup ”, which may cause name resolution to be used by a different configuration location. (Further details may be described at some later time. For now, make whatever use is needed of resources such as OpenBSD's man page for resolv.conf.)
Other systems

In many cases, name resolution is handled by the network stack, such as the TCP/IP suite. In such cases, setting up the ability to use name resolution including DNS is similar to configuring other critical network details, such as configuring a network address. (Details about configuring a network address are mentioned in the section about network addressing.)

Some older notes

The following were some older notes, which might be more verbose/thorough/useful than a newer version. (This should be reviewed, and better merged into the main site.)

Automatic setup
DNS information may be obtained automatically. Methods include:
IPv6
Using NDP

RFC 4339: automatic configuration of DNS settings (e.g. sent via NDP) discusses some of the approaches that have been considered.

DHCPv6

see http://en.wikipedia.org/wiki/DHCPv6 ? There is a term for configurations involving obtaining some information, such as a DNS server address, using DHCPv6 even when DHCPv6 is not being used to obtain an IPv6 address for the client to use. That term is “DHCPv6 stateless mode”. (See http://technet.microsoft.com/en-us/library/cc753493.aspx )

via DHCPv6 (see the Other Managed bit, e.g. raflags 0x40)

IPv4

Surely the most common way that DNS information was automatically provided with IPv4 setups was to use DHCP. Servers can provide a DNS server, and clients may choose to use it.

The common way to get the IP addresses of the DNS servers shared with clients is to transmit it via DHCP. With at least some operating systems (like Windows XP), the setting to “Obtain DNS server address automatically” is a setting that is unavailable unless the DHCP client is used for automatic addressing (by also selecting “Obtain an IP address automatically”). For further details, see info on setting up DHCP options. Specifically, option 6 (as noted by RFC 2132 section 3.8: DNS settings with information DHCP is handing out).

DNS settings
Seeing current settings
Unix

See the /etc/resolv.conf file. With OpenBSD, the /sbin/dhclient-script (which is the default used but the exact script file being used can be overridden by dhclient.conf) adds the contents of /etc/resolv.conf.tail to /etc/resolv.conf, allowing an easy way for manually assigned settings (that are manually put into /etc/resolv.conf.tail) to be placed at the end of /etc/resolv.conf and overwrite any automatic settings that DHCP may put in /etc/resolv.conf. (The code also uses an /etc/resolv.conf.std file.) This may not be widely supported on other platforms but may be nice to take advantage of and definitely is good to know about if trying to troubleshoot: This is even good to know about when using other operating systems as it likely isn't very difficult for an OpenBSD user to implement such functionality onto other operating systems (probably simply by copying and using the script file).

Look for lines that say “nameserver”. Note that this file may be edited automatically, such as by DHCP. This may be modified by using a line in dhclient.conf like “prepend domain-name-servers 8.8.8.8, 8.8.4.4, 4.2.2.2;

Windows
There are options:

If those don't look right, also look for line that says “DHCP Enabled” to see if that is set to “Yes” or “No”. If Yes, that probably does indicate where the DNS settings are coming from.

Mac OS X

One way is to open up a session of Terminal, a program under Utilities under Applications, and then follow the instructions for Unix. Another way is to go to the Apple menu and choose (??? System Preferences/Configuration? Network?)

Modifying current settings
Using automated methods
IPv6
With NDP/SLAAC/etc., the M and/or O bit may be relevant to determine whether to use DHCPv6 for this.
Other
Perhaps Draft document is relevant?
DHCPv6
TechNet article on DHCPv6 ...
IPv4
Use DHCP. Often, very near the spot where the operating system configures whether to use static or dynamic IP addresses is a location to configure DNS servers and there may be an option to choose to automatically set the information about what DNS servers to use.

In general, there are two ways to modify DNS: Statically and dynamically.

Dynamic/True DNS

e.g. see info referenced by Archive.org capture of http://www.dnsserverlist.org/ - the referenced program was http://www.walltechnet.net/WTS-Software/AdaptorConfig-beta.zip (which is also a site which no longer provides useful content).

Some static servers to use

In general, the main thing to set up is the list of DNS servers. Some choices:

  • Internal: By using an internal DNS, private domain names can be used. By having all clients point to an internal DNS server, changes throughout the organization can be done simply by changing the DNS servers. The main reason not to have all machines rely only on internal DNS is that mobile users may not be able to use the internal DNS (at least prior to using a VPN) when the machines are outside the network. Also, the internal DNS servers will need some other way to look up information.
  • DNS provided by an Internet Service Provider. In theory, DNS servers provided by the Internet Service Provider may be the fastest since network traffic doesn't have to travel as far. Also, since this is generally part of the service that the Internet Service Provider is providing, and since such service is frequently paid, there is incentive for the provider to invest, however needed, in ensuring that the service is reliable.

Here are some other, more specific choices which are generally available.

Accessible via IPv6 and/or IPv4

See below sections for information that may apply to IPv6 only or IPv4 only.

Accessible via IPv6
2001:5c0:1000:11::2 or 2001:5c0:1001::194 (described by FreeNet6 Tools)
Accessible via IPv4
  • OpenDNS: IPv4 208.67.222.222 and 208.67.220.220 - in addition to just plain being usable, publicly, users may sign up with the site to set up some customizations such as blocking requests for certain types of sites (in order to filter entire domains or IP addresses as a method of content filtering). http://www.dslreports.com/shownews/OpenDNS-Were-Now-Used-By-1-Of-The-Internet-107497 claims 1% usage.
  • Google Public DNS: IPv4 8.8.8.8 and 8.8.4.4 (see news about Google Public DNS, Google Public DNS telephone support (877-590-4367 in USA and 770-200-1201 outside USA)
  • 4.2.2.2 and nearby (4.2.2.1 through 4.2.2.6): An easy to remember IPv4 address that is short, and may have been the easiest to remember prior to Google's 8.8.8.8. Discussion on 4.2.2.2 where Dan Farrell (dannosite.com) claims to have started the trend.
  • DNSServerList.org provides DNS servers that the site believes will be the fastest. (However, be wary of what would happen if an untrustworthy DNS server is used... If a formerly trustworthy IP address got into the hands of somebody who wanted to use it for rogue purposes, one certainly can't count on this website to both notice the problem and also inform all people who have ever copied the old DNS address from when it was previously published.)
Setting up static DNS
Google's guide (underneath the contact section) says “In most modern Linux distributions, DNS settings are configured through Network Manager.”
[#dnsrvlcl]: Seeing which DNS servers are used by the system-wide settings

As is often the case, information can often be viewed similar to how the information is configured/set. There may also be some other options: here are some approaches at just finding this information quickly.

  • For a Unix/BSD system, the nameservers used by the system should be in /etc/resolv.conf file. (For systems that get information dynamically, details in that text file have likely having been put there by a IPv4 DHCP client that the system ran.) One can run " grep nameserver /etc/resolv.conf " to see what nameservers the system uses.
  • For Win32 systems, running IPCONFIG.EXE/ALL may provide information and, if so, will report the DNS servers. Actually, running “ IPCONFIG.EXE/ALL | more ” may be helpful. For Win98 and WinME machines, that can be done.
    • For Win95, Win98, and WinME machines, WinIPCfg can be used, by running the command and then clicking on "More info". If there are multiple DNS servers that the client recognizes, a clickable button with an elipsis will change which DNS server is shown.)
[#nslookup]: nslookup

The nslookup command has the advantage of being deployed more widely than other alternatives. Both Unix and modern Microsoft Windows operating systems include an nslookup command. The nslookup command lets a person (or program) look up information from a nameserver. It supports both command line options and an interactive mode where settings are specified by entering commands within the program.

Using the nslookup command line

The syntax for a simple lookup may be as simple as:

nslookup site.example

A bit of a more complex example:

nslookup -q=A site-to-lookup.example optionalDNSServerToUse.example

For another example, see an example of using nslookup command line options to query for Reverse DNS information.

For Microsoft Windows (tested in Windows Vista), the following may substantially increase the amount of output:

nslookup -q=A www.kame.net 8.8.8.8
Using nslookup's interactive mode
...

Microsoft KB 200525: Using WinNT4/2K NSlookup.exe

[#digdns]: Domain Information Groper (“dig”)

Wikipedia's article on “Domain Information Groper” says “Dig is part of the BIND domain name server software suite.”

Documentation is available by ISC: BIND 9 Manual Page for the dig command (which is one of several BIND 9 Manual Pages for some DNS-related programs).

Some overview info

Currently this may often come bundled in with BIND. e.g. ISC's BIND for Windows may contain dig.

The Lowe Down: Post by Robert: DNS: Dig on Windows states, “For about as long as I can remember, every serious DNS administrator has always advocated the use of dig (Domain Information Groper) over nslookup. There.s no need for me to rehash all of the arguments . I.ll just say that dig returns information in a manner consistent with what a protocol analyzer might provide. That’s great”

Aaron Saray's blog entry: Dig for Windows points to: ISC BIND software. That now seems to redirect to a download page. Mark Minasi's Windows Networking Tech Page (Newsletter) Issue #94 (Late November 2011) refers to downloading dig for Microsoft Windows by getting BIND for Microsoft Windows, and then deleting the BIND files that are unrelated to the dig software. The Lowe Down: Post by Robert: DNS: Dig on Windows also seems to take the same basic approach (copying only the needed files to the required destination).

Mark Minasi's Windows Networking Tech Page (Newsletter) Issue #94 (Late November 2011) seems to have directions not involving the System32 directory. Also seemed to have an analysis of the output.

Example output
$ dig

; <<>> DiG 9.7.3 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62492
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION: .                       74515   IN      NS      i.root-servers.net.
.                       74515   IN      NS      f.root-servers.net.
.                       74515   IN      NS      a.root-servers.net.
.                       74515   IN      NS      b.root-servers.net.
.                       74515   IN      NS      k.root-servers.net.
.                       74515   IN      NS      c.root-servers.net.
.                       74515   IN      NS      d.root-servers.net.
.                       74515   IN      NS      h.root-servers.net.
.                       74515   IN      NS      g.root-servers.net.
.                       74515   IN      NS      m.root-servers.net.
.                       74515   IN      NS      e.root-servers.net.
.                       74515   IN      NS      j.root-servers.net.
.                       74515   IN      NS      l.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.     15262   IN      A       198.41.0.4

;; Query time: 18 msec
;; SERVER: 198.0.2.3#53(198.0.2.3)
;; WHEN: Tue Jul 10 05:27:59 2012
;; MSG SIZE  rcvd: 244

$

(This ends up being an easy way to see the root hints.)

Summary
It does seem that people who have become very familiar with dig tend to like it better than NSLookup. The dig software is readily used on many Linux systems, but does not come with Windows.
dnsq(r)

D.J. Bernstein, creator of djbdns DNS server software (which includes tinydns), has made some other DNS software including dnsq and dnsqr. The software called dnsqr is recursive. Documentation is at the page for D.J. Bernstein's page on Command line tools to debug DNS configuration.

Other DNS client software
[#hstdnscl]: host DNS client software

Wikipdia's page on “host (Unix)” is about a software command which is called host and which comes with BIND 9. (However, the dig command may be more widely popular/used.) The host may exist on Unix systems.

BIND 9 Manual Page for the dig command (which is one of several BIND 9 Manual Pages for some DNS-related programs).

http://dnscurve.org/in-install.html mentions: “a "recursive server" such as dnscache or PowerDNS Recursor or BIND or MaraDNS or Nominum CNS or Unbound”.