conf/90863: [patch] 6.0 boot: name resolution broken for daemon startup

[Garrett Wollman]

The following reply was made to PR conf/90863; it has been noted by GNATS.

From: Garrett Wollman <wollman at csail.mit.edu>
To: JoaoBR <joao at matik.com.br>
Cc: bug-followup at freebsd.org
Subject: Re: conf/90863: [patch] 6.0 boot: name resolution broken for daemon startup
Date: Tue, 27 Dec 2005 17:51:07 -0500

 <<On Tue, 27 Dec 2005 20:29:05 -0200, JoaoBR <joao at matik.com.br> said:
 
 > I think that named is not starting first and so I guess the rc start order is 
 > wrong and not that named do not answer queries, 
 
 No, on my system named definitely is started in the correct order:
 
 wollman at xyz(4)$ echo `rcorder *` | fold -s
 rcconf.sh dumpon initrandom geli gbde encswap ccd swap1 ramdisk early.sh fsck 
 root mountcritlocal var cleanvar random adjkerntz atm1 hostname ipfilter ipnat 
 ipfs kldxref sppp addswap sysctl serial pccard netif isdnd ppp-user ipfw 
 nsswitch ip6addrctl atm2 pfsync pflog pf routing ip6fw network_ipv6 mroute6d 
 route6d mrouted routed dhclient NETWORKING devd mountcritremote devfs ipmon 
 ramdisk-own newsyslog syslogd savecore SERVERS named ntpdate rpcbind nisdomain 
 [...]
 
 The problem seems to be related to the fact that the bge(4) network
 interface in this machine takes a long time bring the link up.  When
 named starts, it attempts to validate the root zone cache before the
 network link comes up, forks, and returns SERVFAIL (?) to all requests
 until it is finally able to validate.  Older versions of named did not
 daemonize until the root zone cache was validated.
 
 This would not be a problem (that's why a server should always have
 another server after itself in /etc/resolv.conf) except that the stub
 resolver considers any reply (even "no I can't do that now") to be
 authoritative.  If named simply failed to respond to these queries,
 the resolver would fail over to the other server.
 
 -GAWollman