DNS Update Issue
-
@Donahue said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@Donahue said in DNS Update Issue:
right, but I wonder if my branch DC should be pointing to the HQ DC, or just going straight to external?
Branch DC's DNS should point first to the loopback, then to the HQ DNS. That way to minimize WAN traffic, and maximize performance.
in the NIC settings, correct? Should HQ secondarily point to branch?
Itself first then the other DC. Under forwarders there should be no local dns listed
-
@Donahue said in DNS Update Issue:
I just did an experiment and disabled the NIC on my HQ DC. DNS is still able to resolve like normal, so I assume things are fine there. I will check the branch too. For some reason we recently had issues with one DC being down, and DNS being down too, as if it didnt failover to the other DC.
Failover at that level would be from the NIC settings on the desktops, not from something on the server (normally.)
The clients should switch to looking at the "other" one. Although it could be that the DNS service at the second location was not working at all.
-
@wirestyle22 said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
So thought experiment:
If DC1 and DC2 have 127.0.0.1 as their only DNS entry and their forwarders are only set to each other, how does that resolve? Can the DC's tell the difference between a forwarding request and a normal DNS request? Otherwise wouldn't this time out?
The problem here, is if you are on DC1 and DC1's DNS fails, then the loopback lookup will have nowhere to go. And everything will fail, even though you have redundant services on your network.
If you had DC2 as the secondary DNS entry, things would have kept working.
Right but I'm just asking to understand whether or not the DNS servers understand the difference between a normal dns query and a forwarding dns query. Would this ever end due to a rule that wasn't a timeout?
I can't imagine it would see a difference. I think the delayed response would be the only timeout happening. Though, in an implementation that doesn't think about a cyclical query, I could see the resources being used until the server crashed... they would keep going forward, even though the past queries themselves would time out. Though, since you had this setup, and you didn't have crashing servers (did you?) that seems like an unlikely problem.
-
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
So thought experiment:
If DC1 and DC2 have 127.0.0.1 as their only DNS entry and their forwarders are only set to each other, how does that resolve? Can the DC's tell the difference between a forwarding request and a normal DNS request? Otherwise wouldn't this time out?
The problem here, is if you are on DC1 and DC1's DNS fails, then the loopback lookup will have nowhere to go. And everything will fail, even though you have redundant services on your network.
If you had DC2 as the secondary DNS entry, things would have kept working.
Right but I'm just asking to understand whether or not the DNS servers understand the difference between a normal dns query and a forwarding dns query. Would this ever end due to a rule that wasn't a timeout?
I can't imagine it would see a difference. I think the delayed response would be the only timeout happening. Though, in an implementation that doesn't think about a cyclical query, I could see the resources being used until the server crashed... they would keep going forward, even though the past queries themselves would time out. Though, since you had this setup, and you didn't have crashing servers (did you?) that seems like an unlikely problem.
Well the local pc's and stuff had dns set to public dns and then local dns so things just didnt work here and there
-
@Dashrender said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@Donahue said in DNS Update Issue:
right, but I wonder if my branch DC should be pointing to the HQ DC, or just going straight to external?
Branch DC's DNS should point first to the loopback, then to the HQ DNS. That way to minimize WAN traffic, and maximize performance.
Timeout here - is he talking about the IP settings DNS or the DNS forwarder? I thought this question was about the forwarders.
He had both in the question. I'm not clear.
-
@wirestyle22 said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
So thought experiment:
If DC1 and DC2 have 127.0.0.1 as their only DNS entry and their forwarders are only set to each other, how does that resolve? Can the DC's tell the difference between a forwarding request and a normal DNS request? Otherwise wouldn't this time out?
The problem here, is if you are on DC1 and DC1's DNS fails, then the loopback lookup will have nowhere to go. And everything will fail, even though you have redundant services on your network.
If you had DC2 as the secondary DNS entry, things would have kept working.
Right but I'm just asking to understand whether or not the DNS servers understand the difference between a normal dns query and a forwarding dns query. Would this ever end due to a rule that wasn't a timeout?
I can't imagine it would see a difference. I think the delayed response would be the only timeout happening. Though, in an implementation that doesn't think about a cyclical query, I could see the resources being used until the server crashed... they would keep going forward, even though the past queries themselves would time out. Though, since you had this setup, and you didn't have crashing servers (did you?) that seems like an unlikely problem.
Well the local pc's and stuff had dns set to public dns and then local dns so things just didnt work here and there
Yeah - that's a nightmare - surprised that local stuff worked at all - perhaps it worked only because of broadcasts based resolution on the local network - i.e. the public DNS had no answer, so the system did a broadcast to try to resolve the name locally... and that worked.
-
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
So thought experiment:
If DC1 and DC2 have 127.0.0.1 as their only DNS entry and their forwarders are only set to each other, how does that resolve? Can the DC's tell the difference between a forwarding request and a normal DNS request? Otherwise wouldn't this time out?
The problem here, is if you are on DC1 and DC1's DNS fails, then the loopback lookup will have nowhere to go. And everything will fail, even though you have redundant services on your network.
If you had DC2 as the secondary DNS entry, things would have kept working.
Right but I'm just asking to understand whether or not the DNS servers understand the difference between a normal dns query and a forwarding dns query. Would this ever end due to a rule that wasn't a timeout?
I can't imagine it would see a difference. I think the delayed response would be the only timeout happening. Though, in an implementation that doesn't think about a cyclical query, I could see the resources being used until the server crashed... they would keep going forward, even though the past queries themselves would time out. Though, since you had this setup, and you didn't have crashing servers (did you?) that seems like an unlikely problem.
Well the local pc's and stuff had dns set to public dns and then local dns so things just didnt work here and there
Yeah - that's a nightmare - surprised that local stuff worked at all - perhaps it worked only because of broadcasts based resolution on the local network - i.e. the public DNS had no answer, so the system did a broadcast to try to resolve the name locally... and that worked.
That's exactly the case IMO
-
@wirestyle22 said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
So thought experiment:
If DC1 and DC2 have 127.0.0.1 as their only DNS entry and their forwarders are only set to each other, how does that resolve? Can the DC's tell the difference between a forwarding request and a normal DNS request? Otherwise wouldn't this time out?
The problem here, is if you are on DC1 and DC1's DNS fails, then the loopback lookup will have nowhere to go. And everything will fail, even though you have redundant services on your network.
If you had DC2 as the secondary DNS entry, things would have kept working.
Right but I'm just asking to understand whether or not the DNS servers understand the difference between a normal dns query and a forwarding dns query. Would this ever end due to a rule that wasn't a timeout?
I can't imagine it would see a difference. I think the delayed response would be the only timeout happening. Though, in an implementation that doesn't think about a cyclical query, I could see the resources being used until the server crashed... they would keep going forward, even though the past queries themselves would time out. Though, since you had this setup, and you didn't have crashing servers (did you?) that seems like an unlikely problem.
Well the local pc's and stuff had dns set to public dns and then local dns so things just didnt work here and there
Yeah - that's a nightmare - surprised that local stuff worked at all - perhaps it worked only because of broadcasts based resolution on the local network - i.e. the public DNS had no answer, so the system did a broadcast to try to resolve the name locally... and that worked.
That's exactly the case IMO
this is why end points should never have a public DNS entry - ever. The recently discussed solution for setting up DNS inhouse provides failover to public DNS in situations where internal DNS is down. All without the risk that a client machine will just decide to flip to it's secondary DNS and if public suddenly not have access to info about internal resources.
-
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
So thought experiment:
If DC1 and DC2 have 127.0.0.1 as their only DNS entry and their forwarders are only set to each other, how does that resolve? Can the DC's tell the difference between a forwarding request and a normal DNS request? Otherwise wouldn't this time out?
The problem here, is if you are on DC1 and DC1's DNS fails, then the loopback lookup will have nowhere to go. And everything will fail, even though you have redundant services on your network.
If you had DC2 as the secondary DNS entry, things would have kept working.
Right but I'm just asking to understand whether or not the DNS servers understand the difference between a normal dns query and a forwarding dns query. Would this ever end due to a rule that wasn't a timeout?
I can't imagine it would see a difference. I think the delayed response would be the only timeout happening. Though, in an implementation that doesn't think about a cyclical query, I could see the resources being used until the server crashed... they would keep going forward, even though the past queries themselves would time out. Though, since you had this setup, and you didn't have crashing servers (did you?) that seems like an unlikely problem.
Well the local pc's and stuff had dns set to public dns and then local dns so things just didnt work here and there
Yeah - that's a nightmare - surprised that local stuff worked at all - perhaps it worked only because of broadcasts based resolution on the local network - i.e. the public DNS had no answer, so the system did a broadcast to try to resolve the name locally... and that worked.
That's exactly the case IMO
this is why end points should never have a public DNS entry - ever. The recently discussed solution for setting up DNS inhouse provides failover to public DNS in situations where internal DNS is down. All without the risk that a client machine will just decide to flip to it's secondary DNS and if public suddenly not have access to info about internal resources.
This risk is unique to Windows. Under non-Windows situations, you wouldn't avoid that as it isn't a risk.
-
@scottalanmiller said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
So thought experiment:
If DC1 and DC2 have 127.0.0.1 as their only DNS entry and their forwarders are only set to each other, how does that resolve? Can the DC's tell the difference between a forwarding request and a normal DNS request? Otherwise wouldn't this time out?
The problem here, is if you are on DC1 and DC1's DNS fails, then the loopback lookup will have nowhere to go. And everything will fail, even though you have redundant services on your network.
If you had DC2 as the secondary DNS entry, things would have kept working.
Right but I'm just asking to understand whether or not the DNS servers understand the difference between a normal dns query and a forwarding dns query. Would this ever end due to a rule that wasn't a timeout?
I can't imagine it would see a difference. I think the delayed response would be the only timeout happening. Though, in an implementation that doesn't think about a cyclical query, I could see the resources being used until the server crashed... they would keep going forward, even though the past queries themselves would time out. Though, since you had this setup, and you didn't have crashing servers (did you?) that seems like an unlikely problem.
Well the local pc's and stuff had dns set to public dns and then local dns so things just didnt work here and there
Yeah - that's a nightmare - surprised that local stuff worked at all - perhaps it worked only because of broadcasts based resolution on the local network - i.e. the public DNS had no answer, so the system did a broadcast to try to resolve the name locally... and that worked.
That's exactly the case IMO
this is why end points should never have a public DNS entry - ever. The recently discussed solution for setting up DNS inhouse provides failover to public DNS in situations where internal DNS is down. All without the risk that a client machine will just decide to flip to it's secondary DNS and if public suddenly not have access to info about internal resources.
This risk is unique to Windows. Under non-Windows situations, you wouldn't avoid that as it isn't a risk.
How is it not a risk? You don't have internally only known resources? i.e. an internal DNS server that has resolution that only works inhouse?
-
@scottalanmiller said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
So thought experiment:
If DC1 and DC2 have 127.0.0.1 as their only DNS entry and their forwarders are only set to each other, how does that resolve? Can the DC's tell the difference between a forwarding request and a normal DNS request? Otherwise wouldn't this time out?
The problem here, is if you are on DC1 and DC1's DNS fails, then the loopback lookup will have nowhere to go. And everything will fail, even though you have redundant services on your network.
If you had DC2 as the secondary DNS entry, things would have kept working.
Right but I'm just asking to understand whether or not the DNS servers understand the difference between a normal dns query and a forwarding dns query. Would this ever end due to a rule that wasn't a timeout?
I can't imagine it would see a difference. I think the delayed response would be the only timeout happening. Though, in an implementation that doesn't think about a cyclical query, I could see the resources being used until the server crashed... they would keep going forward, even though the past queries themselves would time out. Though, since you had this setup, and you didn't have crashing servers (did you?) that seems like an unlikely problem.
Well the local pc's and stuff had dns set to public dns and then local dns so things just didnt work here and there
Yeah - that's a nightmare - surprised that local stuff worked at all - perhaps it worked only because of broadcasts based resolution on the local network - i.e. the public DNS had no answer, so the system did a broadcast to try to resolve the name locally... and that worked.
That's exactly the case IMO
this is why end points should never have a public DNS entry - ever. The recently discussed solution for setting up DNS inhouse provides failover to public DNS in situations where internal DNS is down. All without the risk that a client machine will just decide to flip to it's secondary DNS and if public suddenly not have access to info about internal resources.
This risk is unique to Windows. Under non-Windows situations, you wouldn't avoid that as it isn't a risk.
In a truly LANless setup, you're right, this would never be a problem. Your servers would all have outward facing resources so using public DNS would give you everything you need.
-
@Dashrender said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
So thought experiment:
If DC1 and DC2 have 127.0.0.1 as their only DNS entry and their forwarders are only set to each other, how does that resolve? Can the DC's tell the difference between a forwarding request and a normal DNS request? Otherwise wouldn't this time out?
The problem here, is if you are on DC1 and DC1's DNS fails, then the loopback lookup will have nowhere to go. And everything will fail, even though you have redundant services on your network.
If you had DC2 as the secondary DNS entry, things would have kept working.
Right but I'm just asking to understand whether or not the DNS servers understand the difference between a normal dns query and a forwarding dns query. Would this ever end due to a rule that wasn't a timeout?
I can't imagine it would see a difference. I think the delayed response would be the only timeout happening. Though, in an implementation that doesn't think about a cyclical query, I could see the resources being used until the server crashed... they would keep going forward, even though the past queries themselves would time out. Though, since you had this setup, and you didn't have crashing servers (did you?) that seems like an unlikely problem.
Well the local pc's and stuff had dns set to public dns and then local dns so things just didnt work here and there
Yeah - that's a nightmare - surprised that local stuff worked at all - perhaps it worked only because of broadcasts based resolution on the local network - i.e. the public DNS had no answer, so the system did a broadcast to try to resolve the name locally... and that worked.
That's exactly the case IMO
this is why end points should never have a public DNS entry - ever. The recently discussed solution for setting up DNS inhouse provides failover to public DNS in situations where internal DNS is down. All without the risk that a client machine will just decide to flip to it's secondary DNS and if public suddenly not have access to info about internal resources.
This risk is unique to Windows. Under non-Windows situations, you wouldn't avoid that as it isn't a risk.
In a truly LANless setup, you're right, this would never be a problem. Your servers would all have outward facing resources so using public DNS would give you everything you need.
Is that the assumption? Pretty specific
-
@Dashrender said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
So thought experiment:
If DC1 and DC2 have 127.0.0.1 as their only DNS entry and their forwarders are only set to each other, how does that resolve? Can the DC's tell the difference between a forwarding request and a normal DNS request? Otherwise wouldn't this time out?
The problem here, is if you are on DC1 and DC1's DNS fails, then the loopback lookup will have nowhere to go. And everything will fail, even though you have redundant services on your network.
If you had DC2 as the secondary DNS entry, things would have kept working.
Right but I'm just asking to understand whether or not the DNS servers understand the difference between a normal dns query and a forwarding dns query. Would this ever end due to a rule that wasn't a timeout?
I can't imagine it would see a difference. I think the delayed response would be the only timeout happening. Though, in an implementation that doesn't think about a cyclical query, I could see the resources being used until the server crashed... they would keep going forward, even though the past queries themselves would time out. Though, since you had this setup, and you didn't have crashing servers (did you?) that seems like an unlikely problem.
Well the local pc's and stuff had dns set to public dns and then local dns so things just didnt work here and there
Yeah - that's a nightmare - surprised that local stuff worked at all - perhaps it worked only because of broadcasts based resolution on the local network - i.e. the public DNS had no answer, so the system did a broadcast to try to resolve the name locally... and that worked.
That's exactly the case IMO
this is why end points should never have a public DNS entry - ever. The recently discussed solution for setting up DNS inhouse provides failover to public DNS in situations where internal DNS is down. All without the risk that a client machine will just decide to flip to it's secondary DNS and if public suddenly not have access to info about internal resources.
This risk is unique to Windows. Under non-Windows situations, you wouldn't avoid that as it isn't a risk.
How is it not a risk? You don't have internally only known resources? i.e. an internal DNS server that has resolution that only works inhouse?
Because the risk is from flipping, a Windows bug.
-
@Dashrender said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
So thought experiment:
If DC1 and DC2 have 127.0.0.1 as their only DNS entry and their forwarders are only set to each other, how does that resolve? Can the DC's tell the difference between a forwarding request and a normal DNS request? Otherwise wouldn't this time out?
The problem here, is if you are on DC1 and DC1's DNS fails, then the loopback lookup will have nowhere to go. And everything will fail, even though you have redundant services on your network.
If you had DC2 as the secondary DNS entry, things would have kept working.
Right but I'm just asking to understand whether or not the DNS servers understand the difference between a normal dns query and a forwarding dns query. Would this ever end due to a rule that wasn't a timeout?
I can't imagine it would see a difference. I think the delayed response would be the only timeout happening. Though, in an implementation that doesn't think about a cyclical query, I could see the resources being used until the server crashed... they would keep going forward, even though the past queries themselves would time out. Though, since you had this setup, and you didn't have crashing servers (did you?) that seems like an unlikely problem.
Well the local pc's and stuff had dns set to public dns and then local dns so things just didnt work here and there
Yeah - that's a nightmare - surprised that local stuff worked at all - perhaps it worked only because of broadcasts based resolution on the local network - i.e. the public DNS had no answer, so the system did a broadcast to try to resolve the name locally... and that worked.
That's exactly the case IMO
this is why end points should never have a public DNS entry - ever. The recently discussed solution for setting up DNS inhouse provides failover to public DNS in situations where internal DNS is down. All without the risk that a client machine will just decide to flip to it's secondary DNS and if public suddenly not have access to info about internal resources.
This risk is unique to Windows. Under non-Windows situations, you wouldn't avoid that as it isn't a risk.
In a truly LANless setup, you're right, this would never be a problem. Your servers would all have outward facing resources so using public DNS would give you everything you need.
It's also a LAN-based problem, true. But both a LAN-based, and a Windows problem.
-
@Donahue said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@Donahue said in DNS Update Issue:
right, but I wonder if my branch DC should be pointing to the HQ DC, or just going straight to external?
Branch DC's DNS should point first to the loopback, then to the HQ DNS. That way to minimize WAN traffic, and maximize performance.
in the NIC settings, correct? Should HQ secondarily point to branch?
ADDS DCs with integrated DNS should have only one DNS entry on the NIC: DNS0: Own IP
When a DC is elevated it drops the loopback address in.
Again, an AD integrated DNS server does not need any other DNS servers assigned to its own NIC. That's taken care of by AD and DNS replication.
In the branch the local DC points to itself. In AD Sites a site is set up with replication links and timing between the branch and the HO. This usually a 15 minute cycle. The branch DC should be a Global Catalogue server so the local machines always authenticate to it. DHCP should assign that local DC for DNS only.
Please don't assign public DNS servers to any internal resource. That's just plain wrong. If anything glitches on the network the clients flip to DNS1 instead of DNS0 that's pointing to an external DNS server. So, when internal resources are called the Internet DNS server answers, "Huh?!?"
Depending on Time To Live (TTL) the clients would either need a IPConfig /Release && IPConfig /Renew or a reboot to get them to look at the local DNS server again.
-
@PhlipElder said in DNS Update Issue:
@Donahue said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@Donahue said in DNS Update Issue:
right, but I wonder if my branch DC should be pointing to the HQ DC, or just going straight to external?
Branch DC's DNS should point first to the loopback, then to the HQ DNS. That way to minimize WAN traffic, and maximize performance.
in the NIC settings, correct? Should HQ secondarily point to branch?
ADDS DCs with integrated DNS should have only one DNS entry on the NIC: DNS0: Own IP
When a DC is elevated it drops the loopback address in.
Again, an AD integrated DNS server does not need any other DNS servers assigned to its own NIC. That's taken care of by AD and DNS replication.
But the whole question is what happens when the DNS fails locally.
-
its very possible that my issue could have been both DC 1 and DC 2 being unavilable and the clients flipping to DNS2 which is a public DNS, in which case that could be why my internal resources were not able to be found at that time. We had some network issues around the same time too, maybe they overlapped and I just didn't put 2+2 together.
-
also, I just want to clarify. People are using the term "DC with integrated DNS". I am thinking of it as DC with DNS role. Are talking about the same thing?
-
@Donahue said in DNS Update Issue:
also, I just want to clarify. People are using the term "DC with integrated DNS". I am thinking of it as DC with DNS role. Are talking about the same thing?
Yes
-
@scottalanmiller said in DNS Update Issue:
@PhlipElder said in DNS Update Issue:
@Donahue said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@Donahue said in DNS Update Issue:
right, but I wonder if my branch DC should be pointing to the HQ DC, or just going straight to external?
Branch DC's DNS should point first to the loopback, then to the HQ DNS. That way to minimize WAN traffic, and maximize performance.
in the NIC settings, correct? Should HQ secondarily point to branch?
ADDS DCs with integrated DNS should have only one DNS entry on the NIC: DNS0: Own IP
When a DC is elevated it drops the loopback address in.
Again, an AD integrated DNS server does not need any other DNS servers assigned to its own NIC. That's taken care of by AD and DNS replication.
But the whole question is what happens when the DNS fails locally.
When does this even happen? How do you have a DC/DNS server running, then suddenly the DNS service breaks? Then what? Just fix it and be done with it. Restore the zone, whatever... if it's the only DC, a simple restore will get you up and going in 10 minutes. If there's others, and DNS is corrupt, it'll replicate and corrupt the other DNS servers too. AD integrated DNS zones replicate.
If the DNS role/service fails on a DC, you have bigger issues. If it's corruption or deletion, well all your other ones will be screwed too anyways.
