These days most (networked) computers get their IP(v4) settings via DHCP, especially if they are likely to move between multiple networks, such as a laptop. So all my computers, other than the servers I run, get their network settings via DHCP. One of the settings commonly passed over DHCP is the DNS nameservers to use, and the local DNS domain name -- so that the computer has some way to turn names, particularly partially qualified names, into IP addresses to use in contacting other systems.
Historically if you gave the DNS Resolver (client) a name it would:
Decide if it was likely to be fully qualified (eg, contained at least one dot in it), and if so try to find it literally as given (otherwise it'd skip that step)
Try appending the local DNS domain to it (so that if you were on
a network with the domain namefoo.bar.example.comand asked for, eg, "files", it would try to findfiles.foo.bar.example.com(which allows the bare hostname to serve as an alias for local resources)If that didn't work, it'd walk up the local domain name, looking in each parent domain (eg,
bar.example.com,example.com), forfiles.bar.example.com, andfiles.example.comin turn (which allows, eg, short names as aliases for company-wide resources)It would stop when it had tried the version with two parts to the name (
example,com) because it "knew" that there were no hosts to be found any higher up (due to historical global DNS allocation policy; this is no longer true with some of the newer top level domains, eg info)
The same thing would happen if you gave something which was partly
qualified, eg files.sales -- if it wasn't found literally,
it'd then try appending variations on the local domain name to it until
it found it -- which works fairly well in a large company or university
with multiple departments.
Mac OS X still defaults to working like this. (Some other systems changed to, eg, search only the literal full local domain name if nothing else was specified.)
This was a bit inefficient but mostly worked when DNS contained only the minimum of results needed to get the answers, and no extraneous answers (so one could be sure of getting a negative answer when asking for something which didn't exist, and hence move on to the next step). Alas, we do not live in that world any longer.
In New Zealand there's a couple of problems with this process:
The New Zealand TLD (Top Level Domain;
.nz) has its own hierachy, so there are essentially no hosts directly under ".nz", but everything is grouped one level down (eg, ".co.nz", ".net.nz", etc). (Of course virtually no one understands hierachy properly -- hierachy is hard, let's go shopping -- so over 85% of ".nz" names are in ".co.nz" even for things which are not actually companies)Someone (Matthew Hart) has registered
nz.co.nz, and someone else (Garth Piesse) has registeredorg.co.nzand set up a "DNS Redirection" service on it (Garth Piesse also hascom.co.nzbut it is apparently "parked").
The result of this particular combination of unfortunate circumstances
is that Matthew Hart and Garth
Piesse have arranged that if your local domain
name ends in co.nz, and you ask for a name that doesn't
exist that ends in "nz" or "org", the pattern of DNS resolution
attempts will try YOURSTRING.nz.co.nz (or
YOURSTRING.org.co.nz) -- at which point they can give you a
answer, their server, which presumably serves out advertising or does
something else you didn't particularly want. No more "doesn't exist"
answers for you, and DNS stops searching.
DNS Redirection has been fairly controversial, with various ISPs trying it at various times, ever since Network Solutions unleashed SiteFinder on the world several years back -- and then withdrew it after a couple of weeks of strong criticism.
If the only thing on the Internet were HTTP web browsing, done by individual people, who mostly used bookmarks, then the damage would be limited to seeing adverts any time you made a typo or something else went away. But web browsing is by no means the only thing on the Internet. Mostly I kept running into this when trying to log into a host (with ssh), or wondering why I can ping a name but couldn't then interact with it the way I expected -- and the answer turned out to be a combination of a typo or it having gone away, plus these DNS Redirection annoyances.
Over 10 years ago, DNS (client) resolvers were changed to allow specifying an explicit list of suffixes to try (instead of just continually trying parent names), in part as a solution to countries like New Zealand with more hierachy in their domain names than the default algorithm expected and in part because sometimes it is useful to search with suffixes that are not a strict superset of your local domain (eg, if you're frequently working with a partner company). On Unix-like systems this is a "search option in /etc/resolv.conf". A short list of suffixes can be specified, and only those suffixes will be tried explicitly rather than trying to guess likely suffixes.
That avoids stumbling across the sorts of DNS Redirection annoyances that Matthew Hart and Garth Piesse set up (but not ones that are put in place by your ISP -- for that you have to avoid using your ISPs DNS servers, and avoid them intercepting your DNS traffic with a Man in the Middle attack).
But configuring the domain search by hand is painful, especially
on a laptop that moves from network to network frequently and hence
wants different "local resources" to come up by default. Linux has long
supported a hack where you could include a space in the "domain-name"
option and due to the way it was written into the
/etc/resolv.conf and the way that file was parsed, it would
act as a search order (with the first domain listed being treated as the
local network name). (To be precise rather than writing "domain
FOO" it would be written into the file as "search FOO", and the
spaces in FOO would be treated as separators when the DNS resolver read
the file.)
In 2002 Microsoft and Apple proposed a DHCP Extension to allow the DNS Search Order to be set as part of the dynamic setup, which became RFC3397. That way the appropriate search order could be set centrally along with the other DNS and IP information -- and more importantly an appropriate DNS search string could set for each network that you connect to. It took a while, but this was standardised as DHCP Option 119, and is supported by Mac OS X 10.5 (Leopard) and 10.6 (Snow Leopard) and Microsoft Windows 2003 amongst other modern software.
The ISC DHCP Server (commonly used on Unix systems) supports this DNS option starting with version 3.1, with the syntax:
option domain-search "FIRSTSUFFIX", "SECONDSUFFIX";
When added to any appropriate DHCP stanza this would be sent out to the clients. (Not all clients were happy with this extra option arriving.)
This went into Debian Linux in early 2008 (Debian Linux is what I use on my servers), and is in the current stable release of Debian Linux (although I had to back port it to some of my older servers).
I've now set up my DHCP to hand out a sensible search order for my local network, and override the default one built into Mac OS X. So at least on the networks that I control I can be sure that my typos will result in the expected "not found", and I can spot the problem and fix it with much less confusion. And hopefully over time more networks will adopt this sort of solution so there'll be less confusion. (Alas, the moneychangers have well and truely invaded the temple so there seems little hope of avoiding people breaking technical things in order to attempt to earn a little more money -- so we are reliant on technical workarounds.)