Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'll try to explain my problem as clearly as possible. We just migrated from Novell eDir and files/print server to Microsoft AD and files/print server. Our domain is integrated into a regional forest. We're a NAT network, LAN it's a and on WAN it's a network.

Actually, we got rogue Windows DNS and DHCP services. I'm to configure DNS and DHCP services into the domain.

Some users have to work on other sites with different domain (in the same forest) so they bring their laptop and authenticated themselve on our DC (domain).

My first tests went well (tests done locally), everything works as expected. The problems starting to occurs when users have to switch sites. While our DNS was empty, adresses resolution were done by sites DNS. Per example, Lotus Notes server is already known as 10.140.x.x outside and users on other sites was able to access those services.

Now, since I put entry in the domain's DNS, those were resolve as 172.16.x.x. (and unreachable outside LAN).

In attempt to resolve this I multihome some servers with 172.16.x.x and 10.140.x.x IP, unchecked the round robin option on DNS to force the subnet ordering. But on LAN, if I do a nslookup multihomed_name I receive IP in this order : 10.140.x.x, 172.16.x.x.

Maybe there's something I don't understand. I expected to receive first the 172.x.x.x Ip since I'm on a 172.x.x.x network. Does can be an issue of how the DHCP's scope are designed (4 vlan's with /23 mask) ?

Anybody can point me where I'm wrong.

share|improve this question
lol not asking for much are we, anyway to start fix this issue "Actually, we got rogue Windows DNS and DHCP services". As to this question "Maybe there's something I don't understand." I'd say there is more that you don't understand then do. – tony roth Jun 4 '13 at 16:29
By the way, tests and issue are not with the "rogue" setup but on the domain integrated setup. – Patrick Pellegrino Jun 4 '13 at 17:23
Unfortuantely if the rogue servers remain it won't matter what you do with the domain intergrated services. Just because a dhcp is authorized does not preclude another dhcp from interfering with dhcp clients. – tony roth Jun 4 '13 at 17:34
My tests computers are on different vlan than my prod. Using ip helper-adress, dhcp broadcast are redirect to the domain dhcp, this test scope exist only on my domain dhcp on wich I can see my computers lease. – Patrick Pellegrino Jun 4 '13 at 17:42
Just so you know ip helper address configurations do not prevent rogue servers from causing problems. Given that I don't even think this (dhcp) is your problem but its a tip of the iceberg thing. – tony roth Jun 4 '13 at 17:59

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.