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.
Being a part of the SBS crew from the BackOffice 4.0 and 4.5 (NT) days, the .Local phenomena started around the discussion of Internet domain registration and keeping the internal and internet domains separate. That was prior to SBS 2003 that was the first product to deploy out of the box with .Local.
Some had to do with the confusion around registering the internet domain that was to be used internally. We used to encounter companies with Domain.Com that did not own the internet domain. It was painful to say the least.
AD was still relatively new so no one really new what to do about internal and external DNS though SBS 2003 did split the DNS for Remote.Domain.Com.
Besides wizards, which were primarily in the SBS realm, splitting the DNS became the norm and eventually the recommendation came about for Corp.Domain.Com with the caveat that the internet domain should be owned.
So, here we are. Most companies own their internet domains so it's a no-brainer to split the DNS for their setups.
-
It really doesn't matter so much. Many places .com works great, many .local works great. Some, like mine, AD is .local but we also have onprem .com and public .com. Any issues? Not a single one, ever.
For the DNS server itself, it's own FQDN first, secondary DNS server(s) next, loopback last. For DNS or DHCP, you can have CF in there too.
-
@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).
-
@pmoncho No. The only entry should be 127.0.0.1. Always loopback.
-
@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.
-
@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
-
@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?
-
@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.
-
@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.
Oh, I see what your saying. Good question and I am awaiting that answer.
-
@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.
You're mixing things together. DNS server service and syncing is it's own thing.
The IP stack referencing a DNS server based on the DNS primary and DNS secondary in the IP settings are completely separate. -
@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.
-
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.
-
@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.
-
@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.
-
@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.
@wirestyle22 I don't think you are missing anything, we discussed that yesterday over PM and it is as you said. I for some reason thought differently although I knew DNS replicate automatically through AD. As it is, you shouldn't need to use another DNS Server on DC1 or viceversa on DC2.
-
@dbeato eh? We didn't talk in PM yesterday. Was it someone else? Last thing we spoke about was ansible I thought
-
@wirestyle22 said in DNS Update Issue:
@dbeato eh? We didn't talk in PM yesterday. Was it someone else? Last thing we spoke about was ansible I thought
Sorry no PM,Telegram!
-
@dbeato said in DNS Update Issue:
@wirestyle22 said in DNS Update Issue:
@dbeato eh? We didn't talk in PM yesterday. Was it someone else? Last thing we spoke about was ansible I thought
Sorry no PM,Telegram!
Oh the group. Sure we were all talking.
-
@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?
-
@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.
