DNS Update Issue
-
@wirestyle22 said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@JaredBusch said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@JaredBusch said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@JaredBusch said in DNS Update Issue:
@PhlipElder said in DNS Update Issue:
@JaredBusch said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
Simple case of me never doing this wrong I guess. What a weird thing to screw up. Didn't really have time to sift through it all.
What do you normally use for your top level domain on an AD build?
ad.domain.com theoretically. Everything I've ever touched is already in place. Although i'd love to rebuild my families infrastructure from the ground up.
If it looks like this, then it owns domain.com
Oh man, what a mess.
Meh, not bad actually. Perfect? No. But small enough to not be a problem really.
Definitely not what I would do now if I set it up new.
This is just a throw back to the new days of AD. MS suggested just this - then after a while they suggested domain.local for the internal domain, and now they recommend ad.domain.com for the internal domain.
MS originally suggested domain.local and stuck to it for a long time. That's how it started.
Pretty sure domain.local wasn't the thing in Windows 2000 days, that came in 2003 and lasted, as you said, a long time.
In 2000, it was simply
domainMan - I know that a TON of people did that - but I didn't think that was the actual recommendation. I guess I'd have to find some old Win2K docs....
I don't know about MS recommendation, but when I was setting up NT4 networks prior to 2000, it was the recommendation from the company on how to setup their stuff.
NT4, yes. But it behaved differently. AD I thought started with the .local recommendation.
We have a .local here
That's traditional and would be fine if Apple didn't sabotage it. If you have no Macs, it still works fine.
-
@wirestyle22 said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@pmoncho said in DNS Update Issue:
@Donahue said in DNS Update Issue:
man, after reading all this, I am pretty sure my DNS is not correct.
I think I am with ya on this one.
So let me get this straight. On DC0 with AD Integrated DNS, Preferred DNS should be IP address of DC0 and Alternate DNS should be 127.0.0.1?
Currently I point DC0 Preferred to itself and Alternate to DC1. I have not had any issue over the last X amount of years so I don't know what the actual issue is with my current setup.
I currently have a .local also (setup by a contractor a long time ago).
There is no issue with your setup.
It's possible that the NIC itself could have an issue which would make your use of the actual IP fail connectivity, but the loopback would still function - but, I said there was an issue with the NIC, so does it matter if the loopback works when you can't get on the network?
As for having a secondary DNS entry - it protects you against the local DNS service itself failing, provides you a backup, just like secondary DNS to client machines have a backup DNS server to communicate with.
If the dns service fails on DC1 though, wouldn't the reference to dc2 fail too and thus switch to the second dns entry, DC2 for the workstation
It's if the DNS on DC1 goes down, but DC1 stays up itself, and the DNC on DC2 stays up, so pointing to both does, in fact, provide some protection.
-
@wirestyle22 said in DNS Update Issue:
@pmoncho said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@pmoncho said in DNS Update Issue:
@Donahue said in DNS Update Issue:
man, after reading all this, I am pretty sure my DNS is not correct.
I think I am with ya on this one.
So let me get this straight. On DC0 with AD Integrated DNS, Preferred DNS should be IP address of DC0 and Alternate DNS should be 127.0.0.1?
Currently I point DC0 Preferred to itself and Alternate to DC1. I have not had any issue over the last X amount of years so I don't know what the actual issue is with my current setup.
I currently have a .local also (setup by a contractor a long time ago).
There is no issue with your setup.
It's possible that the NIC itself could have an issue which would make your use of the actual IP fail connectivity, but the loopback would still function - but, I said there was an issue with the NIC, so does it matter if the loopback works when you can't get on the network?As for having a secondary DNS entry - it protects you against the local DNS service itself failing, provides you a backup, just like secondary DNS to client machines have a backup DNS server to communicate with.
If the dns service fails on DC1 though, wouldn't the reference to the dc fail too and thus switch to the second dns entry, DC2 for the workstation
That is what I want to happen correct? As long as replication between the two DC's was fine prior to the issue with DC1. Am I missing something?
I'm saying the reference to DC2 from DC1 doesn't matter if the dns service fails on DC1. It would stop referencing DC2, right? Specifically replying to @Dashrender's comment.
No, if DC1 fails, it would then use DC2. Why do you see DC2 stopping just because DC1 does?
-
@pmoncho said in DNS Update Issue:
@Donahue said in DNS Update Issue:
man, after reading all this, I am pretty sure my DNS is not correct.
I think I am with ya on this one.
So let me get this straight. On DC0 with AD Integrated DNS, Preferred DNS should be IP address of DC0 and Alternate DNS should be 127.0.0.1?
Currently I point DC0 Preferred to itself and Alternate to DC1. I have not had any issue over the last X amount of years so I don't know what the actual issue is with my current setup.
I currently have a .local also (setup by a contractor a long time ago).
mine is the same. First is it's own IP, secondary is the other DC
-
@Dashrender said in DNS Update Issue:
@JaredBusch said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
As for having a secondary DNS entry - it protects you against the local DNS service itself failing, provides you a backup, just like secondary DNS to client machines have a backup DNS server to communicate with.
No. You don’t put anything in there. The local DNS service is not going to fail. If it does, the. You have a fail state just like any other fail state and you deal with it.
Why hamstring the whole system because a single service failed. I'm already mentioned that it's extremely unlikely that DNS Server will fail on its own, but it is possible.
Not just if it fails, but also if it is just stopped say through a human shutting it down.
-
@wirestyle22 said in DNS Update Issue:
@Dashrender A computer is making a request of DC1. DC1's dns service has failed. computer receives no response and moves to DC2 (the second dns entry). This is what I am referring to. Why would DC1 need to reference DC2 in it's own DNS entries? The replication is something else entirely and doesnt rely on the dns service. Am I missing something? If the DNS service fails it's just a failure regardless of other entries.
Because you don't want DC1 to lose DNS for itself just because its one service has failed.
-
@JaredBusch said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
DNS servers run two services
- DNS Server Service
- DNS Client Service
Client machines only run one
- DNS Client Service
In the case where an AD w/integrated DNS has it's DNS Server Service fail, the DNS Client Service is likely unaffected. So the DNS Client Service will see (rather not see a response) a failure from the local (primary DNS) and failover to the secondary DNS.
So, you are intentionally breaking the DNS design, to hide the fact that the DNS server is broken.
What is the point of this?
Reliability. Other functions keep working, DNS is presumably not the only thing that is on the box. Like any high availability approach, the goal is not to hide problems from being discovered, but to stop outages from impacting end users.
-
@JaredBusch said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@Dashrender A computer is making a request of DC1. DC1's dns service has failed. computer receives no response and moves to DC2 (the second dns entry). This is what I am referring to. Why would DC1 need to reference DC2 in it's own DNS entries? The replication is something else entirely and doesnt rely on the dns service. Am I missing something? If the DNS service fails it's just a failure regardless of other entries.
You are mixing things, just fucking stop.
This discussion is strictly related to DNS server functionality. Client connectivity is unrelated.
Of course DC1 needs a reference to DC2 in its own DNS tables, because it is all replicated and all systems know all. This also has nothing to do with NIC DNS settings..
NIC DNS settings are strictly for the DNS client service on a system to access..
The discussion that I saw was asking about NIC settings, not just server sync.
-
@JaredBusch said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@Dashrender A computer is making a request of DC1. DC1's dns service has failed. computer receives no response and moves to DC2 (the second dns entry). This is what I am referring to. Why would DC1 need to reference DC2 in it's own DNS entries? The replication is something else entirely and doesnt rely on the dns service. Am I missing something? If the DNS service fails it's just a failure regardless of other entries.
Correct - that's how the client works.
But the server is also a client. Active Directory needs to make a DNS call - so it looks to the IP stack and gets the primary DNS server IP - which fails to respond. If there is no secondary DNS server, the AD service on this server now fails. BUT if you have a secondary DNS entry in the IP settings, then the IP stack will flip over to using the secondary DNS listed... and now get a response for Active Directory.
If 127.0.0.1 fails to respond to a DNS request, you have issues that need resolved. Dont mask it.
That's the same as saying "if a drive fails, just lose the data, don't hide the drive failing." Less dramatic, but same concept. We have RAID so that we can "mask" a failure and recover elegantly without impacting the users. Same idea here.
-
@Dashrender said in DNS Update Issue:
@JaredBusch said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@Dashrender A computer is making a request of DC1. DC1's dns service has failed. computer receives no response and moves to DC2 (the second dns entry). This is what I am referring to. Why would DC1 need to reference DC2 in it's own DNS entries? The replication is something else entirely and doesnt rely on the dns service. Am I missing something? If the DNS service fails it's just a failure regardless of other entries.
Correct - that's how the client works.
But the server is also a client. Active Directory needs to make a DNS call - so it looks to the IP stack and gets the primary DNS server IP - which fails to respond. If there is no secondary DNS server, the AD service on this server now fails. BUT if you have a secondary DNS entry in the IP settings, then the IP stack will flip over to using the secondary DNS listed... and now get a response for Active Directory.
If 127.0.0.1 fails to respond to a DNS request, you have issues that need resolved. Dont mask it.
then there is never a reason to give a client a secondary DNS either - don't mask that problem.
Or to have a second AD / DNS at all, since all of that is to mask failures from the end users.
-
Ok, I am definitely getting confused between the DNS client settings that are set at the NIC, and some other internal setting in the DNS manager.
@JaredBusch Where are you saying we should set the loopback? What should the NIC settings be?
-
@wirestyle22 said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@JaredBusch said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@Dashrender A computer is making a request of DC1. DC1's dns service has failed. computer receives no response and moves to DC2 (the second dns entry). This is what I am referring to. Why would DC1 need to reference DC2 in it's own DNS entries? The replication is something else entirely and doesnt rely on the dns service. Am I missing something? If the DNS service fails it's just a failure regardless of other entries.
Correct - that's how the client works.
But the server is also a client. Active Directory needs to make a DNS call - so it looks to the IP stack and gets the primary DNS server IP - which fails to respond. If there is no secondary DNS server, the AD service on this server now fails. BUT if you have a secondary DNS entry in the IP settings, then the IP stack will flip over to using the secondary DNS listed... and now get a response for Active Directory.
If 127.0.0.1 fails to respond to a DNS request, you have issues that need resolved. Dont mask it.
then there is never a reason to give a client a secondary DNS either - don't mask that problem.
It's failover. I think what JB means is that if you have a problem you should know you have a problem
You find that with monitoring, not by making end users call you when things are broken. Sure you want to know, but there is a good way to find out, and a bad way.
-
@JaredBusch said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@JaredBusch said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@Dashrender A computer is making a request of DC1. DC1's dns service has failed. computer receives no response and moves to DC2 (the second dns entry). This is what I am referring to. Why would DC1 need to reference DC2 in it's own DNS entries? The replication is something else entirely and doesnt rely on the dns service. Am I missing something? If the DNS service fails it's just a failure regardless of other entries.
Correct - that's how the client works.
But the server is also a client. Active Directory needs to make a DNS call - so it looks to the IP stack and gets the primary DNS server IP - which fails to respond. If there is no secondary DNS server, the AD service on this server now fails. BUT if you have a secondary DNS entry in the IP settings, then the IP stack will flip over to using the secondary DNS listed... and now get a response for Active Directory.
If 127.0.0.1 fails to respond to a DNS request, you have issues that need resolved. Dont mask it.
then there is never a reason to give a client a secondary DNS either - don't mask that problem.
Incorrect, because a client system is not a DNS server. You don’t setup a client and a server the same.
Why not? From the client perspective (the client process that is) it's the same. Point primarily to one DNS server, then secondarily to a different one. Why would one client be different from another just because it has access to a local server?
-
@scottalanmiller said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@JaredBusch said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@Dashrender A computer is making a request of DC1. DC1's dns service has failed. computer receives no response and moves to DC2 (the second dns entry). This is what I am referring to. Why would DC1 need to reference DC2 in it's own DNS entries? The replication is something else entirely and doesnt rely on the dns service. Am I missing something? If the DNS service fails it's just a failure regardless of other entries.
Correct - that's how the client works.
But the server is also a client. Active Directory needs to make a DNS call - so it looks to the IP stack and gets the primary DNS server IP - which fails to respond. If there is no secondary DNS server, the AD service on this server now fails. BUT if you have a secondary DNS entry in the IP settings, then the IP stack will flip over to using the secondary DNS listed... and now get a response for Active Directory.
If 127.0.0.1 fails to respond to a DNS request, you have issues that need resolved. Dont mask it.
then there is never a reason to give a client a secondary DNS either - don't mask that problem.
Or to have a second AD / DNS at all, since all of that is to mask failures from the end users.
Masking problems isn't the goal but it's a side effect of doing it this way
-
@Donahue said in DNS Update Issue:
@pmoncho said in DNS Update Issue:
@Donahue said in DNS Update Issue:
man, after reading all this, I am pretty sure my DNS is not correct.
I think I am with ya on this one.
So let me get this straight. On DC0 with AD Integrated DNS, Preferred DNS should be IP address of DC0 and Alternate DNS should be 127.0.0.1?
Currently I point DC0 Preferred to itself and Alternate to DC1. I have not had any issue over the last X amount of years so I don't know what the actual issue is with my current setup.
I currently have a .local also (setup by a contractor a long time ago).
mine is the same. First is it's own IP, secondary is the other DC
That's what I do. Some people flip that, but you get lower latency with the major one being the local one.
-
@Donahue said in DNS Update Issue:
Ok, I am definitely getting confused between the DNS client settings that are set at the NIC, and some other internal setting in the DNS manager.
@JaredBusch Where are you saying we should set the loopback? What should the NIC settings be?
NIC to loopback, not the forwarders, forwarders can't look to the loopback, that would break a lot of things.
-
@scottalanmiller said in DNS Update Issue:
@Donahue said in DNS Update Issue:
Ok, I am definitely getting confused between the DNS client settings that are set at the NIC, and some other internal setting in the DNS manager.
@JaredBusch Where are you saying we should set the loopback? What should the NIC settings be?
NIC to loopback, not the forwarders, forwarders can't look to the loopback, that would break a lot of things.
I have no idea what you are saying. This is my NIC settings currently on my local DC. The first one is it's own IP, but not loopback.
-
@Donahue The first one (It's own IP) should be 127.0.0.1 is what they are saying
-
@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?
-
@wirestyle22 said in DNS Update Issue:
@scottalanmiller said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@JaredBusch said in DNS Update Issue:
@Dashrender said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@Dashrender A computer is making a request of DC1. DC1's dns service has failed. computer receives no response and moves to DC2 (the second dns entry). This is what I am referring to. Why would DC1 need to reference DC2 in it's own DNS entries? The replication is something else entirely and doesnt rely on the dns service. Am I missing something? If the DNS service fails it's just a failure regardless of other entries.
Correct - that's how the client works.
But the server is also a client. Active Directory needs to make a DNS call - so it looks to the IP stack and gets the primary DNS server IP - which fails to respond. If there is no secondary DNS server, the AD service on this server now fails. BUT if you have a secondary DNS entry in the IP settings, then the IP stack will flip over to using the secondary DNS listed... and now get a response for Active Directory.
If 127.0.0.1 fails to respond to a DNS request, you have issues that need resolved. Dont mask it.
then there is never a reason to give a client a secondary DNS either - don't mask that problem.
Or to have a second AD / DNS at all, since all of that is to mask failures from the end users.
Masking problems isn't the goal but it's a side effect of doing it this way
No more so than having RAID masks the problem. So it's better to have end user impact on DNS than it is from a drive failure?
