I've been having a lot of trouble recently with the nameserver on snv_101b (and
earlier). Specifically, during the install/upgrade process, the
/etc/resolv.conf is changed to look like:
search object-craft.com.au
domain object-craft.com.au
nameserver 192.168.0.3
According the DNS and Bind book, the "search" and "domain" directives are
mutually exclusive. Bind enforces this by making the one that appears last
override the other.
As a result, the search domain is set to "object-craft.com.au" and "com.au".
For domains with less dots in them, ndots probably forestalls this happening,
ie, frobozz.com doesn't set the search path to "frobozz.com" and "com".
That works fine usually except when I try to reference "localhost". Some bozo
has registered "localhost.com.au" so that is discovered before the resolver
falls back to the localhost entry in /etc/hosts.
This was a very frustrating bug to try to find. The main symptom was that
postgres was refusing to connect to db running on localhost. Postgres appeared
to be running. And localhost was reachable:
2 $ ping localhost
localhost is alive
The light only went on when I ran:
3 $ ping -s localhost
PING localhost: 56 data bytes
64 bytes from apache2-zoo.pandora.dreamhost.com (208.113.201.226): icmp_seq=0.
time=217.313 ms
64 bytes from apache2-zoo.pandora.dreamhost.com (208.113.201.226): icmp_seq=1.
time=232.249 ms
And then discovered that localhost.com.au was a CNAME for
apache2-zoo.pandora.dreamhost.com.
The best solution is to delete the "domain" directive from /etc/resolv.conf and
then restart the network stack (svcadm restart net). I think some part of the
"pkg image-update" command will restore the resolv.conf to its broken state
when it updates the system so it's liable to break again.
I've wasted a stupid amount of time tracking this down.
Ben.
--
This message posted from opensolaris.org
