Need for DNS? - Page 2

[knsljo]

I'm also still having this problem:

all scopes for dhcp clients fluded with bad_address
entries.
My DHCP server is Win 2003 standard with only one network
interface enabled. And there is 5 conflict detection attempt
configured. All knowlege base articles that i found out
does not match my situation.
And very interesting that all this bad_address appears
with 6-bytes Unique Identifier, when all other clients
have MAC address as Unique Identifier.
Did anybody know what is the possible reason of such
behaviour?

You must have an ip conflict on the client side. A bad address entry is entered When a third-party Dynamic Host Configuration Protocol (DHCP) client detects that the Transport Control Protocol/Internet Protocol (TCP/IP) address received from a DHCP server already exists on the Local Area Network (LAN), the DHCP client may send a DHCP decline message to the DHCP server. This would be the BAD_ADDRESS message you are getting. You will need to go to all clients and cross reference there ip's this includes network printers, routers, switches anything that could have a static or dynamic address on the network.

[Duki]

You must have an ip conflict on the client side. A bad address entry is entered When a third-party Dynamic Host Configuration Protocol (DHCP) client detects that the Transport Control Protocol/Internet Protocol (TCP/IP) address received from a DHCP server already exists on the Local Area Network (LAN), the DHCP client may send a DHCP decline message to the DHCP server. This would be the BAD_ADDRESS message you are getting. You will need to go to all clients and cross reference there ip's this includes network printers, routers, switches anything that could have a static or dynamic address on the network.

But what would cause 130+ BAD_ADDRESS entries when we only have roughly 25 computers?

[knsljo]

But what would cause 130+ BAD_ADDRESS entries when we only have roughly 25 computers?

Not too sure it sounds like some sort of loop it could be that you have 2 dhcp servers running but you don't know. You really must check every- thing on your network again, the answer is there you just haven't looked at everything yet.

i found this article might help with one or two of your problems::lol:

On Windows-based networks, DHCP and DNS can work together to simplify the configuration and operation of your network. Normally what happens is a DHCP client register its A (host) record directly with the DNS server, while the PTR (pointer) record is instead registered on behalf of the client by the DHCP server. This means an attack on a DHCP server could compromise control over records registered with your DNS server and be used to redirect traffic to a hostile site or cause denial of service. If you make a DHCP server a member of the DNSUpdateProxy group however, your DHCP server will not take ownership of any resource records it registers on behalf of clients. This approach is typically used when upgrading from Windows NT to ensure downlevel clients that do not support DDNS can take ownership of their own resource records when they are upgraded to Windows 2000 or Windows XP.

The point is that you should only add the computer accounts for your DHCP server to the DNSUpdateProxy group if you are going to be upgrading pre-Windows 2000 computers to Windows 2000 or Windows XP. And you should never add your DHCP server to this DNSUpdateProxy group if your DHCP server is running on a domain controller.

Detecting Rogue DHCP Servers

Finally, there are a few tools you can use to detect the presence of rogue DHCP servers on your network so you can get rid of them. These include both tools from Microsoft and from third-party sources, and we'll end by examining two of these tools.

Dhcploc.exe

Dhcploc.exe is a command-line tool that is part of the Windows Support Tools found in the \Support\Tools folder on your Windows XP product CD and it can be used to display all DHCP servers that are active on the local subnet. Dhcploc.exe has been around since Windows NT 4.0 and it works by sending out DHCPREQUEST messages and displaying the IP addresses of the DHCP servers that responded with DHCPACK. You can find the syntax of this tool in the Help file that is installed when you install the Support Tools on your machine.

dhcp_probe

The Network Systems Group at Princeton University's Office of Information Technology has developed a tool called dhcp_probe that tries to discover DHCP and BOOTP servers on a directly-attached Ethernet network. The existing build runs on Solaris 8 on SPARC with gcc and there is patch for it to work on Linux also, so if you have either of those platforms you can try using this tool to detect any rogue DHCP servers that might be running on your network. You can find the Network Systems Group's tools page here and can download dhcp_probe directly from here.

hope this helps.

[Duki]

Not too sure it sounds like some sort of loop it could be that you have 2 dhcp servers running but you don't know. You really must check every- thing on your network again, the answer is there you just haven't looked at everything yet.

i found this article might help with one or two of your problems::lol:

On Windows-based networks, DHCP and DNS can work together to simplify the configuration and operation of your network. Normally what happens is a DHCP client register its A (host) record directly with the DNS server, while the PTR (pointer) record is instead registered on behalf of the client by the DHCP server. This means an attack on a DHCP server could compromise control over records registered with your DNS server and be used to redirect traffic to a hostile site or cause denial of service. If you make a DHCP server a member of the DNSUpdateProxy group however, your DHCP server will not take ownership of any resource records it registers on behalf of clients. This approach is typically used when upgrading from Windows NT to ensure downlevel clients that do not support DDNS can take ownership of their own resource records when they are upgraded to Windows 2000 or Windows XP.

The point is that you should only add the computer accounts for your DHCP server to the DNSUpdateProxy group if you are going to be upgrading pre-Windows 2000 computers to Windows 2000 or Windows XP. And you should never add your DHCP server to this DNSUpdateProxy group if your DHCP server is running on a domain controller.

Detecting Rogue DHCP Servers

Finally, there are a few tools you can use to detect the presence of rogue DHCP servers on your network so you can get rid of them. These include both tools from Microsoft and from third-party sources, and we'll end by examining two of these tools.

Dhcploc.exe

Dhcploc.exe is a command-line tool that is part of the Windows Support Tools found in the \Support\Tools folder on your Windows XP product CD and it can be used to display all DHCP servers that are active on the local subnet. Dhcploc.exe has been around since Windows NT 4.0 and it works by sending out DHCPREQUEST messages and displaying the IP addresses of the DHCP servers that responded with DHCPACK. You can find the syntax of this tool in the Help file that is installed when you install the Support Tools on your machine.

dhcp_probe

The Network Systems Group at Princeton University's Office of Information Technology has developed a tool called dhcp_probe that tries to discover DHCP and BOOTP servers on a directly-attached Ethernet network. The existing build runs on Solaris 8 on SPARC with gcc and there is patch for it to work on Linux also, so if you have either of those platforms you can try using this tool to detect any rogue DHCP servers that might be running on your network. You can find the Network Systems Group's tools page here and can download dhcp_probe directly from here.

hope this helps.

dang, when I read about dhcploc I got excited... only to find out that one 2 different computers the command gives me an error and asks to send error report. I can type dhcploc and it tells me the usage, but when i use dhcploc -p it comes up with send error report and then ends the command. :sad:

I've checked just about everything, and the odds of something coming with DHCP enabled for the 192.168.0.x range is rare as it is. Usually it's 192.168.1.x but my DNS isn't working correctly either. There's a ay to get it to register A records automatically, and it's not doing it.