How to Configure a Router to Use DHCP

Steps to configure router to use DHCP:

1. Connect to your router (by typing 192.168.0.1 or 192.168.1.1 into the URL bar) and log in. Check your user manual or documentation if you do not know the log-in credentials.

2. Make sure you are in the Setup -> Basic Setup category.

3. Scroll down until you see 'DHCP Server' - if it is disabled, select 'Enable'

4. If you want, you can change the number that the DHCP IP assigning starts. This is optional, and is totally dependant on personal preference.In this picture, the maximum number of DHCP clients is 3. You may need to increase this number according to how many people will need a dynamic IP address on your network. Once the max is reached, no one else can get an address until one expires!

5. Use the DNS servers provided to you by your ISP, or use the following DNS servers: 205.152.37.254, 205.152.132.235, 205.152.132.23; There are many DNS servers out there. It's best to use your ISP's if possible.

6. Scroll down and click 'Save Settings'.

7. Open up the network configurations for the computers on your network (Control Panel -> Network Connections -> Local Area Connection or Wireless Connection) and select 'Obtain IP address automatically'

Related Post:

How to Troubleshoot a DHCP Server?
Installation of DHCP Server in 2008

Source: wikihow

How to Enable DHCP Server Logging?

To enable enhanced DHCP logging, perform the following steps:

1. Start the DHCP administration tool (go to Start, Programs, Administrative Tools, and click DHCP).
2. Right-click the DHCP server, and select Properties from the context menu.
3. Select the General tab.
4. Select the "Enable DHCP audit logging" check box.
5. Click OK.

Windows 2000 will now create a DHCP log file in the %systemroot%\system32\dhcp directory for each day using a DhcpSrvLog.XXX file format.

Common audit codes that might appear in the log include

* 00—The log was started.
* 01—The log was stopped.
* 02—The log was temporarily paused due to low disk space.
* 10—A new IP address was leased to a client.
* 11—A lease was renewed by a client.
* 12—A lease was released by a client.
* 13—An IP address was found to be in use on the network.
* 14—A lease request could not be satisfied because the scope's address pool was exhausted.
* 15—A lease was denied.
* 16—A lease was deleted.
* 17—A lease was expired.
* 20—A BOOTP address was leased to a client.
* 21—A dynamic BOOTP address was leased to a client.
* 22—A BOOTP request could not be satisfied because the scope's address pool for BOOTP was exhausted.
* 23—A BOOTP IP address was deleted after verifying that it wasn't in use.

The DHCP Server uses codes above 50 for Rogue Server Detection information.

windowsitpro.com

Tools for diagnosing server problems remotely

Today I want to talk to you about some ways that you can remotely manage server room and not be dependent on platform or vendors.

IP-based Power Distribution Unit

One way to avoid that inconvenient commute to restart a stalled server is with an IP-based Power Distribution Unit (PDU).

APC makes pretty good IP-based PDUs with nice Web interfaces. If you're looking at other brands, you'll want to make sure they offer the ability to stagger "power-on" timings. This will prevent all the servers from powering on at the same time should there be an extended black-out - possibly tripping the circuits or damaging your servers.

The more advanced models will also display the power drain by outlet or as an entire unit. This could help you diagnose power-related problems remotely, and let you better estimate the load on your UPS.

Serial-IP adapter

Despite the shift towards IP-based appliances, there remains some server room equipment that still requires serial connectivity. The common ones would be your humble analog or GSM modems.

Equinox--now under Avocent--makes serial hubs that can connect directly to your serial-port based devices. The output comes in the form of an Ethernet port that connects to your network. You can install a free software driver on servers that need to access the serial devices, which also transparently creates the appropriate COM port.

Other companies such as Digi International and Axis Communications manufacture and sell such devices as well.

Using a serial hub is superior to the traditional method of installing a PC-based adapter board. Since your serial devices are now on the network, it's very useful in terms of business continuity (BC). Rather than having to run back to the office in the event of a hardware failure to swap out a hardware card or cable, it's now possible to remotely set up another server to take over the serial devices over the network.

Video Extender

The Video Extender is a class of device by itself. It's entirely possible to place a computer monitor as far as 150m away from a server or desktop machine.

Video Extender can prove incredibly useful in a factory or retail setting in which the display has to be placed in a server closet far from the server.

Full info here: http://www.zdnetasia.com/techguide/network/0,3800010800,62038162,00.htm

How to Troubleshoot a DHCP Server?

If you use DHCP servers to automatically configure the TCP/IP settings for workstations in your organization, a DHCP failure can lead to a major disruption in service. After all, if a workstation is not able to acquire an IP address, then it will have no way of accessing any of the resources on your private network or on the Internet. In this article, I will discuss some techniques that you can use to troubleshoot DHCP server failures.

Inappropriate Address Assignment

One very common DHCP related issue is the assignment of an unexpected IP address. For example, suppose that your DHCP server was configured with an IP address scope of 192.168.0.1 to 192.1680.50. You would expect network hosts to be assigned IP addresses in this range. Now, suppose that a workstation on your network appeared to be having problems communicating with network servers. You issue an IPCONFIG /ALL command to view the workstation’s IP address configuration. Instead of the expected address range, the workstation has been assigned an address beginning with 169.254.

So what happened? If a host on your network is unexpectedly assigned an address beginning with 169.254, you can rest assured that the address was not assigned by your DHCP server. What actually has happened, is that the workstation has failed to contact a DHCP server. When this occurs, the workstation will assign itself an IP address using a Windows feature known as Automatic Private IP Addressing (APIPA).

Common DHCP Server Problems

If multiple workstations are experiencing problems with leasing IP addresses, then the problem is most likely related to the DHCP server itself. If you suspect that the DHCP server is the cause of the problem, then you might start off by doing some ping tests to verify that the DHCP server is able to communicate across the network.

If the DHCP server is able to communicate with other computers on the network, then I recommend verifying that the DHCP server has an IP address that is compatible with the scope that the server is configured to assign addresses from. For example, if the DHCP server’s scope consists of addresses from 192.168.0.1 to 192.168.0.50, then the server will not actually be able to assign those addresses unless the server itself has been assigned a static address in the same subnet range, such as 192.168.0.0 or 192.168.0.51.

IP Address Conflicts

Another problem that I have seen on occasions involves IP address conflicts among dynamically configured addresses. When you create a DHCP scope, it is the DHCP server’s responsibility to make sure that addresses within the scope are only leased to one client at a time. If that’s the case, then how is it possible to have an IP address conflict for dynamically assigned addresses?

There are two situations that I’ve run into that can cause this problem. The first time that I ever ran into this problem, I was able to determine which PCs had been assigned at the duplicate addresses. When I checked the TCP/IP configuration on those machines, I found that one of the machine’s IP addresses had been manually configured. It’s kind of a long story, but that machine’s user was running an unauthorized application that required a static IP address. The user got tired of having to reconfigure the application every time they used it, so they took the address that had been dynamically assigned to them, and entered it as a static address.

Full Information here

How to Setup a DNS Server in Ubuntu

Assumptions

Enough with the DNS background. Let’s now start configuring our own DNS server. Let’s assume that we have the following: we want to create a private internal domain name called mydomain.com, our private internal network is 192.168.0.x and our router and gateway is set at 192.168.0.1. Let’s assume all devices are going to be configured with static IP addresses. Normally, most computer systems nowadays are configured to automatically obtain IP addresses from the DHCP server/router. In this example, we will use static IP addresses to show how DNS works. Finally, we have 3 computers connected to our network:

• Ubuntu Server, the DNS server - 192.168.0.9
• Ubuntu Desktop - 192.168.0.10
• PC - 192.168.0.11

Instructions

1. To install the DNS server, we need to install Bind 9.

sudo apt-get install bind9

2. Let’s configure Bind. We need to touch 5 files.

We will edit 3 files.

• /etc/bind/named.conf.local
• /etc/bind/named.conf.options
• /etc/resolv.conf

We will create 2 files.

• /etc/bind/zones/mydomain.com.db
• /etc/bind/zones/rev.0.168.192.in-addr.arpa

A. First step. Lets add our domain zone - mydomain.com.

sudo vi /etc/bind/named.conf.local

# Our domain zone
zone "mydomain.com" {
 type master;
 file "/etc/bind/zones/mydomain.com.db";
};

# For reverse DNS 
zone "0.168.192.in-addr.arpa" {
 type master;
 file "/etc/bind/zones/rev.0.168.192.in-addr.arpa";
};

Save file. Exit.

We just created a new domain. Please note: later we will create two files named mydomain.com.db and rev.0.168.192.in-addr.arpa files. Also, notice the reverse IP address sequence in the reverse DNS section.

B. Let’s add the DNS servers from your ISP. In my case, I’m using Comcast DNS servers. You can place the primary and secondary DNS servers here separated by semicolons.

sudo vi /etc/bind/named.conf.options

forwarders {
 68.87.76.178;
};

Save file. Exit.

C. Now, let’s modify the resolv.conf file found in /etc and place the IP address of our DNS server which is set to 192.168.0.9.

$ sudo vi /etc/resolv.conf

search mydomain.com.
nameserver 192.168.0.9

D. Now, let’s define the zones.

sudo mkdir /etc/bind/zones
sudo vi /etc/bind/zones/mydomain.com.db

$TTL 3D
@ IN SOA ns.mydomain.com. admin.mydomain.com. (
 2007062001
 28800
 3600
 604800
 38400
);
mydomain.com.  IN      NS         ns.mydomain.com.
ubuntudesktop  IN      A          192.168.0.10
www            IN      CNAME      ubuntudesktop
pc             IN      A          192.168.0.11
gw             IN      A          192.168.0.1
                     TXT        "Network Gateway"

The TTL or time to live is set for 3 days
The ns.mydomain.com nameserver is defined
ubuntudesktop, pc and gateway are entered as an A record
An alias of www is assigned to ubuntudesktop using CNAME

E. Let’s create a “rev.0.168.192.in-addr.arpa” file for reverse lookup.

sudo vi /etc/bind/zones/rev.0.168.192.in-addr.arpa

$TTL 3D
@       IN      SOA     ns.mydomain.com. admin.mydomain.com. (
              2007062001
              28800
              604800
              604800
              86400
)
      IN      NS      ns.mydomain.com.
1       IN      PTR     gw.mydomain.com.
10      IN      PTR     ubuntudesktop.mydomain.com.
11      IN      PTR     pc.mydomain.com.

3. Let’s restart Bind to activate our latest changes.

sudo /etc/init.d/bind9 restart

4. Finally, let’s test our new domain and DNS entries.

Dig

$ dig mydomain.com

Nslookup

nslookup gw

5. That’s it.

Source

Howto find DNS Server Version remotely using fpdns

A nameserver basically responds to a query. Interoperability is an obvious requirement here. The standard protocol behaviour of different DNS implementations is expected to be the same.

The reality is quite different though. fpdns uses a series of borderline DNS queries to determine the vendor, product and version of a nameserver.

A nameserver basically responds to a query. Interoperability is an obvious requirement here. The standard protocol behaviour of different DNS implementations is expected to be the same.

Requirements for protocol behaviour of DNS implementations is widely documented in the case of ‘common’ dns messages. The DNS protocol is over 20 years old and since its inception, there have been over 40 independent DNS implementations, while some implementations have over 20 versions.

The methodology used to identify individual nameserver implementations is based on “borderline” protocol behaviour. The DNS protocol offers a multitude of message bits, response types, opcodes, classes, query types and label types in a fashion that makes some mutually exclusive while some are not used in a query messages at all. Not every implementation offers the full set of features the DNS protocol set currently has. Some implementations offer features outside the protocol set, and there are implementations that do not conform to standards.

Also, new features added to - or bugs removed allow for differentiations between versions of an implementation.

Install fpdns in Ubuntu

sudo aptitude install fpdns

This will complete the installation

Using fpdns

fpdns [-c] [-d] [-f] [-p port] [-Q srcaddr] [-r retry] [-s] [-t timeout] [-v] server

Where: server is an ip address or a resolvable name
or ‘-’ to read list of servers from stdin
-c (where appropriate check CH TXT version) [off]
-d (debug) [off]
-f (force check CH TXT version) [off]
-F (maximum forked processes) [10]
-p port (nameserver is on this port) [53]
-Q srcaddr (source IP address) [0.0.0.0]
-r retry (set number of attempts) [1]
-s (short form) [off]
-t time (set query timeout) [5]
-v (show version)

fpdns Examples

BIND Version 8 Example

fpdns -D google.com

fingerprint (google.com, 216.239.34.10): ISC BIND 8.3.0-RC1 — 8.4.4
fingerprint (google.com, 216.239.36.10): ISC BIND 8.3.0-RC1 — 8.4.4
fingerprint (google.com, 216.239.38.10): ISC BIND 8.3.0-RC1 — 8.4.4
fingerprint (google.com, 216.239.32.10): ISC BIND 8.3.0-RC1 — 8.4.4

BIND Version 9 Example

fpdns -D debianhelp.co.uk

fingerprint (debianhelp.co.uk, 212.67.202.2): ISC BIND 9.2.3rc1 — 9.4.0a0 [recursion enabled]
fingerprint (debianhelp.co.uk, 212.67.203.246): ISC BIND 9.2.3rc1 — 9.4.0a0 [recursion enabled]

TinyDNS Example

fpdns ns1.eu.dedicatedserver.com.

fingerprint (ns1.eu.dedicatedserver.com., 213.198.65.226): DJ Bernstein TinyDNS 1.05

Microsoft windows 2003 Example
fpdns -D microsoft.com

Source: http://www.ubuntugeek.com/howto-find-dns-server-version-remotely-using-fpdns-fingerprinting-dns-servers.html

DNS Servers Are Under Fire

The number and severity of domain name service server attacks have risen sharply on networks around the globe, as phishers, pharmers and other malicious code writers embrace the latest way to circumvent traditional forms of mitigation.

Sandvine has observed an increase in server attacks, particularly DNS attacks on broadband networks. DNS server are suddenly overwhelmed by a glut of spoofed DNS requests and responses, causing the server to process requests slower and slower until it eventually fails entirely - impacting subscribers' ability to use the Internet for the duration of the attack.

Sandvine Security Operations Services team has identified increases where single attackers performed over 1000 times the normal amount of lookups on a DNS server in a 12-hour period. These attackers are engaging in a form of DNS attack called DNS poisoning - the act of tainting the server's cache with incorrect routing information so illegitimate sites appear in a browser despite a legitimate web address being requested.

One successful poisoning attempt could affect many thousands of users, and result in droves of subscribers being taken to exploitive sites that bilk them of their personal information, steal their identity, download malware (worms, spyware, adware, etc.) onto their computers, or bombard them with irrelevant advertisements - even though they typed in the correct URL into their browser or followed the right hyperlink. Poisoning can be accomplished by individual computers or by networks of 'zombie' computers directly on the ISP's network or spread around the world.

As threatening as DNS attacks and poisoning are to the personal- information integrity of subscribers, the damage is compounded for broadband service provider networks. DNS attacks are responsible for overwhelming DNS servers to the point of failure, causing massive, wide-scale service outages. This results in subscriber churn, destroys brand equity, and can cost millions in subscriber refunds, not to mention the substantial financial burden of trying to identify and alleviate the problem.

"Broadband service providers must protect their network and subscribers with multi-layered, network-based approaches," said Don Bowman, VP, Consulting Systems Engineering, Sandvine Incorporated. "Attacks and malicious code are becoming more and more evasive and targeted. Service providers need to proactively monitor their networks for threats and respond in real-time to shut down these attacks."

Source: http://news.softpedia.com/news/DNS-Servers-Are-Under-Fire-2226.shtml