DNS Update Issue
-
@Donahue said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@Donahue said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@Donahue said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@Donahue The first one (It's own IP) should be 127.0.0.1 is what they are saying
That's what I thought. What about settings for the DNS server service?
The DNS server (via DNS Manager) should have it's forwarders set to whatever service you want to use as your upstream resolution provider (I use Google - some people pay Umbrella, so they use Umbrella).
ok, weird. One of my DC's, the one at my location, is set to only google. The other at my branch is set to the DC at my location, then our two ISP provided servers, and then finally to google.
You DNS Forwarders are set to only google? ok - so what's the problem? There is nothing wrong with that.
It's that both my DC's are different, that's the weird part.
Yeah, that's not idea. Whatever is good for the gander is good for the goose.
Where gander is DC1 and goose is DC2 for no particular reason.
-
yeah, its changed now. That was setup by some random third party when our AD was setup years ago, at the time I didnt even know what DNS was.
-
@Donahue said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@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.
Was DHCP handing out two DNS servers? was the second DNS server online and working?
DHCP hands out the local DC first, then the remote DC. During this outage, that also went down because it was the same DC VM. But at the time, that wasnt my primary concern. now that everything is working, I feel the need to verify that all aspects will failover correctly. DNS apparently does but I am not sure if all other DC functions do.
If DNS fails over, then AD should as well, though you could have some timeout issues... which will mostly be masked from the users by slowness.
-
@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.
-
@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.
-
@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?
-
@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.
-
@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?
-
@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
