DNS Update Issue
-
@PhlipElder said in DNS Update Issue:
@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.
yeah, this is what I recall too.
The DNS server service doesn't use the DNS client ip settings - those are completely skipped in this setting. Instead is uses the forwarders, and if there are no forwarders listed, it uses Root Hints.
-
@JaredBusch 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?
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.
Yeah I know. I've said this in this very thread, it's just a thought experiement
-
@Dashrender said in DNS Update Issue:
@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.in my case, the public was number 3, after both DC's, but the point remains.
-
@Donahue said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@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.in my case, the public was number 3, after both DC's, but the point remains.
aww, yep - both internal DNS servers flaked - or windows auto flipped like it likes to do sometimes...
-
@wirestyle22 said in DNS Update Issue:
@JaredBusch 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?
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.
Yeah I know. I've said this in this very thread, it's just a thought experiement
It was an invalid thought that derailed an entire section of the conversation
-
@JaredBusch said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@JaredBusch 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?
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.
Yeah I know. I've said this in this very thread, it's just a thought experiement
It was an invalid thought that derailed an entire section of the conversation
Sure
-
@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:
@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.
But non-Windows flip back, right? One of the specific problems was Windows machines never going back to their normal settings until rebooted.
-
@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:
@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.
But non-Windows flip back, right? One of the specific problems was Windows machines never going back to their normal settings until rebooted.
I have no idea - do they? and in what time frame?
That second part is also wrong - they flip back when whatever event caused them to flip in the first place happens in again. But when you're using public DNS as a secondary entry - you're instantly broken, and once you discover you're broken who's going to wait around until whatever caused the flip to happen to happen again?It's more likely that most non Windows machine don't rely upon AD type things so heavily and therefore don't realize when a switch has happened.... because they likely tend to be more LANless in nature.
-
@Dashrender said in DNS Update Issue:
That second part is also wrong - they flip back when whatever event caused them to flip in the first place happens in again. But when you're using public DNS as a secondary entry - you're instantly broken, and once you discover you're broken who's going to wait around until whatever caused the flip to happen to happen again?
You mean an opposite event? Meaning... they stay forever, until something breaks?
-
Testing now, because I want to know...
-
@scottalanmiller said in DNS Update Issue:
Testing now, because I want to know...
On non-Windows (Fedora specifically) it goes back instantly. The moment the original server is back, it is using it. And always uses it when available.
-
@scottalanmiller said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
Testing now, because I want to know...
On non-Windows (Fedora specifically) it goes back instantly. The moment the original server is back, it is using it. And always uses it when available.
cool - nice to know.. I wonder why Windows doesn't do that.
-
@Dashrender said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
Testing now, because I want to know...
On non-Windows (Fedora specifically) it goes back instantly. The moment the original server is back, it is using it. And always uses it when available.
cool - nice to know.. I wonder why Windows doesn't do that.
Time-To-Live is shorter?
-
Or it something to do with Fedora using mDNS and avahi.
-
@black3dynamite said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
Testing now, because I want to know...
On non-Windows (Fedora specifically) it goes back instantly. The moment the original server is back, it is using it. And always uses it when available.
cool - nice to know.. I wonder why Windows doesn't do that.
Time-To-Live is shorter?
TTL isn't used at all. TTL doesn't apply to DNS selection in this case.
-
@Dashrender said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
Testing now, because I want to know...
On non-Windows (Fedora specifically) it goes back instantly. The moment the original server is back, it is using it. And always uses it when available.
cool - nice to know.. I wonder why Windows doesn't do that.
The logic is probably something from the 1990s that no one has addressed again to deal with how things should reasonably work in the modern world.
-
@black3dynamite said in DNS Update Issue:
Or it something to do with Fedora using mDNS and avahi.
More likely just Windows being the odd man out here. I expect everyone else behaves like Fedora. It's just a way more logical, and simple, approach.
-
Does anyone know what event causes this in Windows?
-
@wirestyle22 said in DNS Update Issue:
Does anyone know what event causes this in Windows?
Cause what, the NIC to flip? I've heard Windows people say that it's just a bug and it does it randomly. I know that it could happen from a DNS server being unavailable for a split second, just long enough to fail a lookup.
-
@scottalanmiller said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
Does anyone know what event causes this in Windows?
Cause what, the NIC to flip? I've heard Windows people say that it's just a bug and it does it randomly. I know that it could happen from a DNS server being unavailable for a split second, just long enough to fail a lookup.
That was my initial thought. So what--Linux OSes are checking periodically to see if they are using the first entry and Windows doesn't care until there's a hiccup?
