Whatever you want to call it, I'm a firm believer that this should work:

% cat /etc/resolv.conf
search example.com
nameserver 192.0.2.10
% host foo.bar.baz.example.com.
foo.bar.baz.example.com has address 192.0.2.1
foo.bar.baz.example.com has IPv6 address 2001:db8::1
% host foo.bar.baz
foo.bar.baz.example.com has address 192.0.2.1
foo.bar.baz.example.com has IPv6 address 2001:db8::1

Unfortunately, it seems like most operating systems are starting to break this by not appending the search prefix to short names that contain dots.  Windows and Mac OS X have changed to this broken behavior by default and now require obscure tweaks to get the correct behavior back.

Now, since Linux lately is becoming a wannabe Mac OS X, it apparently now suffers from the same issue:

(destiny:22:08)% host nox.ext.prolixium.com.
nox.ext.prolixium.com has address 64.16.214.60
(destiny:22:08)% host nox.ext               
Host nox.ext not found: 3(NXDOMAIN)
(destiny:22:08)% cat /etc/resolv.conf
search prolixium.com
nameserver 10.3.5.1
nameserver 10.3.4.17

We can see that the resolver libraries aren't bothering to append prolixium.com. to nox.ext in the second query:

22:08:45.103912 IP 10.3.5.107.57313 > 10.3.5.1.53: 28936+ A? nox.ext.prolixium.com. (39)
22:08:45.104274 IP 10.3.5.1.53 > 10.3.5.107.57313: 28936* 1/7/14 A 64.16.214.60 (507)
22:08:45.104703 IP 10.3.5.107.57958 > 10.3.5.1.53: 13808+ AAAA? nox.ext.prolixium.com. (39)
22:08:45.104970 IP 10.3.5.1.53 > 10.3.5.107.57958: 13808* 0/1/0 (108)
22:08:45.105245 IP 10.3.5.107.44277 > 10.3.5.1.53: 55206+ MX? nox.ext.prolixium.com. (39)
22:08:45.105450 IP 10.3.5.1.53 > 10.3.5.107.44277: 55206* 0/1/0 (108)
22:08:46.946125 IP 10.3.5.107.51518 > 10.3.5.1.53: 38662+ A? nox.ext. (25)
22:08:46.946415 IP 10.3.5.1.53 > 10.3.5.107.51518: 38662 NXDomain 0/1/0 (100)

However, I've got another machine sitting here that's running the same version of libc-bin (2.19-7) and does work.  I'm failing to identify the delta between these machines.

Is this a bug?  Is this expected behavior?  How do I fix it?  No, the "ndots" parameter for /etc/resolv.conf is irrelevant.

Update: As some folks have pointed out, the reliance of short names even on controlled networks is being discouraged due to the new ICANN TLDs.  I've been aware of the consequences of using short names and the potential for blackholing legitimate external sites using these new TLDs and still believe I should be able to use the legacy resolver behavior.  If there's another way of not having to type example.com a million times per day, though, I'm all ears!

Update 2: After a post I made to debian-user I realized that the ndots parameter is not irrelevant and fixed my issue.  However, changing it shouldn't have fixed the issue because the defaults (I checked the source) are ndots:4.

Update 3: I'm an idiot.  I wasn't using anything other than host(1) to do testing.  host(1) implements its own resolver library and reads /etc/resolv.conf itself.  Apparently something changed in host(1), but didn't impact anything else!  Case closed!

New comments are currently disabled for this entry.