nestey
asked on
How does my internal network receive external DNS
I have a 2008 domain with 2 internal DNS servers. DNS was setup by a consultant so I trying to get see what external DNS servers my network uses. I have notes written down that says the external DNS should be xxx.xxx.xxx.xxx but I called my ISP to make sure these were the correct ones and was told no these were static address and I should be using a different set of numbers. So I have been looking in my settings to change it but can not find anywhere that the old external ip's are listed? All of my servers point to the internal DNS servers even the DNS servers themself? I have looked on our firewall and do not see anything listed there as well?
How does my internal DNS servers get External DNS?
How does my internal DNS servers get External DNS?
Does your internet access work right now? Follow the advice from Scott on what to look for on your internal servers.
What type of firewall do you have, and do you have a static or dynamic public IP? If static, then the DNS servers should be set somewhere. Otherwise, that info should come from the DHCP server at the ISP.
What type of firewall do you have, and do you have a static or dynamic public IP? If static, then the DNS servers should be set somewhere. Otherwise, that info should come from the DHCP server at the ISP.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hi All,
Everything works fine, I have to send this information to our parent company as they are sending me a device for a VPN connection. They asked for an IP on my LAN along with full information gateway / dns / netmask and also a public IP with default gateway / netmask etc .. so I wanted to make sure I gave them the correct DNS? If I can use any DNS servers I will give them the ones recommended by my ISP and not worry about what I have in my old notes.
Scott, I opened DNS Manager and right clicked on my DNS server then selected properties and then the Forwarder tab and there is nothing listed there.
masnrock, My servers have static IP's
Footech, what are root hints?
Everything works fine, I have to send this information to our parent company as they are sending me a device for a VPN connection. They asked for an IP on my LAN along with full information gateway / dns / netmask and also a public IP with default gateway / netmask etc .. so I wanted to make sure I gave them the correct DNS? If I can use any DNS servers I will give them the ones recommended by my ISP and not worry about what I have in my old notes.
Scott, I opened DNS Manager and right clicked on my DNS server then selected properties and then the Forwarder tab and there is nothing listed there.
masnrock, My servers have static IP's
Footech, what are root hints?
OK, I'll say it. Unless you have a specific reason or configuration, do not use forwarders. They create more problems than they "solve". As you saw, you had some wrong addresses written down. You don't worry about incorrect external DNS settings if you don't use forwarders. I expound on that below. Forwarders were so,"10 years" ago.
DNS….. This is one of the most misunderstood beasts on every network and the one I see misconfigured most of the time. Too often these are over complicated or those without the requisite knowledge configures it according to what they “think”.
The absolute best way to do this is to adhere to Microsoft’s Best Practices.
In an Active Directory network, we need to use the KISS method and use our devices and services the way they were designed. In short, let the Domain Controllers handle DNS internally and when there is an external request that is not in the cache, let them go to the root servers. That is all there is to it.
So, let’s say you have 2 Domain Controllers, DC01 and DC02. On the NIC of DC01 you should have a static IP address and the primary DNS server should be DC01’s own IP address. You point it to itself. The secondary DNS server setting should have the IP address of DC02. On DC02’s NIC, its primary DNS server setting should point to DC01 and the secondary address should point to itself. Now those servers are setup properly as far as the NICs.
Inside the DNS server you have your forward lookup zone. Make sure you also setup a Reverse Lookup Zone for your subnet(s).
Your Server should have Server Aging/Scavenging setup for all zones to Scavenge stale resource records. The default of 7 days is fine.
In the Server properties almost everything can stay as the default.
On the Forwarders tab, remove any forwarders. You do not need them except for a very narrow set of circumstances. I can tell you in my decades of networking, I have only seen 2 times that these were ever needed. Also remove any Conditional forwarders. For most networks, you will never have to deal with these. You also never have to worry about proper settings if you switch ISP’s, move offices, etc., because your DNS server will always go to the root servers and does not care what your ISP is or what their DNS server addresses are.
Root Servers (Root Hints): The authoritative name servers that serve the DNS root zone, commonly known as the “root servers”, are a network of hundreds of servers in many countries around the world. They are configured in the DNS root zone as 13 named authorities. There is no better place for your DNS server to resolve external requests.
If you use your Domain Controllers for your DHCP servers also, setup the DNS in your scopes to point to DC01 and DC02 in that order. I have seen DC’s used for this in smaller networks where they are the only servers. Where you do have additional servers, Best Practices is to put the DHCP servers on something other than a DC.
Note: If your DHCP servers are on a server that is not a Domain Controller, you need to add those servers to the Active Directory Security Group, DNSUpdateProxy so that they can register clients with your DNS servers.
Generally, I setup 2 DHCP servers for fault tolerance and set them up almost identically. So for example if my internal IP Addressing scheme was 192.168.1.x, I would setup the scopes to go from .1 to 254. On both I would exclude, for example the ranges from .1 to .69. This is where I put all my static IP addresses. Then I exclude, for example 70 – 99. This is for future use should I need to free up 30 more addresses later for DHCP addresses. Finally, on DHCP Server #1 I would hand out addresses 100-177 and Exclude 178-254. On DHCP Server #2 I would Exclude addresses 100-177 and give out addresses 178-254. This way they do not step on each other and should either die, I still have a functioning DHCP Server.
Finally, on the DHCP IPv4 properties, under the DNS tab, Ensure that “Enable DNS dynamic updates………” is checked, as is “Always dynamically update DNS records”. You also want to check, “Dynamically update DNS records for DHCP clients that do not request updates…….”
Setting things up this way is the KISS method and you have full redundancy if you lose a DC, DNS Server or DHCP Server.
Resolving Names
When that name resolution request from the client hits DC01, from the settings it got statically or via DHCP, DC01 attempts to resolve it. If it is internal, it should have that information as we told the DHCP servers to ensure everyone is registered with DNS. If that request is for an external site, DC01 checks its cache and if it does not find the information, goes directly out to the Internet Root Servers for the information. Once resolved, DC01 Caches the information for the next time.
If you use forwarders here, you put another step in the process and introduce another single point of failure. If your ISP goes down, or their DNS servers are hit by DOS attacks or just that internet pipe to their servers goes down because some construction crew severed their fiber, you may have no resolution because the servers don’t answer or you time out. Also, if the ISP has old Cache data, you may not get the correct resolved address. ISP’s have been known to change their DNS server addresses in the past and not notified their customers.
Using Root Hints though, you always get the best, most accurate data. There is a lot less chance all the internet root servers would get hit with DOS attacks, and should one internet pipe go down, like with a poisoned route, severed fiber, etc., there is a very good chance that the rest will all be working. You also eliminate that single point of failure or the extra hops by using the ISP’s DNS serves as your middle man.
This is the way DNS was designed to work and it does that very well.
So, there you have it, the KISS method. You have redundancy and fault tolerance all rolled into one.
DNS….. This is one of the most misunderstood beasts on every network and the one I see misconfigured most of the time. Too often these are over complicated or those without the requisite knowledge configures it according to what they “think”.
The absolute best way to do this is to adhere to Microsoft’s Best Practices.
In an Active Directory network, we need to use the KISS method and use our devices and services the way they were designed. In short, let the Domain Controllers handle DNS internally and when there is an external request that is not in the cache, let them go to the root servers. That is all there is to it.
So, let’s say you have 2 Domain Controllers, DC01 and DC02. On the NIC of DC01 you should have a static IP address and the primary DNS server should be DC01’s own IP address. You point it to itself. The secondary DNS server setting should have the IP address of DC02. On DC02’s NIC, its primary DNS server setting should point to DC01 and the secondary address should point to itself. Now those servers are setup properly as far as the NICs.
Inside the DNS server you have your forward lookup zone. Make sure you also setup a Reverse Lookup Zone for your subnet(s).
Your Server should have Server Aging/Scavenging setup for all zones to Scavenge stale resource records. The default of 7 days is fine.
In the Server properties almost everything can stay as the default.
On the Forwarders tab, remove any forwarders. You do not need them except for a very narrow set of circumstances. I can tell you in my decades of networking, I have only seen 2 times that these were ever needed. Also remove any Conditional forwarders. For most networks, you will never have to deal with these. You also never have to worry about proper settings if you switch ISP’s, move offices, etc., because your DNS server will always go to the root servers and does not care what your ISP is or what their DNS server addresses are.
Root Servers (Root Hints): The authoritative name servers that serve the DNS root zone, commonly known as the “root servers”, are a network of hundreds of servers in many countries around the world. They are configured in the DNS root zone as 13 named authorities. There is no better place for your DNS server to resolve external requests.
If you use your Domain Controllers for your DHCP servers also, setup the DNS in your scopes to point to DC01 and DC02 in that order. I have seen DC’s used for this in smaller networks where they are the only servers. Where you do have additional servers, Best Practices is to put the DHCP servers on something other than a DC.
Note: If your DHCP servers are on a server that is not a Domain Controller, you need to add those servers to the Active Directory Security Group, DNSUpdateProxy so that they can register clients with your DNS servers.
Generally, I setup 2 DHCP servers for fault tolerance and set them up almost identically. So for example if my internal IP Addressing scheme was 192.168.1.x, I would setup the scopes to go from .1 to 254. On both I would exclude, for example the ranges from .1 to .69. This is where I put all my static IP addresses. Then I exclude, for example 70 – 99. This is for future use should I need to free up 30 more addresses later for DHCP addresses. Finally, on DHCP Server #1 I would hand out addresses 100-177 and Exclude 178-254. On DHCP Server #2 I would Exclude addresses 100-177 and give out addresses 178-254. This way they do not step on each other and should either die, I still have a functioning DHCP Server.
Finally, on the DHCP IPv4 properties, under the DNS tab, Ensure that “Enable DNS dynamic updates………” is checked, as is “Always dynamically update DNS records”. You also want to check, “Dynamically update DNS records for DHCP clients that do not request updates…….”
Setting things up this way is the KISS method and you have full redundancy if you lose a DC, DNS Server or DHCP Server.
Resolving Names
When that name resolution request from the client hits DC01, from the settings it got statically or via DHCP, DC01 attempts to resolve it. If it is internal, it should have that information as we told the DHCP servers to ensure everyone is registered with DNS. If that request is for an external site, DC01 checks its cache and if it does not find the information, goes directly out to the Internet Root Servers for the information. Once resolved, DC01 Caches the information for the next time.
If you use forwarders here, you put another step in the process and introduce another single point of failure. If your ISP goes down, or their DNS servers are hit by DOS attacks or just that internet pipe to their servers goes down because some construction crew severed their fiber, you may have no resolution because the servers don’t answer or you time out. Also, if the ISP has old Cache data, you may not get the correct resolved address. ISP’s have been known to change their DNS server addresses in the past and not notified their customers.
Using Root Hints though, you always get the best, most accurate data. There is a lot less chance all the internet root servers would get hit with DOS attacks, and should one internet pipe go down, like with a poisoned route, severed fiber, etc., there is a very good chance that the rest will all be working. You also eliminate that single point of failure or the extra hops by using the ISP’s DNS serves as your middle man.
This is the way DNS was designed to work and it does that very well.
So, there you have it, the KISS method. You have redundancy and fault tolerance all rolled into one.
Which firewall do you have?
ASKER
Steve,
I appreciate all this information as it gives me a understading as how DNS works and it appears that this is how my network is setup other than the DHCP servers which are on both of my DC's except for the fact that both scopes are 192.168.5,1 - 192.168.7.254.
Masnrock
I have a Cisco ASA5506
Looks like I am already using the root hints and do not have any external static DNS servers listed anywhere so thanks for all your help.
Regards
I appreciate all this information as it gives me a understading as how DNS works and it appears that this is how my network is setup other than the DHCP servers which are on both of my DC's except for the fact that both scopes are 192.168.5,1 - 192.168.7.254.
Masnrock
I have a Cisco ASA5506
Looks like I am already using the root hints and do not have any external static DNS servers listed anywhere so thanks for all your help.
Regards
Steve provides a lot of good information, but I'll interject on a couple points.
There's no reason to dismiss the use of forwarders out of hand. I have to make this point because I dislike the sentiment that "forwarders are bad/outdated" that Steve espouses. If you want to use root hints purely from a perspective of simplicity, that's fine. But you can't make the point that they're always better. MS DNS servers were designed to use whatever you configure; forwarders, root hints, or both. The choice of using forwarders (and which ones) vs. root hints mostly comes down to performance (and there can be filtering benefits too, like with OpenDNS). Yes, root hints are almost always accessible, and their IPs rarely change, but depending on location/connectivity the use of forwarders can result in better performance. That can only be determined by testing (using a tool like https://www.grc.com/dns/benchmark.htm ). Depending on the relative performance of using a forwarder vs. root hints, you can then make a determination which to use.
As far as Microsoft's Best Practices:
1) They say nothing about forwarders vs. root hints, so I don't want you to leave with that impression.
2) Taking Steve's example (my changes are in bold, deletions noted with <>):
So, let’s say you have 2 Domain Controllers, DC01 and DC02. On the NIC of DC01 you should have a static IP address and the primary DNS server should be DC02’s IP address. <> The secondary DNS server setting should have the IP address of itself. On DC02’s NIC, its primary DNS server setting should point to DC01 and the secondary address should point to itself. Now those servers are setup properly as far as the NICs.
You will find arguments about whether it's better to have a DC/DNS point to itself as primary and other as alternate, or other as primary and itself as alternate (even within MS). What's shown above is Microsoft's stated best practice.
You will also find discussion about whether it's better to use a server's own IP or a loopback address (like 127.0.0.1). Typically I like to include the loopback IP as an alternate/tertiary server (and MS recommends using it - https://technet.microsoft.com/en-us/library/ff807362(v=ws.10).aspx ).
There's no reason to dismiss the use of forwarders out of hand. I have to make this point because I dislike the sentiment that "forwarders are bad/outdated" that Steve espouses. If you want to use root hints purely from a perspective of simplicity, that's fine. But you can't make the point that they're always better. MS DNS servers were designed to use whatever you configure; forwarders, root hints, or both. The choice of using forwarders (and which ones) vs. root hints mostly comes down to performance (and there can be filtering benefits too, like with OpenDNS). Yes, root hints are almost always accessible, and their IPs rarely change, but depending on location/connectivity the use of forwarders can result in better performance. That can only be determined by testing (using a tool like https://www.grc.com/dns/benchmark.htm ). Depending on the relative performance of using a forwarder vs. root hints, you can then make a determination which to use.
As far as Microsoft's Best Practices:
1) They say nothing about forwarders vs. root hints, so I don't want you to leave with that impression.
2) Taking Steve's example (my changes are in bold, deletions noted with <>):
So, let’s say you have 2 Domain Controllers, DC01 and DC02. On the NIC of DC01 you should have a static IP address and the primary DNS server should be DC02’s IP address. <> The secondary DNS server setting should have the IP address of itself. On DC02’s NIC, its primary DNS server setting should point to DC01 and the secondary address should point to itself. Now those servers are setup properly as far as the NICs.
You will find arguments about whether it's better to have a DC/DNS point to itself as primary and other as alternate, or other as primary and itself as alternate (even within MS). What's shown above is Microsoft's stated best practice.
You will also find discussion about whether it's better to use a server's own IP or a loopback address (like 127.0.0.1). Typically I like to include the loopback IP as an alternate/tertiary server (and MS recommends using it - https://technet.microsoft.com/en-us/library/ff807362(v=ws.10).aspx ).
So, yes this is Microsoft Best practices and was testable when I earned my MCSE.
You should, in a Domain make one DNS server your "Primary". DC01 should point to itself as the primary. In fact, when you make it a DC it automatically populates that entry with the loopback address of 127.0.0.1. Then the secondary is DC02. On DC02, you make DC01 also the primary with itself as the secondary.
Again, this was testable and it configures this way as the default.
Lastly, while Microsoft puts the loopback address in there and there typically are not problems, at the first sign of an issue, they will recommend putting the actual IP address of the server in there as there have been issues at times of the loopback not working, but the regular IP working.
Your TechNet reference is to address a specific problem and is not a Best Practices document.
The inclusion of its own IP address in the list of DNS servers improves performance and increases availability of DNS servers. However, if the DNS server is also a domain controller and it points only to itself, or points to itself first for name resolution, this can cause a delay during startup. For this reason, use caution when configuring the loopback address on an adapter if the server is also a domain controller. The loopback address should be configured only as a secondary or tertiary DNS server on a domain controller.
So this is just addressing the 127 loopback address. It never says not to use the actual IP address of the DNS server. In my experience, whichever entry is used, I have never seen a problem with a delay during startup. Your document is almost 8 years old and a lot of things happen in technology. So, while working with Microsoft engineers on DNS issues in the past, what I put above is their recommendations and what I had to know for my exams.
So, please read the TechNet bulletin closely and don't selectively pull out parts and then use that as the bible.
You should, in a Domain make one DNS server your "Primary". DC01 should point to itself as the primary. In fact, when you make it a DC it automatically populates that entry with the loopback address of 127.0.0.1. Then the secondary is DC02. On DC02, you make DC01 also the primary with itself as the secondary.
Again, this was testable and it configures this way as the default.
Lastly, while Microsoft puts the loopback address in there and there typically are not problems, at the first sign of an issue, they will recommend putting the actual IP address of the server in there as there have been issues at times of the loopback not working, but the regular IP working.
Your TechNet reference is to address a specific problem and is not a Best Practices document.
The inclusion of its own IP address in the list of DNS servers improves performance and increases availability of DNS servers. However, if the DNS server is also a domain controller and it points only to itself, or points to itself first for name resolution, this can cause a delay during startup. For this reason, use caution when configuring the loopback address on an adapter if the server is also a domain controller. The loopback address should be configured only as a secondary or tertiary DNS server on a domain controller.
So this is just addressing the 127 loopback address. It never says not to use the actual IP address of the DNS server. In my experience, whichever entry is used, I have never seen a problem with a delay during startup. Your document is almost 8 years old and a lot of things happen in technology. So, while working with Microsoft engineers on DNS issues in the past, what I put above is their recommendations and what I had to know for my exams.
So, please read the TechNet bulletin closely and don't selectively pull out parts and then use that as the bible.
Feel free to provide documentation on any points.
"Again, this was testable and it configures this way as the default."
Not sure what you're referring to as being testable. The first DC set up in a domain does indeed have the primary DNS set as itself by default. And why is that? Because it's the only DNS in the domain so far. That doesn't mean it can't/shouldn't be changed after you add other DNS servers. Subsequent DCs point at other DNS for primary by default because that same limitation of being the only DNS doesn't apply to them.
See what I mean about finding arguments about whether it's better to have a DC/DNS point to itself as primary and other as alternate, or other as primary and itself as alternate?
I didn't really mean to make an argument for which way was better, just what I've seen MS documents state, and I haven't seen anything by them which reverses that recommendation (please, if you have something, I'd truly be interested). Keep in mind that they are just recommendations/guidelines
But yes, the link I posted is a best practice. It says so right at the top. And it is linked to from the Best Practices Analyzer in Windows Server (even 2016). I can't help when MS updates their documents. You often find that they link to old content which applies to current versions. It'd be great if they updated all their content immediately when a new OS was released, but that is wishful thinking.
You misconstrued my point about the loopback - I never said not to use a DNS server's own IP. When I said I like to include the loopback, I didn't mean replace the IP with it.
Example config:
Primary - other DNS IP
Alternate - own IP
Alternate/Tertiary - loopback IP
"So, please read the TechNet bulletin closely and don't selectively pull out parts and then use that as the bible."
That's really a silly accusation to make. You made your own inferences, don't apply them to me.
"Again, this was testable and it configures this way as the default."
Not sure what you're referring to as being testable. The first DC set up in a domain does indeed have the primary DNS set as itself by default. And why is that? Because it's the only DNS in the domain so far. That doesn't mean it can't/shouldn't be changed after you add other DNS servers. Subsequent DCs point at other DNS for primary by default because that same limitation of being the only DNS doesn't apply to them.
See what I mean about finding arguments about whether it's better to have a DC/DNS point to itself as primary and other as alternate, or other as primary and itself as alternate?
I didn't really mean to make an argument for which way was better, just what I've seen MS documents state, and I haven't seen anything by them which reverses that recommendation (please, if you have something, I'd truly be interested). Keep in mind that they are just recommendations/guidelines
But yes, the link I posted is a best practice. It says so right at the top. And it is linked to from the Best Practices Analyzer in Windows Server (even 2016). I can't help when MS updates their documents. You often find that they link to old content which applies to current versions. It'd be great if they updated all their content immediately when a new OS was released, but that is wishful thinking.
You misconstrued my point about the loopback - I never said not to use a DNS server's own IP. When I said I like to include the loopback, I didn't mean replace the IP with it.
Example config:
Primary - other DNS IP
Alternate - own IP
Alternate/Tertiary - loopback IP
"So, please read the TechNet bulletin closely and don't selectively pull out parts and then use that as the bible."
That's really a silly accusation to make. You made your own inferences, don't apply them to me.
ASKER
Sorry I thought I had already accepted an answer.
I appreciate all your comments, I do understand DNS a lot more now than I did before but I wasn't looking to change my configuration as everything is working fine. I just wanted to know what external DNS servers I was pointing to or using which seems to be root hints.
I thought I already clicked the best solution days ago.
Thanks again for all your help.
I appreciate all your comments, I do understand DNS a lot more now than I did before but I wasn't looking to change my configuration as everything is working fine. I just wanted to know what external DNS servers I was pointing to or using which seems to be root hints.
I thought I already clicked the best solution days ago.
Thanks again for all your help.
ASKER
Thank you, Again thought I accepted this answer last week.
Just because your ISP recommends you use their DNS servers you are not required to... Some people use other resolvers for different reasons...
Also, the ports have to be open at the firewall, just in case someone tweaked them...