|
Monday, June 3, 2002 |
|
Ever found yourself in a networking situation where the DHCP advertised nameserver insists on resolving 'localhost' to something other than 127.0.0.1 (or the vended IP address ofyour machine)? If you have ever stayed in a Fairmont hotel, this is exactly the case on their $10/day high speed Internet service. Very annoying. To further compound the problem, OS X's lookupd is configured to look to DNS to provide host lookups before falling back to NetInfo. Thankfully, this is easily fixed. To ease configuration, this fix adds the Flat File resolving agent into the mix before DNS -- the flat hosts file is very easy to edit. Simply insert: LookupOrder CacheAgent FFAgent NIAgent DNSAgent NILAgent into the file /etc/lookupd/hosts. You may need to create the /etc/lookupd directory first. Once created, either restart your machine or send a HUP signal (kill -1 PID) to lookupd. Add machines, as needed, to /etc/hosts. That file should already have an entry for localhost-- fixing the problem I encountered at the Fairmont-- but you might want to add other hosts, as needed. Note that nslookup (command line tool for querying host names) will always look up a host via DNS. So, even if a host is in /etc/hosts, nslookup will still go to DNS! You can use lookupd to test the configuration:
bbum% lookupd -d If it had gone to DNS, the second line would have started with 'Dictionary: "DNS: ...'.
Over the weekend, I figured out how to advertise a bogus TLD [top level domain] via OS X Server's DNS server. I point all machines within my LAN at the OSXS box for DHCP and, hence, DNS. This allows all machines to share the DNS lookup cache and allows me to have properly advertised machine names for completely private IP network [192.168.1.*] whose IP address to the rest of the world is vended by my cable provider's DHCP server. OSXS is much happier if the server thinks that something somewhere is providing it with an authoritative IP address / name combo. |
Last update: 4/10/03; 17:57:54 .
