Using dnsmasq for DNS and DHCP services

Software for providing DNS and DHCP services have typically come from ISC in the form of BIND and dhcpd. While these software packages are quite robust and, for the most part, quite secure, there are other alternatives that may work better depending on your situation. For smaller home or office networks, managing BIND and dhcpd may be overkill.

Another solution that provides both services is dnsmasq, which will cache external DNS addresses, provide local DNS names or override external DNS entries, and also provides dynamic IP addresses in the form of DHCP. It can even provide static IP addresses over DHCP, the same as dhcpd, with the only pre-requisite being the MAC address of the system to assign the static IP to.

Most Linux distributions come with dnsmasq packaged, so it is a simple apt-get, yum, or urpmi away. Otherwise, compiling from source is quite easy. Dnsmasq handles DNS setup differently than BIND and other DNS servers. Everything is configured via a single configuration file, /etc/dnsmasq.conf.

When a request comes in, dnsmasq does not look in zone or similar files; it consults /etc/hosts first and then will look externally for addresses by consulting the name server(s) defined in /etc/resolv.conf. This is a quick and easy way to override external DNS addresses by simply defining them in /etc/hosts on the system that is running dnsmasq.

Dnsmasq also provides DHCP services quite easily. To do so, uncomment and set the following options in /etc/dnsmasq.conf:

expand-hosts

domain=example.com

dhcp-range=192.168.0.50,192.168.0.150,12h

dhcp-option=3,192.168.0.1

This will enable DHCP and set the network domain to “example.com.” The DHCP server will offer addresses between 192.168.0.50 and 192.168.0.150 with a lease of 12 hours. Finally, dhcp-option sets the third (3) DHCP option, which sets the default route, pointing to 192.168.0.1 as the router. There are a lot of dhcp-option values; the configuration file and man pages go through them all with examples.

To set a static IP address for a client, use the dhcp-host keyword:

dhcp-host=11:22:33:44:55:66,foo,192.168.0.10

This will always give the host with the hardware MAC address of 11:22:33:44:55:66 the hostname foo (.example.com) and the IP address 192.168.0.10.

Another useful feature of dnsmasq is that it provides a TFTP server as well. You can enable the TFTP server, point it to the root directory of files to serve, and make use of network booting.

Dnsmasq provides a number of features that make it a compelling replacement for BIND and dhcpd, or any other DNS or DHCP server software you may be using. It can set default MX records, various caching options, a wide variety of DHCP options, SRV records to provide LDAP information, PTR records, SPF records, and even Zeroconf records.

For small office and home networks, dnsmasq is hard to beat in terms of simplicity and power. The configuration file is loaded with examples and information so, while initial setup for a larger network will require a commitment of some time, it is all very straightforward.

Get the PDF version of this tip here.

Source: blogs.techrepublic.com.com/opensource/?p=293

Manage Windows Server 2008 DHCP Servers From Command Line

Installing the DHCP Feature from the Command Line

A Windows Server 2008 system can only act as a DHCP server if the DHCP feature has been installed. This can be achieved from the command prompt using the servermanagercmd utility as follows:

servermanagercmd -install dhcp

[edit] Authorizing DHCP Servers in Active Directory

If a DHCP server is to operate within an Active Directory domain (and is not running on a domain controller) it must first be authorized. This can be achieved either as part of the DHCP Server role installation, or subsequently using either DHCP console or at the command prompt using the netsh tool. To achieve this, open a command prompt and enter the following command:

netsh dhcp server serverID initiate auth

In the above command syntax, serverID is replaced by the IP address or full UNC name of system on which the DHCP server is installed.
[edit] Configuring Scopes at the Command Prompt

DHCP scopes may be configured from the command prompt using the netsh tool. netsh may be run as a single command, or interactively. To run interactively. To run in interactive mode follow these steps:

1. At the command prompt enter netsh.
2. At the netsh> prompt enter dhcp.
3. At the netsh dhcp> prompt enter server \\servername where servername is the UNC name or IP address of the server to be managed. For example:
4. netsh dhcp>server \\winserver-1
5. At the netsh dhcp server prompt, enter the commands to be executed.

Alternatively, run each netsh command separately, using the following syntax:

netsh dhcp server \\servername commands

To create a new DHCP scope the command syntax is as follows:

netsh dhcp server \\servername scope subnetID add iprange startIP endIP

For example, to create a scope on subnet 192.168.2.0 ranging from 192.168.2.1 through 192.168.2.100:

netsh dhcp server \\winserver-1 scope 192.168.2.0 add iprange 192.168.2.1
192.168.2.100

Changed the current scope context to 192.168.2.0 scope.

Command completed successfully.

To list a scope IP address range:

netsh dhcp server \\winserver-1 scope 192.168.2.0 show iprange

Changed the current scope context to 192.168.2.0 scope.

=========================================================
Start Address - End Address - Address type
=========================================================
192.168.2.1 - 192.168.2.100 - DHCP ONLY

Number of IP Ranges : 1 in the Scope : 192.168.2.0.

Command completed successfully.

To delete a scope using netsh:

netsh dhcp server \\winserver-1 scope 192.168.2.0 delete iprange 192.168.2.1
192.168.2.100

Changed the current scope context to 192.168.2.0 scope.

Command completed successfully.

To display the current state of a scope:

netsh dhcp server \\winserver-1 scope 192.168.2.0 show state

Changed the current scope context to 192.168.2.0 scope.

Current State of the Scope 192.168.2.0 : Active

Command completed successfully.

To add an exclude range to a scope:

netsh dhcp server \\winserver-1 scope 192.168.2.0 add excluderange
192.168.2.10 192.168.2.20

Changed the current scope context to 192.168.2.0 scope.

Command completed successfully.

To display an exclude ranges:

netsh dhcp server \\winserver-1 scope 192.168.2.0 show excluderange

Changed the current scope context to 192.168.2.0 scope.

=====================================
Start Address - End Address
=====================================
192.168.2.10 - 192.168.2.20

Number of ExcludeRanges : 1 in the Scope : 192.168.2.0.

Command completed successfully.

To list the clients using a DHCP scope:

netsh dhcp server \\winserver-1 scope 192.168.2.0 show clients

Changed the current scope context to 192.168.2.0 scope.

Type : N - NONE, D - DHCP B - BOOTP, U - UNSPECIFIED, R - RESERVATION IP
==================================================================================
IP Address - Subnet Mask - Unique ID - Lease Expires -Type
==================================================================================


No of Clients(version 4): 0 in the Scope : 192.168.2.0.

Command completed successfully.

[edit] Activating and Deactivating DHCP Scopes using Netsh

DHCP scopes must be activated before they can be used and may also be deactivated at any time. Both of these tasks may be performed at the command prompt using the 'netsh tool. For example, to activate a scope the following command line syntax is used:

netsh dhcp server serverID scope subnetID state status

where serverID is the name or IP address of the computer running the DHCP server, subnetID is the network ID of the subnet on which the scope is to be configured, and status is either 1 or 0 depending on whether the scope is to activated (1) or deactivated (0). On a switched network with multiple virtual networks are hosts on a single network use 2 and 3 respectively to deactivate and activate the scope.
[edit] Terminating a DHCP Lease using Netsh

The lease associated with an IP address may be terminated at the command prompt using the following command syntax:

netsh dhcp server serverID scope subnetID delete lease IPaddress

where serverID is the name or IP address of the computer running the DHCP server, subnetID is the network ID of the subnet on which the IP address resides, and IPaddress is the IP address on which the lease is to be terminated. For example,

netsh dhcp server \\winserver-1 scope 192.168.2.0 delete lease 192.168.2.101

[edit] Configuring DHCP Reservations using Netsh

DHCP reservations provide a mechanism by which IP addresses may be permanently assigned to a specific client based on the MAC address of that client.

The MAC address of a Windows client can be found running the ipconfig /all command. For Linux systems the corresponding command is ifconfig -a. Once the MAC address has been identified, the reservation may be configured using either the DHCP console or at the command prompt using the netsh tool.

To add a reservation using netsh the following syntax is used:

netsh dhcp server \\servername scope subnetID add reservedip IPaddress MacAddress ReservationName Comment

For example the following command reserves an IP address for a specific MAC address (note that the MAC address must be entered without any delimiters):

C:\Users\Administrator>netsh dhcp server \\winserver-2 scope 192.168.2.0 add reservedip
192.168.2.12 0013720B1457 "CEO Printer" "Printer in Exec Suite"

Changed the current scope context to 192.168.2.0 scope.

Command completed successfully.

To list the current reserved IP addresses for a particular scope the following netsh command may be used:

C:\Users\Administrator>netsh dhcp server \\winserver-2 scope 192.168.2.0 show
reservedip

Changed the current scope context to 192.168.2.0 scope.

===============================================================
Reservation Address - Unique ID
===============================================================

192.168.2.10 - 00-0b-db-18-a0-db-
192.168.2.11 - 06-ec-e6-11-47-bd-
192.168.2.12 - 00-13-72-0b-14-57-


No of ReservedIPs : 3 in the Scope : 192.168.2.0.

Command completed successfully.

[edit] Configuring DHCP Conflist Detection

By default, if a DHCP server assigns an IP address to a client which conficts with another client, it is the job of the client to decline the assigned address and request that the DHCP server send another. A faster option is to enable DHCP Conflict Detection on the DHCP server, whereby the server checks that there are no conflicts associated with an IP address before it is assigned to a client. The DHCP server will repeat this process until a valid IP address is found, or a specified number of attempts to find a non-conflicting IP address is reached. The syntax to enable conflict detection and specify the number of retry attempts is as follows:

netsh dhcp server servername set detectionconflictretry no_of_attempts

where servername is the name or IP address of the DHCP server and no_of_attempts is the maximum number of times the DHCP server will attempt to find a non-conflicting IP address. To disable confict detection simpy run the above command setting no_of_attempts to 0. For example:

netsh dhcp server \\winserver-1 set detectionconflictretry 0

[edit] Backing Up and Restoring DHCP Configuration Information

The current configuration of a DHCP server can quickly and easily be saved and restored using the dump option of the netsh tool. This enables a server to be quickly restored to its original state in the case of a system failure, or for the configuration to be duplicated on another server.

For example, to back up the configuration on a local server to a file named DHCPconfig.cfg:

netsh dhcp server dump > DHCPconfig.cfg

The configuration on a remote system may be similarly saved by specifying the name or IP address of the server:

netsh dhcp server winserver-1 dump > DHCPconfig.cfg

Source:techotopia.com/index.php/Managing_a_Windows_Server_2008_DHCP_Server_from_the_Command_Line

DHCP Server Security

Although DHCP servers are critical to the operation of most enterprise networks, DHCP server security is often one of the most overlooked areas of network security. One reason for this might be the simplicity of how DHCP works: DHCP clients broadcast discovery messages (DHCPDISCOVER) containing their MAC addresses and DHCP servers respond by offering (DHCPOFFER) to lease an IP address and other TCP/IP settings that the client can use to communicate on the network. The client responds (DHCPREQUEST) to the first lease offer it receives and the server acknowledges (DHCPACK) the request and marks the address as leased in its DHCP database. That's all there is to it—who needs to worry about security?

Attacking DHCP

Unfortunately it's the very simplicity of DHCP that's actually the problem as far as security goes. No authentication or authorization takes place during an exchange between a DHCP server and DCHP client, so the server has no way of knowing if the client requesting the address is a legitimate client on the network, and the client has no way of knowing if the server that assigned the address is a legitimate DHCP server. The possibility of rogue clients and servers on your network can create all kinds of problems.

For example, a rogue DHCP server could provide legitimate clients with bogus TCP/IP information that prevents the clients from communicating on the network. A denial of service (DoS) condition then results, and users are unable to connect to network resources to perform their work. Setting up a rogue DHCP server could be as simple as conducting a social engineering attack to gain physical access to your network and plugging in a laptop configured as a DHCP server.

Another scenario might involve an attacker compromising a client computer on your network and installing software that repeatedly requests new IP addresses using spoofed MAC addresses until the entire pool of addresses in your DHCP server's scope is leased. When this happens, legitimate clients that boot onto the network can't acquire an address and again users are unable to access the network and can't do their work.

A more sinister result happens when an attacker breaches network security and gains control of your own DHCP servers. At that point the attacker might proceed to modify the DHCP server to assign clients an incorrect subnet setting and thus create another DoS condition. Or they might modify the server to assign clients incorrect DNS settings and redirect clients to rogue or hijacked DNS servers, which could then redirect clients to hostile websites where they unknowingly download a trojan.

Worse yet, if you're running your DHCP server on a domain controller then an attacker who compromises your DHCP server gains access to your accounts database and can cause all sorts of further problems. The result is usually your worst nightmare. Fortunately, there are some measures you can take to protect your DHCP servers and avoid many of these scenarios, provided you're also following all the usual best practices for securing Windows-based networks. Let's look at some specific threats to DHCP on your network and the countermeasures you can take to mitigate these different threats.

Threats and Countermeasures

On the face of it, the requirement that Windows 2000 and Windows Server 2003 DHCP servers be authorized in Active Directory before they can start leasing addresses to requesting clients seems to mitigate the threat of rogue DHCP servers on your network. Authorization means that when a Windows 2000 or Windows Server 2003 DHCP server boots onto an Active Directory network it first contacts a domain controller to check if its own IP address is found on the list of authorized DHCP servers maintained by the domain controller. If the DHCP server determines that it is authorized to lease addresses to clients, it begins to do so. If it's not authorized, Windows shuts down the DHCP Server service on the machine so it won't be able to lease addresses.

The real benefit of this is to protect your network against legitimate DHCP servers that are badly configured, though it has the added side effect of guarding against accidental or rogue DHCP servers running Windows 2000 or Windows Server 2003. What happens though if an attacker compromises your network with a rogue DHCP server not running Windows 2000 or Windows Server 2003? In this case authorization won't help because non-Microsoft DHCP servers may not respond the same way as Microsoft ones to the DHCPINFORM messages Windows uses to check if DHCP servers are authorized.

Rogue clients is another problem entirely though, as DHCP is designed to make it easy for clients to obtain IP addresses so they can participate on a network. The obvious way of dealing with the problem of rogue clients would seem at first to be DHCP reservation, though on large networks this entails considerable administrative overhead. A reservation is a predefined setting that maps a MAC address to an IP address so that only a client with a particular MAC address can lease the IP address associated with that reservation. If security is critical an administrator could create reservations for each and every client machine on the network, and if unreserved IP addresses still remain in the DHCP server's cope then these could be reserved using invalid or non-existing MAC addresses. Then when a rogue client tries to boot on the network the result is that the DHCP server has no free addresses to lease and the client can't connect.

If only it were that simple. While this approach might foil a casual attack, sophisticated attackers have ways for circumventing DHCP reservations. The simplest approach is for the attacker to run a program that listens for DHCPDISCOVER broadcasts from clients and harvests their MAC addresses. Then when a legitimate client shuts down the rogue client can reconfigure its MAC address to match that of the legitimate client and hijack the legitimate client's lease or try to disrupt communications for the client. Considering this, security-conscious administrators might consider dropping DHCP entirely in favor of static addressing, but what's to stop an attacker who has physical access to your network from assigning a static address to their own machine and joining the network?

Via:windowsecurity.com/articles/DHCP-Security-Part1.html

How to reinstall a dynamic DNS Active Directory-integrated zone

Under the following situations you may want to reinstall the dynamic DNS in a Windows 2000 Active Directory:

	Multiple DNS errors have occurred and methods have been unsuccessful.
	Services that depend upon DNS, such as, the File Replication service (FRS) and/or Active Directory are failing. Also, the standard troubleshooting procedures have been unable to locate the exact cause of the problem.
	DNS had been built as a secondary DNS server or files copied from a DNS server do not support dynamic updates.
•	To create a better name space design, such as, splitting the internal and external name spaces.

You have to remove DNS and the DNS cache. Then, you must rebuild one Active Directory DNS server to set up long term stability.

The following steps can remove the defective information in Active Directory-integrated DNS:

	Go to the properties of the DNS zone files and change them to be a "Standard Primary".
	In the %Systemroot%\Winnt\System32\DNS folder, delete the text DNS Zones files.
	Delete the object in Active Directory Users and Computers.
	On the View menu, click Advanced Features, expand the System folder, click MicrosoftDNS, and then delete the zone file objects.
	For each Active Directory-integrated DNS server, repeat steps 1-3.
	In the Transmission Control Protocol/Internet Protocol (TCP/IP) properties of the first Active Directory-integrated DNS server, point it to itself.
	To obtain proper resolution, you must clear the Caching Resolver, which is the DNS client on the DNS server. At the command prompt, type: ipconfig /flushdns.
	Stop and restart DNS and the NetLogon service. Then, remove and re-add the DNS service.

You have completed the process to clear out a DNS server. You must complete the process for any additional DNS servers that you plan to integrate with Active Directory.

The following steps can assist you to build a strong foundation for DNS, Active Directory, and FRS:

	Configure all DNS servers to point to the same DNS server in the domain or forest under TCP/IP properties in DNS: Right-click My Network Places, click Local Area Connection, right-click Local Area Connection, click Properties, select the properties of TCP/IP, and then point all DNS servers to the same DNS server. Also, click the Advanced DNS tab, and then confirm that secondary DNS servers are not configured.
	Re-add the DNS service, or re-add the zones and configure them to be Active Directory integrated. For troubleshooting purposes, you may want to set "Allow Dynamic Updates?" to Yes. Later, you can change this setting to "Allow Only Secure Updates".
	Run the ipconfig /flushdns command, and then run the comand. This command can help you to register your A resource record for DNS as well as your start of authority (SOA). You may want to run this command on any other servers that are critical to you.ipconfig /registerdns NOTE: The Dynamic Host Configuration Protocol (DHCP) client service needs to be running on each of these computers to register the records in Dynamic DNS. It is not relevant if the computer is a DHCP client or not. You must have this service set to "start" and the "Start up" type set to "automatic." The DHCP client service is what registers records in Dynamic DNS. (Refer to the description in the Computer Management snap-in.)
	Active Directory-integrated DNS is now working on your first Dynamic DNS server. You must point additional Dynamic DNS servers to the first DNS server under TCP/IP properties. You must confirm that a full and complete replication process has occurred before you change the TCP/IP properties to point to itself for any additional DNS servers.

Before you configure DNS, you must research the benefits of various DNS name space architectures, such as, internal name spaces, external name spaces, child domains, caching only DNS servers, and reverse look-up zones. Then, you must consider how to develop a design architecture that can work for your organization.

Source:support.microsoft.com/kb/294328