Don't try DNS at home! :-)

Mon Apr 26 03:10:01 UTC 2004

I am in BIG trouble, and I hope somebody out there
in DNS land can help me.

Mac OS 10.3.3 comes with BIND 9.2.2 installed but
"turned off."

I installed the Squid proxy which for reasons unknown
to me, refuses to run unless it can contact a DNS server.
(Since I use PPP/dialup, most of the time there is no
DNS server and Squid complains and quits.)  man squid
says that squid -D "disables initial DNS tests" but
squid still complains it can't find a DNS server and quits.

I look at the Apple-supplied files for BIND.  They look to
me to be appropriate for caching-only, so I turn it on,
and put 127.0.0.1 at the top of the list(s) for nameservers.

ping, host, nslookup, dig, web browser, telnet, news client, etc.
all work by name or by number.  But Squid STILL complains and quits!
So I figure, if it doesn't fix Squid, I may as well turn it off again.
So I turn it off, and remove 127.0.0.1 from the lists and NOTHING works
by name, though they still work by number.  Except 'host' which complains
it can't find any servers.  IF I put the IP of the alternate server
as the second parameter to host, it works, but if I put that IP first
on the list, it doesn't work, nor did it try that guy when the first
failed.  In other words, when I put everything back exactly as it was
before running named, they are no longer able to get resolutions from
the servers they used before!

Moral of the story is DNS is addictive--once you start you can't stop.  :-)

Seriously, keeping named running is not a major problem, but there's
one more gotcha:  I was running tcpdump to sniff out another problem, and I 
noticed that with an NNTP client (Thunderbird) running, even though it
only knows about ONE server and was neither fetching nor sending anything,
there was DNS traffic to EVERYWHERE, about fifty messages per second.

I did make one change to the config files.  My syslog complained
as shown below, so I commented out the section in named.conf that
mentions that file, i.e.
// controls {
//     inet 127.0.0.1 port 54 allow {any; };
// };
but the complaints still occur, though they do not
prevent DNS from working.

Apr 25 19:26:06 localhost named[22210]: starting BIND 9.2.2
Apr 25 19:26:06 localhost named[22210]: using 1 CPU
Apr 25 19:26:06 localhost named[22210]: loading configuration from 
'/private/etc/named.conf'
Apr 25 19:26:06 localhost named[22210]: listening on IPv4 interface lo0, 
127.0.0.1#53
Apr 25 19:26:06 localhost named[22210]: listening on IPv4 interface en0, 
192.168.87.99#53
Apr 25 19:26:06 localhost named[22210]: listening on IPv4 interface ppp0, 
69.9.86.42#53
==== HERE =====
Apr 25 19:26:06 localhost named[22210]: none:0: open: 
/private/etc/rndc.key: file not found
Apr 25 19:26:06 localhost named[22210]: couldn't add command channel 
127.0.0.1#953: file not found
Apr 25 19:26:06 localhost named[22210]: none:0: open: 
/private/etc/rndc.key: file not found
Apr 25 19:26:06 localhost named[22210]: couldn't add command channel 
::1#953: file not found
Apr 25 19:26:06 localhost named[22210]: zone 0.0.127.in-addr.arpa/IN: 
loaded serial 1997022700
Apr 25 19:26:06 localhost named[22210]: zone localhost/IN: loaded serial 42
Apr 25 19:26:06 localhost named[22210]: running

Then here are some other syslog bits.  Does this mean others found
out somehow that I'm running and are asking me for resolutions?
I don't mind it listening for answers on ppp0 but I don't want it
listening for queries!

Apr 25 19:39:49 localhost named[22210]: lame server resolving 
'kr2ld.dacom.co.kr' (in 'dacom.co.kr'?): 211.216.50.150#53
Apr 25 19:39:49 localhost named[22210]: lame server resolving 
'usns.dacom.co.kr' (in 'dacom.co.kr'?): 211.216.50.150#53
Apr 25 20:26:06 localhost named[22210]: no longer listening on 69.9.86.42#53
Apr 25 21:02:12 localhost named[22210]: lame server resolving 
'sdf.lonestar.org' (in 'LONESTAR.org'?): 216.87.155.110#53
Apr 25 21:23:11 localhost named[22210]: lame server resolving 
'194.162.162.194.in-addr.arpa' (in '162.194.in-addr.arpa'?): 198.6.1.65#53
Apr 25 21:25:13 localhost named[22210]: lame server resolving 
'140.31.12.202.in-addr.arpa' (in '31.12.202.in-addr.arpa'?): 202.12.28.140#53
Apr 25 21:26:06 localhost named[22210]: listening on IPv4 interface ppp0, 
69.9.86.39#53
Apr 25 21:27:17 localhost named[22210]: lame server resolving 
'11.202.16.192.in-addr.arpa' (in '202.16.192.in-addr.arpa'?): 137.39.1.3#53
Apr 25 21:27:36 localhost named[22210]: lame server resolving 
'4.0.0.0.0.0.0.0.0.0.0.0.3.5.0.0.0.0.0.0.0.4.2.0.0.1.6.0.1.0.0.2.ip6.arpa' 
(in '4.2.0.0.1.6.0.1.0.0.2.ip6.arpa'?): 192.149.252.21#53
Apr 25 21:27:38 localhost named[22210]: lame server resolving 
'4.0.0.0.0.0.0.0.0.0.0.0.3.5.0.0.0.0.0.0.0.4.2.0.0.1.6.0.1.0.0.2.ip6.arpa' 
(in '4.2.0.0.1.6.0.1.0.0.2.ip6.arpa'?): 192.149.252.22#53
Apr 25 21:31:39 localhost named[22210]: lame server resolving 
'33.144.116.198.in-addr.arpa' (in '116.198.in-addr.arpa'?): 128.102.16.2#53
Apr 25 21:31:44 localhost named[22210]: lame server resolving 
'3.191.91.139.in-addr.arpa' (in '91.139.in-addr.arpa'?): 139.91.1.1#53
Apr 25 21:31:45 localhost named[22210]: lame server resolving 
'1.1.91.139.in-addr.arpa' (in '1.91.139.in-addr.arpa'?): 139.91.1.1#53
Apr 25 21:31:46 localhost named[22210]: lame server resolving 
'70.151.91.139.in-addr.arpa' (in '151.91.139.in-addr.arpa'?): 139.91.1.1#53
Apr 25 21:31:53 localhost named[22210]: lame server resolving 
'1.16.52.147.in-addr.arpa' (in '52.147.in-addr.arpa'?): 139.91.1.1#53

-- 
Wes Groleau
   ----
   The man who reads nothing at all is better educated
   than the man who reads nothing but newspapers.
                             -- Thomas Jefferson