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:
@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?
-
@wirestyle22 said in DNS Update Issue:
@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?
Linux checks every time, I believe. That's the expected behaviour. It always uses its list top to bottom, it doesn't "change" primary just because it wants to.
-
@scottalanmiller said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@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?
Linux checks every time, I believe. That's the expected behaviour. It always uses its list top to bottom, it doesn't "change" primary just because it wants to.
See this just seems odd to me - why add in that delay every time. The way windows does it - once it flips it doesn't flip back until the current DNS server blips - makes sense. Stay stable, stay on what is working.
There shouldn't be an issue with this - assuming your DNS setup is correct.But flipping back each and every time adds latency to your DNS queries for at best a minor benefit (again, assuming a correctly setup DNS environment).
-
@Dashrender said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@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?
Linux checks every time, I believe. That's the expected behaviour. It always uses its list top to bottom, it doesn't "change" primary just because it wants to.
See this just seems odd to me - why add in that delay every time. The way windows does it - once it flips it doesn't flip back until the current DNS server blips - makes sense. Stay stable, stay on what is working.
There shouldn't be an issue with this - assuming your DNS setup is correct.But flipping back each and every time adds latency to your DNS queries for at best a minor benefit (again, assuming a correctly setup DNS environment).
See, you say "little benefit" in the midst of a whole thread about how Linux works beautifully because of this and Windows is flaky and unreliable. Can't be both. Either Windows works and all of that is BS, or clearly this isn't a trivial thing. The DNS delay only happens when your set primary is down, which is almost never in the modern world. If you have issues that your DNS is always down, stop using it as your primary.
You are using something that isn't a real world problem and acting like it affects someone when it doesn't, while ignoring a real world problem that has clearly impacted nearly everyone in this thread (and others, this has come up multiple times in the last few weeks alone) that this behaviour solves.
So I think it's pretty clear why Linux chooses to work the way that it does, and extremely clear why it is what we'd always prefer.
The Windows way only makes sense under the assumption that you always are using internal DNS, not public, and that you have only local DNS servers in your pool. It's most useful only under a very specific set of circumstances where you are going with AD and LAN-based, and you have redundancy locally, not redundancy over a WAN link like many SMBs do.
-
Well - frankly - I have no clue how much of a real issue this is any more. I haven't had incorrectly setup DNS in ages.
I suppose I could setup my PC with google for a secondary, then what - make a script that tries pinging one of my internal resources by DNS name and see if/ever it fails?
-
@scottalanmiller said in DNS Update Issue:
(and others, this has come up multiple times in the last few weeks alone)
It has? where?
-
@scottalanmiller said in DNS Update Issue:
It's most useful only under a very specific set of circumstances where you are going with AD and LAN-based, and you have redundancy locally, not redundancy over a WAN link like many SMBs do.
Or the opposite - home users who generally only have public DNS servers. or travelers who also only generally have public DNS servers.
In fact, this is only an issue for those who do have internal DNS servers with internal only records.
-
@Dashrender said in DNS Update Issue:
Well - frankly - I have no clue how much of a real issue this is any more. I haven't had incorrectly setup DNS in ages.
I suppose I could setup my PC with google for a secondary, then what - make a script that tries pinging one of my internal resources by DNS name and see if/ever it fails?
It's enough of an issue that everyone recommends not having public failover from clients because they perceive it as simply not workable. So either it's actually a big deal, or all that advice is wrong.
