DNS Update Issue
-
@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.
-
@Obsolesce said in DNS Update Issue:
@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.
The only time we've hit this is in a full power outage situation where there was not enough UPS to keep things up and running.
With Cloud Witness there needs to be a DNS server alive prior to the cluster nodes firing to allow them to find that cloud located witness or no-go for starting the cluster.
For on-premises, if DNS is offline there's more going on there than a simple oops. What we do while recovering the DC if it's going to take longer than 15-30 minutes is flip DHCP Services on at the edge and have the clients release and renew their IP address to pick that up. Then, at least they are somewhat productive while we're working on the recovery.
As soon as the DC is back online DHCP gets turned off at the edge and the clients renew their IP address to catch the DC again. Done.
-
@scottalanmiller said in DNS Update Issue:
@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.
I don't follow - Won't non windows machine also flip to a secondary DNS if the primary times out? and when it does flip - when do those non windows OSes decide to flip back?
i.e. you give you Linux client primary internal DNS and secondary google DNS - how do you not run into the same issue if the client flips to the secondary?
-
@Dashrender said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@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.
I don't follow - Won't non windows machine also flip to a secondary DNS if the primary times out? and when it does flip - when do those non windows OSes decide to flip back?
i.e. you give you Linux client primary internal DNS and secondary google DNS - how do you not run into the same issue if the client flips to the secondary?
The issue discussed (possibly offline) was that Windows does this at random and never flips back.
-
@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.
He never said forwarders. Base don the chain, i would assume he was loking at his NIC settings.
-
@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?
That is not how you set anything up.
Forwarders are external to your network.
You don't forward to another DC. AD syncs DNS settings between DNS servers on an AD network.
-
@Dashrender said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@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.
I don't follow - Won't non windows machine also flip to a secondary DNS if the primary times out? and when it does flip - when do those non windows OSes decide to flip back?
i.e. you give you Linux client primary internal DNS and secondary google DNS - how do you not run into the same issue if the client flips to the secondary?
There was, or maybe still is, a bug in Windows Server DNS Server service WRT Top Level Domains (TLDs) and the DNS cache that reared its head occasionally. The bug would not allow a DNS poll to get beyond the initial local cache check to check the Root Hints servers and move on from there.
So, folks would get no answer or a blank page when the DNS poll failed.
There's a fix for it somewhere. But, since we always use forwarders, normally OpenDNS, we've not hit the bug in years. Thus, I have no idea if the bug is still present in Server 2016 or Server 2019!
-
@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.
You are correct, because the DNS forwarding functions is simply a DNS lookup to the IP of the DNS forwarder instead of the local DNS. It does not use the NIC DNS settings at all. Also, this can only occur is the DNS server itself is working as the DNS server itself is what makes the damned forwarder lookup. So in the case of DNS server not working, this would never apply.
I do not understand why this is so damned hard for everyone to understand.
-
@JaredBusch 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.
You are correct, because the DNS forwarding functions is simply a DNS lookup to the IP of the DNS forwarder instead of the local DNS. It does not use the NIC DNS settings at all. Also, this can only occur is the DNS server itself is working as the DNS server itself is what makes the damned forwarder lookup. So in the case of DNS server not working, this would never apply.
I do not understand why this is so damned hard for everyone to understand.
I'm not sure who you think didn't understand that. I'm not sure to which situation that applies that we've been discussing.
-
@scottalanmiller said in DNS Update Issue:
@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.
No. While there was/is a problem with Windows flipping to DNS2 and not flipping back, that does not negate this actual core issue. Once a system makes a DNS call to a public service and returns bad information, that information is locally cached on all operating systems.
Services will be broken even after local DNS returns because the user OS will not look it up again for a while.
-
@Donahue said in DNS Update Issue:
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.
Oh - good reminder - your secondary DNS was google - yeah of course you could no longer get to local resources, google's DNS knowns nothing of your internal servers, so lookups would fail.
This is why you never give clients an external DNS entry in IP settings. -
@scottalanmiller said in DNS Update Issue:
@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
Definitely yes, because there is basically no way to have a Windows DC not also have DNS.
-
@JaredBusch 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.
You are correct, because the DNS forwarding functions is simply a DNS lookup to the IP of the DNS forwarder instead of the local DNS. It does not use the NIC DNS settings at all. Also, this can only occur is the DNS server itself is working as the DNS server itself is what makes the damned forwarder lookup. So in the case of DNS server not working, this would never apply.
I do not understand why this is so damned hard for everyone to understand.
DNS Forwarding is:
- Client: Hay, where's www.whatchamacallit.com?
- DNS Server: Hmmm, looking in my local cache
- DNS Server: Nope, not there
- DNS Server: Do I have the domain hosted locally? Nope
- DNS Server: I have a Forwarder DNS Server set up
- DNS Server: Hay Forwarder DNS Server, do you know where www.whatchamacallit.com is?
- DNS Forwarder: Yup, it's at IP 99.88.77.66 (or, ask DNS SOA for domain at NS1.HostedDNS.Com)
- DNS Server: Hay Client, it's at 99.88.77.66
The alternate at step 4 would be to go through the process of finding SOA (Start of Authority) via the Root Hints server. But, that process takes a lot "longer".
The above is as close as I can remember to the process.
-
@scottalanmiller said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@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.
I don't follow - Won't non windows machine also flip to a secondary DNS if the primary times out? and when it does flip - when do those non windows OSes decide to flip back?
i.e. you give you Linux client primary internal DNS and secondary google DNS - how do you not run into the same issue if the client flips to the secondary?
The issue discussed (possibly offline) was that Windows does this at random and never flips back.
I absolutely agree with this - but there can be times where the primary DNS server faulters, but it's completely down - so all your other client devices could flip too. therefore the same issues could happen.
