Link to home
Start Free TrialLog in
Avatar of PtboGiser
PtboGiserFlag for Canada

asked on

How to prevent additional network adapter IP's from populating in DNS on domain controller?

We have one server that exists outside our cluster which we use for many back-end tasks, but most importantly, it acts as a backup Active Directory Domain Controller in case the cluster ever goes down.  The problem is, that it has to have 2 additional network cards so it can communicate on our Storage and Voice Vlans, as well as our computer Vlan.  Because of this, it automatically, and continually populates all 3 of it's IP addresses in DNS.

I have disabled registering of DNS of the two additional network cards, yet their addresses keep appearing.  This is interfering with AD replication.

Can someone advise how I can stop the two additional network cards from populating these extra DNS entries for that server?
Avatar of jakethecatuk
jakethecatuk
Flag of United Kingdom of Great Britain and Northern Ireland image

have you configured your server to only listen to DNS on your main IP address?

make sure that you don't have your additional IP addresses under sites and services configured
Avatar of Krzysztof Pytko
I would strongly suggest following an article on MVP blog for multihomed DCs at
http://msmvps.com/blogs/acefekay/archive/2009/08/17/multihomed-dcs-with-dns-rras-and-or-pppoe-adapters.aspx

When you follow those steps, you should be OK

Regards,
Krzysztof
Avatar of PtboGiser

ASKER

Thanks, I will go through it and get back.  In the mean time though, this article seems to be geared towards server 2003 (possibly even server 2000).  Do you have anything updated for Server 2008?  I understand the principle should be the same, but for example, unless I'm mistaken, there is no binding order anymore in server 2008...or if there is, it's not in the same place.
In DHCP properties on Advanced tab over "Bindings" button
So, generally, the same place :)

Krzysztof
ASKER CERTIFIED SOLUTION
Avatar of Darius Ghassem
Darius Ghassem
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Simple, dont every use a multi-homed server as an ad server. It causes far too many problems. Use that server for the other purposes you need and if you need another DC outside of your cluster then install another server soley for that purpose.
Ok, doublechecked that DNS registering is disabled, and it is.  I disabled bios, I found the bindings, and moved corrected a mis-ordering there.  But I think the root of the problem is disabling DNS listening on the other adapters.  I had thought of that alread, and fixed it to only listen on the correct adapter, but when I double-checked after your suggestions, it was set back to all adapters.  I found a suggestion to stop and restart DNS after adjusting the setting, so I did that and rechecked, and it was set to only listen on the correct adapter, the extra DNS entries were gone.  So I rebooted that server, and the setting changed back to listen on all adapters.

Any ideas why Server 2008 R2 would 'forget' that setting on reboot?
You should not forget the settings I have multiple with one IP address listed without issues.

Do a Windows Update to make sure you are fully updated.

The solution really is not to use multihomed Domain Controllers.
Yes, I understand that it is bad practice to use a multi-homed DC, however I am very close.  If I can figure out why this setting gets wiped to default on reboot, I will be good to go.  I just tried running the dnscmd <servername> /resetlist....etc command, and will try rebooting again later.  Does anyone have any other ideas why the setting won't stick, or suggestions to make it do so?
Setting should stick.

So, when you select the IP address you want to listen on the setting is saved, right? But when you reboot it is removed?

The binding orders are setup properly, right?
Yes, the settings is saved.  I can stop and restart the DNS service, and it is still saved.  But when I reboot, it gets set back to listen on all.  Yes, I adjusted the binding order to put the correct IP (the one I want DNS to listen on) on top, I did that before the last two reboots that both cleared the listen setting..... :(
What are the Network Card settings? Are they Domain?
Not sure exactly what you mean, but in Network and Shareing Center, it specifies our domain name.  Server IP is set statically, with DNS pointing at itself, and the loopback.  The other two adapters have only IP and mask, no gateway or DNS.
The problem is, that it has to have 2 additional network cards so it can communicate on our Storage and Voice Vlans, as well as our computer Vlan.

That is not a valid reason to have multiple Nics.  The Networks should all have are Router or Routers between them.  So the server would have only one Nic (the right one it would need) and would communicate to those other segments.  Not having the routability between the segment is a design flaw in the LAN as far as I am concerned.   The problem is just snow-balling when you create a second design flaw (multi-homed DC) to cover up the first design flaw (non-routability).

I am aware of Ace's article that was given above (Ace is a friend of mine) but I will never tell anyone it is "ok" to have a multi-homed DC.  Even Ace strongly discourages it which I am sure he mention in his article.
That first sentence was a quote from a above but I missed marking it as such
I understand all that.  And I'm not saying that the rest of our network has been done correctly, because it's not.  I get the message, I shouldn't have a multi-homed DNS, and our network should be configured better.  But for now, can we please just assume that I don't have a choice?  And given that, is there anything I can do to keep this setting from going back to default on reboot, and therefore keep the IP's from showing up in DNS?
Here is the thing the setting should stay set even during a reboot.

Run sfc /scannow
But for now, can we please just assume that I don't have a choice?

But that is just it.   I don't think it is something you can choose no matter how bad you want it.  I think you just have to fix the flaw now rather than later.  If you don't think you have a choice then you have to push the situation so that you get a choice.

Also Ace's article was Server2003 centric, and I think someone mentioned that.  There could very well be a big enough difference in 2008 to matter.

dariusg is correct,...the setting "should" stick.  But MS can screw up a wet dream.  2008 is just the "Vista of the servers" and 2008R2 was only just a mild improvement just like Win7 was only a mild improvement to vista.  All 4 OSs have had a history of problems in the networking structure of the OS and I don't trust any of them farther than I can throw them.  Heck I remember reading MS material that said to disable IPV6 if you aren't' using it and they I saw MS material that said you have to leave it enabled even if you aren't using it due to some functionality that fails if you do,...so if MS can't make up there mind,...who can you trust?

Maybe you can run Windows Update on the Server and bring all the patches up to date,...maybe you'll get lucky,...and one of the patches will get it behaving properly.
Thanks pwindell, I appriciate your recommendations and your concerns.  I agree with you on a lot of things and I dissagree with you on some things as well, but I'm not interested in discussing it,  I'm just interested in whether or not I can fix the specific problem that I posted about originally.  I have heard your concerns, and I thank you for them because you are right, and I would like to correct the 'roots' of the problem eventually, but for now, I'm not interested in talking any more about why I shouldn't use a multi-homed DC.

I did an sfc /scannow, which didn't find any problems.  I will keep googling, and try another reboot later today.  I am open to furthur input on why the DNS setting won't stick, if anyone else has any more suggestions for me, thanks.
So you aren't interested in running Windows Updates to try to correct the server's behavor which might help the setting stick?   As if I never even mentioned it?

If you aren't interested in not multi-homing the DC that is your choice,...but don't treat me as if that was the only thing I suggested.
Sorry about that, I had aldready installed all available Microsoft updates over the weekend.  I forgot to mention that in my response.  I just re-checked, and no new updates waiting.
There is a registry setting you can manually enter the IP addresses to listen on but I can't remember exactly where that it is right now. I don't have a DNS server in front of me to look either.
I will google for the registry setting and give that a try, thanks dariusg!
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Well I am out of ideas.   Maybe the reg setting will band-ade it if you can find the information.

@dariusg
I agree with everything you have said and suggested.  I think it is just a screwed up server.  I have seen threads where 2008 just gets like this and nothing ever seemed to fix it.
Thanks for your assistance pwindell, I appriciate your input.
That works for all of my multihomed Hyper-V Server hosts.

MS's "official" way to handle it with Hyper-V is to unbind TCP/IP from the Nics and disable them after the Virtualized Network is in place and has VMs using it.  the Virtualized Network will remain active after the Physical Nics are disabled.   The only nic that remains active on hyper-V is the Management Nic if you need to manage it from another workstation.
I have also changed the DNS suffix on the unwanted segments, such as iscsi.domain.local. Since endpoints are looking for dc.domain.local, and not dc.iscsi.domain.local, they don't find the other ip addresses when querying DNS. Not sure if that would work on a DC.

Finally, the routers on the network could be configured to route traffic destined for those other NICs to the main NIC of the DC. The DC would probably need to have routing turned on, but that is only so it can route traffic destined for itself; it wouldn't need to actually route traffic from the rest of the iSCSI LAN.
Sometimes listening to the best advice on offer, even though it is NOT the advice you wanted to hear, is the correct and best thing to do. Multi homed DC's, as I stated right at the begining, are just not the done thing, are a disaster waiting to happen and will ALWAYS bite you in the ass.

I know you dont want to discuss it nut just maybe you will go away and think about it quietly, even if you dont admit to it.
@pwindell, my Hyper-V server hosts are legitimately multihomed because they have iSCSI interfaces. The different DNS suffix name works for machines that get iSCSI interface IPs via DHCP. The static name assignment works for the servers that would otherwise register multiple IPs in DNS. I do it this way because it's much easier to make the static DNS assignment than to figure out how to disable specific NICs from registering in DNS without the Networking GUI.
@kevinhsieh

I'm not saying anything is illegitimate,...I'm just stating the way MS expects it to be handled.
It is just an FYI.  You can do with it what you want.  I'm tired of everything becoming a debate.  I'm here to tell people what the proper way it to do something when I run across a potential situation.  It is nothing more than that.  Below is a link to a video backing up what I said.

MS doesn't say its due to any DNS issues because the Hyper-V is not expected to be a multi-homed DC in addition to the hyper-V Role.  They are suggesting it due to security issues.
http://technet.microsoft.com/en-us/edge/Video/ff710552
But those servers are NOT DC's right? The BIG Issue is multihomed DC's.
But those servers are NOT DC's right? The BIG Issue is multihomed DC's.

Yes,..That's correct
I expect that dynamic registration of IPs on multihomed machines to behave similarly between DCs and member servers.
As far as the OS goes it is the same behavor.  The problem is the way AD recognizes (or fails to recognize) the machine.  For AD to operate properly the machine can only have one IP Identity,...and that comes from DNS.  So you have to hide the other identities (IP#s) from DNS and AD for it to work right.

But 2008 is not quite the same in how it handles TCP/IP as it was with 2003.  One other thing that 2008 does it that is doesn't consistently use the same IP# as the source IP# inside packets leaving the machine when you have a situation with more than one IP on the same Nic (same subnet). With 2003 it consistently used the Default IP# but 2008 doesn't seem to.  So it exacerbates and already bad situation with multi-homes DCs.  Sorry guys,..I just don't trust the behavor of the TCP/IP Stack in 2008 to behave consistently the way I would want it.
Avatar of teomcam
teomcam

Actually there is an easy way to solve that issue.
Go to DNS Server and right click adn remove all IP addresses other than your DC's!

 User generated image
No that really isn't the problem.

It is not a problem of what IP it listens for DNS Requests.  It can listen for DNS Requests on any IP# it wants to and that doesn't hurt anything.

The problem is how the DC itself gets registered in the DNS Zone's Records. So there ends up being discrepancies in what IP# the DC gets identified by and how the Suffixes get applied,...and how Active Directory expects things to be.

When you look at the TCP/IP Properties of a Nic and go into the Advanced Section and look at the DNS Tab you will find a check box Item that says "Register this connection's IP in DNS".  On a multi-homed DC this should only be enabled on the one primary NIC but should be disabled on any other.  You also want that Nic to be the first in the Binding Order.

However that is where I have hear a lot of horror stories about how 2008 almost seems to ignore these things and seem to just do whatever it wants.  I hear stories that a Nic continues to register itself in DNS when the check box tells it not to and have also heard that it doesn't always follow the Binding Order in expected way.

Sorry I don't have any concrete documentation of this,...all I have are experiences in what I have read of the problems people have had in their forum posts over the couple years 2008 has been out.
So it just enforces what we keep saying over and over and over in these forums.  do not multi-home your DCs,...period.

Are there workarounds?  Yes
Do they work?  Sometimes
Are they dependable?  I my opinion,...NO.

So just don't do it and you'll never have to worry about all this.
I think pwindell that we waste our breath you and I.  You can offer the best advice in the world but if somebody has it in their mind to ignore the best advice, even before it is offered, your onto a loser.
Shall me and you retire to the lounge and discuss the weather instead? :P
You've hit on why I sometimes come across so irritable at times in these threads even though I don't set out to be that way.

This isn't the only subject that suffers from this either,...there are several others, such as avoiding over-loading subnets, and avoiding asynchronous routing.

I think everything that can be said here has been said.  It is up to people to do whatever they are going to do, whatever that may be.
I am very interested to know if statically assigning the A record for the DC in DNS solves the problem.
I sounds like something good to try.  
Ok, thanks for all the comments.  The solution SHOULD have been as simple as setting DNS to only bind to the correct IP as Dariusq advised.  However, as I mentioned, that setting would not stick for me and kept reverting to the default on every reboot (still doing that, even when manually entered into the registry).  In the end though, I was able to prevent DNS from updating the records as kevinhsieh suggested.

Thank you pwindell for all your advise, and rest assured that when our situation allows, we will be correcting the root of the problem so that we do not need a multi-homed DC.
I am glad to hear that simply statically assigning the A record fixed the problem. I believe that the multi-homed DC will be okay going forward, because all of the issues I have personally heard of involve the issue of adresses being in DNS that aren't fully available to all domain members because of routing, binding, or firewall issues.  By ensuring that only the correct IP is in DNS, all of those issues should go away.