DNS Update Issue
-
With the Linux way, I get the best DNS performance 99.99% of the time. And I get far broader failover options. I can, at the client level, fail between several internal DNS servers AND if those all fail, I can fail to public DNS, too. It gives me "more protection", not less. Which is really nice if I have to have DNS set statically and have machines that might move off of the 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:
@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.
It's only a benefit there. For people using public, you want the Linux way. Really for everyone you want the Linux way except a very niche group of people in medium or larger businesses that somehow have non-stop DNS problems.
The thing is is that when the Linux way fails, it fails "soft" and no one notices because the negatives are SO minor. But when the Windows way fails, it fails "hard" and causes things to not work potentially.
You're making that claim - why? because you believe that using a public DNS should be totally acceptable for client machines as a secondary DNS?
Of course it SHOULD be acceptable. How the hell is it okay for Windows to be so broken that reasonable failovers, whether secondary or tertiary or whatever, have to be avoided because the platform is flaky and doesn't behave predictably or usefully?
I disagree, because assuming you have an additional working internal DNS server you should always fail to that to make sure you continue to have access to internal records.
And HOW is that disagreeing? You didn't state anything that is disagreeing at all.
-
@Dashrender said in DNS Update Issue:
And it doesn't matter that public is in use here. This applies equally to other internal servers, too. What if you failed to a slow DNS over a throttled WAN link and now are stuck with it because Windows never goes back to local primary?
OK - you do have a point here. though trying each and everytime does seem like overkill and lag inducing. I could see checking once a min or something.
It might seem like overkill, but it's not. It's the simplest, fastest solution. I think the crux here is that you perceive that delay as being far more dramatic and important than it is. And I suspect that you believe DNS failures are more common and long term than they typically are.
The impact of that "trying every time" is undetectable to normal users, remember their local systems cache so it's super trivial to have it do this in the real world. And normal failures for DNS are insanely short lived, like seconds or a minute as a server reboots, typically.
In the real world, doing secondary lookups for a full minute when the server is already back is the actual overkill, on average.
-
@scottalanmiller said in DNS Update Issue:
@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.
You said that it seemed odd to you, "why add in that delay every time."
It shouldn't be odd, it should be super obvious as by far the best way. And that "delay every time" is an imperceptible delay .001% of the time. It only seems like "Every time" if you assume random DNS choices like people keep saying that Windows makes (I'm not convinced of this). Since Linux DNS is deterministic, it only adds that minuscule delay under failure conditions which in this day and age are super, duper rare (unless, apparently, you have Windows then the desktop seems to inject a server-like failure condition on its own.)
You make it sound like this is a foolish approach, but it fixes the problems everyone is reporting with essentially no downsides.
Well, I've missed the recent posts where people had sorta messed up DNS configs (Wirestyle's were completely hosed, not just public as a secondary issue), so I'm not sure where the recent issue is coming from - I just must have missed them.
The Linux way is also assuming that the failure most likely was simply intermittent and that the primary will be back online nearly instantly, and frankly, using public DNS that totally makes sense. But we could hope that wouldn't be the case on a local network - and again, I'm not sure it still is a real issue.
Does the linux way make things more transparent to the user? Sure does. And the cost, as you said, it pretty damned low... So fine - I'll give you all that, and if Windows changed to that method I definitely wouldn't complain.
-
@scottalanmiller said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
And it doesn't matter that public is in use here. This applies equally to other internal servers, too. What if you failed to a slow DNS over a throttled WAN link and now are stuck with it because Windows never goes back to local primary?
OK - you do have a point here. though trying each and everytime does seem like overkill and lag inducing. I could see checking once a min or something.
It might seem like overkill, but it's not. It's the simplest, fastest solution. I think the crux here is that you perceive that delay as being far more dramatic and important than it is. And I suspect that you believe DNS failures are more common and long term than they typically are.
The impact of that "trying every time" is undetectable to normal users, remember their local systems cache so it's super trivial to have it do this in the real world. And normal failures for DNS are insanely short lived, like seconds or a minute as a server reboots, typically.
In the real world, doing secondary lookups for a full minute when the server is already back is the actual overkill, on average.
you undoubtedly have data that shows DNS outages are that short lived, I assume.
I know I know - you'll ask me for data that shows that DNS outages are longer.. tit for tat.
-
@Dashrender said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
And it doesn't matter that public is in use here. This applies equally to other internal servers, too. What if you failed to a slow DNS over a throttled WAN link and now are stuck with it because Windows never goes back to local primary?
OK - you do have a point here. though trying each and everytime does seem like overkill and lag inducing. I could see checking once a min or something.
It might seem like overkill, but it's not. It's the simplest, fastest solution. I think the crux here is that you perceive that delay as being far more dramatic and important than it is. And I suspect that you believe DNS failures are more common and long term than they typically are.
The impact of that "trying every time" is undetectable to normal users, remember their local systems cache so it's super trivial to have it do this in the real world. And normal failures for DNS are insanely short lived, like seconds or a minute as a server reboots, typically.
In the real world, doing secondary lookups for a full minute when the server is already back is the actual overkill, on average.
you undoubtedly have data that shows DNS outages are that short lived, I assume.
I know I know - you'll ask me for data that shows that DNS outages are longer.. tit for tat.
The average DNS outage is a server reboot. Think about an AD environment with two AD servers. You do updates and reboot all of the time, that's an outage to the clients looking at that specific server. In the Linux case, it would only use the backup entry for the moments while the service is restarting. In Windows, apparently, it simply abandones that server until it has no choice but to return.
-
@Dashrender said in DNS Update Issue:
The Linux way is also assuming that the failure most likely was simply intermittent and that the primary will be back online nearly instantly, and frankly, using public DNS that totally makes sense. But we could hope that wouldn't be the case on a local network - and again, I'm not sure it still is a real issue.
Even private DNS, what kind of failure do you have where you assume that the outage will be a long time, but not so long that DHCP updates are in order? That's a pretty rare, small window of failures. DNS restarts (outages) are common. Total failures are once every 5-10 years if we are talking enterprise AD DNS setups. Typically it would be totally dead hardware - but only in a case where a backup and restore aren't an option.
DNS is something that restarts very quickly, and can be restored very quickly. And can normally be adjusted almost instantly via DHCP or state management, however you manage DNS in your environment.
So even in pretty extreme failures, a DNS failures is usually intermittent, even in a purely internal DNS situation.
-
@scottalanmiller said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
The Linux way is also assuming that the failure most likely was simply intermittent and that the primary will be back online nearly instantly, and frankly, using public DNS that totally makes sense. But we could hope that wouldn't be the case on a local network - and again, I'm not sure it still is a real issue.
Even private DNS, what kind of failure do you have where you assume that the outage will be a long time, but not so long that DHCP updates are in order? That's a pretty rare, small window of failures. DNS restarts (outages) are common. Total failures are once every 5-10 years if we are talking enterprise AD DNS setups. Typically it would be totally dead hardware - but only in a case where a backup and restore aren't an option.
DNS is something that restarts very quickly, and can be restored very quickly. And can normally be adjusted almost instantly via DHCP or state management, however you manage DNS in your environment.
So even in pretty extreme failures, a DNS failures is usually intermittent, even in a purely internal DNS situation.
We both agree that Windows NEVER switching back is bad. let's move past that. Now the question is - is it worth it to test on every single DNS query.
From a coding POV, it's probably much simpler to test every time than setting a time variable and waiting for that to expire before trying the primary again - so fine.. you win.
-
@Dashrender said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
The Linux way is also assuming that the failure most likely was simply intermittent and that the primary will be back online nearly instantly, and frankly, using public DNS that totally makes sense. But we could hope that wouldn't be the case on a local network - and again, I'm not sure it still is a real issue.
Even private DNS, what kind of failure do you have where you assume that the outage will be a long time, but not so long that DHCP updates are in order? That's a pretty rare, small window of failures. DNS restarts (outages) are common. Total failures are once every 5-10 years if we are talking enterprise AD DNS setups. Typically it would be totally dead hardware - but only in a case where a backup and restore aren't an option.
DNS is something that restarts very quickly, and can be restored very quickly. And can normally be adjusted almost instantly via DHCP or state management, however you manage DNS in your environment.
So even in pretty extreme failures, a DNS failures is usually intermittent, even in a purely internal DNS situation.
We both agree that Windows NEVER switching back is bad. let's move past that. Now the question is - is it worth it to test on every single DNS query.
From a coding POV, it's probably much simpler to test every time than setting a time variable and waiting for that to expire before trying the primary again - so fine.. you win.A wait "called a stand off period" would be easy, not AS easy, but trivially easy. But I think in the real world, it's not as ideal. With how DNS works today (not in the 1990s) I think it is what you would want. Having any stand off period would introduce more overhead (on average) that it would resolve. Because normal outages are so tiny, and so much DNS is cached.
-
@scottalanmiller said in DNS Update Issue:
In Windows, apparently, it simply abandones that server until it has no choice but to return.
I don't see any issue there. You're getting DNS either way, what's it matter what it's from if they are the same? If clients are getting DNS from the failover DNS server and you don't want it to, turn off the DNS service on that server then, and clients will fail back... if you even care.
-
@Obsolesce said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
In Windows, apparently, it simply abandones that server until it has no choice but to return.
I don't see any issue there. You're getting DNS either way, what's it matter what it's from if they are the same? If clients are getting DNS from the failover DNS server and you don't want it to, turn off the DNS service on that server then, and clients will fail back... if you even care.
The problem happens when your secondary server isn't part of your internal network (assuming your primary is part of your internal network). When using the secondary you won't get resolution for internal network resources.
-
-
@Obsolesce said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
In Windows, apparently, it simply abandones that server until it has no choice but to return.
I don't see any issue there. You're getting DNS either way, what's it matter what it's from if they are the same? If clients are getting DNS from the failover DNS server and you don't want it to, turn off the DNS service on that server then, and clients will fail back... if you even care.
That's a pretty awful process. I mean... horrendous. Kill a server just to get clients back to where you want them to be?
ANd since it is random, that doesn't even work.
-
@Dashrender said in DNS Update Issue:
@Obsolesce said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
In Windows, apparently, it simply abandones that server until it has no choice but to return.
I don't see any issue there. You're getting DNS either way, what's it matter what it's from if they are the same? If clients are getting DNS from the failover DNS server and you don't want it to, turn off the DNS service on that server then, and clients will fail back... if you even care.
The problem happens when your secondary server isn't part of your internal network (assuming your primary is part of your internal network). When using the secondary you won't get resolution for internal network resources.
That's the BIG problem. But not the only one. Take a common manufacturing plant with one AD at one site, and the other one at a different site. If you can't choose primary or secondary, then failover means slow DNS over a WAN link - potentially for weeks or months at a time. Sometimes for no reason at all, or something as simple as having rebooting the local one.
It's not just wanting to use a public source, that clouds the issue. Lots of people don't want to use public ever, so ignore that. It's bad behaviour regardless.
-
@scottalanmiller said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@Obsolesce said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
In Windows, apparently, it simply abandones that server until it has no choice but to return.
I don't see any issue there. You're getting DNS either way, what's it matter what it's from if they are the same? If clients are getting DNS from the failover DNS server and you don't want it to, turn off the DNS service on that server then, and clients will fail back... if you even care.
The problem happens when your secondary server isn't part of your internal network (assuming your primary is part of your internal network). When using the secondary you won't get resolution for internal network resources.
That's the BIG problem. But not the only one. Take a common manufacturing plant with one AD at one site, and the other one at a different site. If you can't choose primary or secondary, then failover means slow DNS over a WAN link - potentially for weeks or months at a time. Sometimes for no reason at all, or something as simple as having rebooting the local one.
It's not just wanting to use a public source, that clouds the issue. Lots of people don't want to use public ever, so ignore that. It's bad behaviour regardless.
@scottalanmiller is describing my setup because he has seen it.
-
@Donahue said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@Obsolesce said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
In Windows, apparently, it simply abandones that server until it has no choice but to return.
I don't see any issue there. You're getting DNS either way, what's it matter what it's from if they are the same? If clients are getting DNS from the failover DNS server and you don't want it to, turn off the DNS service on that server then, and clients will fail back... if you even care.
The problem happens when your secondary server isn't part of your internal network (assuming your primary is part of your internal network). When using the secondary you won't get resolution for internal network resources.
That's the BIG problem. But not the only one. Take a common manufacturing plant with one AD at one site, and the other one at a different site. If you can't choose primary or secondary, then failover means slow DNS over a WAN link - potentially for weeks or months at a time. Sometimes for no reason at all, or something as simple as having rebooting the local one.
It's not just wanting to use a public source, that clouds the issue. Lots of people don't want to use public ever, so ignore that. It's bad behaviour regardless.
@scottalanmiller is describing my setup because he has seen it.
It's a common, real world setup that makes sense. But non-deterministic DNS behaviour from Windows would be less than ideal for use in that environment. Not a show stopper, especially with a Gig link between sites, but a silly problem to have that doesn't need to exist.
-
@scottalanmiller the only problem with Microsoft Windows DNS Clients when used for authentication that it is so random to choose which DC to login to which makes it so unpredictable. But I know that it out of the main scope of this discussion, but wanted to clarify that.
-
@scottalanmiller said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@Obsolesce said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
In Windows, apparently, it simply abandones that server until it has no choice but to return.
I don't see any issue there. You're getting DNS either way, what's it matter what it's from if they are the same? If clients are getting DNS from the failover DNS server and you don't want it to, turn off the DNS service on that server then, and clients will fail back... if you even care.
The problem happens when your secondary server isn't part of your internal network (assuming your primary is part of your internal network). When using the secondary you won't get resolution for internal network resources.
That's the BIG problem. But not the only one. Take a common manufacturing plant with one AD at one site, and the other one at a different site. If you can't choose primary or secondary, then failover means slow DNS over a WAN link - potentially for weeks or months at a time. Sometimes for no reason at all, or something as simple as having rebooting the local one.
It's not just wanting to use a public source, that clouds the issue. Lots of people don't want to use public ever, so ignore that. It's bad behaviour regardless.
I've never seen this. We have a DC at one site and a DC at another site. DNS at the computers primary site is always preferred.
Perhaps the whole issue is because AD sites aren't set up properly.
I'll test this now in a properly set up AD environment.
-
@dbeato said in DNS Update Issue:
@scottalanmiller the only problem with Microsoft Windows DNS Clients when used for authentication that it is so random to choose which DC to login to which makes it so unpredictable. But I know that it out of the main scope of this discussion, but wanted to clarify that.
Performance of the DNS itself and traffic on a limited WAN link are also concerns.
-
@Obsolesce said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@Obsolesce said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
In Windows, apparently, it simply abandones that server until it has no choice but to return.
I don't see any issue there. You're getting DNS either way, what's it matter what it's from if they are the same? If clients are getting DNS from the failover DNS server and you don't want it to, turn off the DNS service on that server then, and clients will fail back... if you even care.
The problem happens when your secondary server isn't part of your internal network (assuming your primary is part of your internal network). When using the secondary you won't get resolution for internal network resources.
That's the BIG problem. But not the only one. Take a common manufacturing plant with one AD at one site, and the other one at a different site. If you can't choose primary or secondary, then failover means slow DNS over a WAN link - potentially for weeks or months at a time. Sometimes for no reason at all, or something as simple as having rebooting the local one.
It's not just wanting to use a public source, that clouds the issue. Lots of people don't want to use public ever, so ignore that. It's bad behaviour regardless.
I've never seen this. We have a DC at one site and a DC at another site. DNS at the computers primary site is always preferred.
Perhaps the whole issue is because AD sites aren't set up properly.
I'll test this now in a properly set up AD environment.
I've not seen it either. But it is the reason behind most everyone's decision making around WIndows DNS clients. So my point is that either that reason is false and Windows doesn't actually do this, or it's significant.
