I'm still investigating this, but if others have seen evidence of
config files being corrupted when dhclient-script is run I'd like to
hear.

I have two sparc boxes:

NetBSD too 1.5L NetBSD 1.5L (TOO) is an SS20, it is running 1.5
userland.
NetBSD gate 1.5.1_ALPHA NetBSD 1.5.1_ALPHA (GATE) is a classic, also
running 1.5 userland.

On both boxes I've seen /etc/resolv.conf corrupted each time dhclient
renews its lease.  The result is:

root:342# cat /etc/resolv.conf                                                 
search quick.com.au
27 Jan 11:41:50 ntpdate[5817]: ntpdate 4.0.99i Thu Nov 23 01:47:19 MET 2000 (1)
27 Jan 11:41:56 ntpdate[5817]: step time server 203.12.250.1 offset 5.407183 sec
root:343#

Neither machine has softdeps enabled btw.

Now I have a dhclient-exit-hooks which does:


if [ "$new_ntp_servers" ]; then
        for ntp in $new_ntp_servers
        do
                echo server $ntp
        done > /etc/ntp.conf
        if [ "$old_ntp_servers" != "$new_ntp_servers" ]; then
                [ -s /etc/rc_d/ntp ] && /etc/rc_d/ntp stop
                ntpdate -b -v $new_ntp_servers
                [ -s /etc/rc_d/ntp ] && /etc/rc_d/ntp start
        fi
fi
exit 0

which is where ntpdate is being run from.  But 

make_resolv_conf() {
  echo search $new_domain_name >/etc/resolv.conf
  for nameserver in $new_domain_name_servers; do
    echo nameserver $nameserver >>/etc/resolv.conf
  done
}

in dhclient-script is where resolv.conf gets touched.

BTW 

  for nameserver in $new_domain_name_servers; do
    echo nameserver $nameserver 
  done >>/etc/resolv.conf

is better.  Anyway, just how syslog entries from ntpdate reliably end
up in /etc/resolv.conf is unclear, but I can think of some nasty
possibilities. 

I've just fired up my old i486 notebook which is running a 1.5 GENERIC
kernel with the same setup to see if it gets the same problem.

--sjg