short hostname resolution

[Mark Andrews]

> I am setting up a nameserver running on a Redhat 9 box that resides
> on a private network that will NOT utilize NAT.  named starts fine 
> and resolves FQDNs instantly for all clients.  For short hostnames,
> however, name resolution for certain clients such as 'rsh' and 
> 'host' is instant while for other clients such as 'ssh' and 'dig', 
> resolution either involves timeouts before eventually getting an 
> IP address (ssh) or delays followed by eventual failure (dig).
> 
> The domain name for the private network follows the format: 
> <organization>.pvt and all hosts on the private network have a 
> simple /etc/resolv.conf:
> 
> search <organization>.pvt  <my public domain>
> options timeout:5
> nameserver 192.168.9.2
> nameserver 192.168.9.3
> 
> 
> Detailed logging reveals the following frequent pattern but web
> searches on such messages seem to implicate firewalls and NAT.  I'm 
> not using NAT and even hosts on the same subnet as the nameserver 
> suffer. 
> 
> Apr 24 17:39:47.025 fctx 0x80f2f20: too many timeouts, disabling EDNS0
> Apr 24 17:39:47.025 resquery 0x81019c8 (fctx 0x80f2f20): sent
> Apr 24 17:39:47.025 resquery 0x81046c8 (fctx 0x80e5cc8): senddone
> Apr 24 17:39:47.025 resquery 0x81019c8 (fctx 0x80f2f20): senddone
> 
> Stranger still, the detailed logs reveal some dialog with root
> servers even though the nameserver resides on an un-NAT'd private 
> network.
> 
> I have tried BIND 9.3.1, 8.4.6, and the 9.2.1 that ships with 
> Redhat 9 - all result in the same behavior.  I found some stuff on 
> a SCO website claiming named itself can generate packets in 
> response to queries on short hostnames that exceed its own size 
> limits - resulting in reattempts and delays but nothing on ISC's 
> website corroborating these claims.  I use a similar configuration 
> for BIND 9.2.1 on my public class C network with none of this 
> difficulty.  Any and all thoughts appreciated.
> 
> Paul
> 
> 
> -- 
> 
> Paul Daniel
> Owens Valley Radio Observatory
> 
> email:	paul at ovro.caltech.edu
> voice:	760.938.2075 x 130
> street:	OVRO 
>         100 Leighton LN 	
>         Big Pine, CA 93513

	You need to setup your own root zone.

	What is happening is that the resolver continues searching on
	a NODATA response.

	This query sequence is like this:

		short.<organization>.pvt/AAAA	(NODATA continue)
		short/AAAA 			(NXDOMAIN continue)
		short.<organization>.pvt/A	(answer stop)
		short/A

	There is definitly a arguement for making the query sequence
	with skips of the other type on NXDOMAIN.

		short.<organization>.pvt/AAAA	(NODATA continue)
		short.<organization>.pvt/A	(answer stop)
		short/AAAA
		short/A

	There is also a arguement for stopping a single type search
	on NODATA rather then proceeding to try other search list
	elements.  This would make "ssh foo", "ssh -4 foo" and
	"ssh -6 foo" always behave as if you are trying to connect
	to the first foo on the search list.  Currently you may get
	the second depending upon query type / search order.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org