What with having both Linux and Windows clients, and various Linux distributions that like to do things their own way, you’re a bit befuddled as to how to configure them to have dnsmasq give them static IP addresses.
The key to getting static IP addresses from DHCP is for the clients to send their host-names to the DHCP server when they request a lease.
Windows 2000, 2003, and XP clients do this automatically. All you do is configure them for DHCP in the usual manner.
First, on all Linux machines, make sure there is nothing in /etc/hosts other than the localdomain entry.
Most Linux distributions are not configured to send the hostname by default. To fix this, add one line to their DHCP client files. On Debian, this is the /etc/dhcp3/ dhclient.conf file. This example is for the computer named Penguina:
send host-name "penguina";
You must also enter the hostname in /etc/hostname:
Just the hostname and nothing else. Then, set up the normal DHCP configuration in /etc/network/interfaces, like this:
On Fedora, each interface gets its own DHCP client file, like /etc/dhclient-eth1. You may need to create this file. This takes the samesend host-name "penguina";entry. Then, add this line to /etc/sysconfig/network-scripts/ifcfg-eth0:
Make sure theHOSTNAMEline in /etc/sysconfig/network is empty.
The sure way to test your new configurations is to reboot, then run these commands:
Ping will look like this:
carla@xena:~$ ping penguina
The most common cause of problems with this is not configuring the hostname correctly. Check all of your pertinent configuration files.
Here is a complete example Fedora configuration for eth0:
Either edit Fedora configuration files directly, or use the graphical network configurator, but don’t use both because the graphical tool overwrites your manual edits.
dnsmasq automatically enters DHCP clients into DNS. This is a great convenience, and when you deploy IPv6, it will be more than a convenience—it will be a necessity, unless you’re comfortable with remembering and typing those long IPv6 addresses.
dnsmasq combines a lot of complex functions into a short configuration file, and can be used in conjunction with BIND, djbdns, MaraDNS, and other nameservers. Use dnsmasq for your private LAN services, and one of the others for a public authoritative server. This makes it easy to keep the two completely separate, as they should be. Remember the number one DNS server rule: keep your authoritative and caching servers strictly separated, which means using two physically separate network interfaces and different IP addresses. Authoritative servers do not answer queries for other domains; that is the job of a caching resolver like dnsmasq. Maintaining two separate servers might sound like more work, but in practice, it’s easier and safer than trying to configure a single server to handle both jobs.
blog comments powered by Disqus