How to Deploy and configure DNS 2016 – (Part3)
In the last part Part 2 I detailed what DNS Zones are and how to create them. In Part 3 we will take a look at Conditional Forwarders (Difference between Stub Zone and Conditional Forwarder), Server Properties, Root Hints etc.
Let’s get started.
Conditional Forwarders (Difference between Stub Zone and Conditional Forwarder)
Many people get confused when they need to decide if they are going to create Stub Zone or Conditional Forwarder. So what is the difference?
Stub Zone –> Like I said, Stub Zone owns SOA and NS records for the other domain and it will has zone transfer, when we want to resolve the other domain.
With Stub Zones, the other domains records will expose to this domain, so, some Admins think it’s not secure. As authoritative dns server are added and removed, the list is auto updated. Stub zones can be AD-Integrated so they can be replicated to all DNS servers. You should consider using stub zones in multisite scenarios where replication of large zone may be an issue.
Conditional Forwarder –> Conditional forwarder do not hold records for the other zone, it only re-direct the resolution for the other domain to DNS server in that domain. If you want specific request for specific domain to go to a certain server you use conditional forwarding e.g all requests to mehic.se goes to 192.168.0.20. For instance, if you know that CompanyAB.com domain has a DNS server at 192.168.0.20, then you can specify this, and reduce the time need to resolve the domain (as the query does not have to go out the Root domain and get referrals to downward domains). With conditional forwarding, if the IPs change for the NS servers in the domain that you are forwarding to, you wouldn’t know unless you were monitoring that or got a call from their DNS admin.
Let’s see how we can create conditional forwarder. I have installed third DNS server DC03, which is not part of mehic.se domain.
Let’s see first if we can resolve mehic.se from DC03
Right-Click on Conditional Forwarder and select New Conditional Forwarder
New Conditional Forwarder window will pop-up. Type in the DNS Domain name and IP of the master DNS server for the domain. And we also get a little error message here because we have no way in this domain to determine the authoritativeness of that other domain. This error can be ignored. Once we do that, we can hit the OK button.
We have conditional forwarder that we can use for resolving requests in the other domain.
So let’s actually verify that this forwarder is really functioning.
We’re receiving that non-authoritative answer because the answer is coming from our local server. The authoritative server is not actually getting us the answer directly, but this proves that in fact we can use this conditional forwarder as a mechanism to redirect these DNS requests to the server most capable of handling them.
DNS Forwarders (vs Conditional Forwarders)
Like I said Conditional forwarding allows us to place conditions on which DNS requests get
sent to which DNS server.
DNS Forwarders –> allows us to forward DNS Requests from one DNS server to another
to be resolved.
The most common example of this is when a company forwards its internal DNS server to its ISP’s DNS server. This is more efficient than resolving the DNS requests themselves as the ISP may have already resolved that dns request and have the result stored in the ISP’s dns server cache.
Next example would be when you have dns server and you do not want to have that server directly connected to the internet. The internal dns will contain the dns records for the local network like records for the company’s servers and clients and services like AD.
The DNS will still be able to resolve DNS Names on the internet even though it does not have direct access by forwarding dns requests to a dns server in the perimeter or DMZ network. DNS in DMZ will forward the dns request to the ISP’s DNS.
This means the internal DNS server does not access the internet directly and thus helps protect it. If the DMZ DNS server was to be attacked, the DNS records on the internal DNS would be protected.
To configure DNS Forwarder right-click on your DNS server and select Properties.
Click on Forwarders Tab, Here I have my ISP DNS servers
If you would like to add new forwarder you would need to click on Edit and type in the IP address of the DNS you would like to forward dns requests and press OK.
“Use root hints if no forwarders are available” option
This option will be grayed out if no forwarders have been configured. If the forwarders cannot be contacted the DNS server will attempt to contact a root hint server. If your DNS server is behind a firewall and should not be connecting to the internet directly, then this option should be cleared.
Root Hints
The DNS root hints servers are at the top of the resolving process for DNS names and those servers are the first servers contacted in order to start resolving a DNS request. On most networks you will never need to configure the root hint servers. In order for a DNS server to resolve a DNS name without the help of other DNS servers, e.g. forwarding the request to another DNS server, a root hint server needs to be contacted.
If we right-click on our dns server in (DNS Manager) and select Properties –> Forwarders Tab. Use root hints if no forwarders are available” option will be grayed out if no forwarders are configured. To allow that option you will need to click on edit and configure Forwarders. Example you can use Google’s DNS server.
When you configure Forwarders you will be able to un-tick this option. If forwarders are not available the DNS server will use root hints, but when would you want to use or disable this option?
Let’s say you have 2 DNS servers. DC01 is your internal DNS and DC02 is DNS in the DMZ Network. DC01 forwards DNS queries to DC02 (DNS in DMZ). DC02 (DNS in DMZ) then forwards queries to the ISP DNS server.
Let’s consider what would happen if the DNS server in DMZ were to become unvailable?
If this were to occur, the internal DNS server would attempt to use the Root Hint server to start the DNS resolving process. So essentially what you now have happening is an internal DNS server that is not suppose to be directly communicating with the internet is now attempting to contact a root hint server on the internet.
If it is able to do this (When you have “Use root hints if no forwarders are available” option checked) it will then start contacting other DNS servers on the internet attempting to resolve the DNS query. A lot of admins would consider this poor security and would switch this off. This of course would mean that while the perimeter DNS server is unvailable no internal clients would be able to resolve dns requests so we would need to ensure that outages, if they occurred, were short.
If we click on Advance tab we will notice the option at the top Disable Recursion (also disables forwarders)
This tick box when ticked will prevent the DNS server from contacting any other dns server if it does not know the answer to the dns query. It will not attempt to contact any root hints servers or forwarders even if these options are configured. You would use this option on a secure network that is isolated from other networks. The only other time is when you have multiple dns servers and you only want particular server to only resolve dns requests and other dns server to ignore the request.
To check Root Hints servers we need to click on Root Hints Tab
This shows the 13 root hints server that are configured. Due to a limitation of the UDP Protocol when DNS was first developed, the max number of root hints server is limited to 13. Root hint server is not one physical server, it is installed on HA Cluster and they are using anycast making them available from multiple locations. Data for the root hints servers is stored in Windows Directory. \dnsservername\c$\Windows\System32\dns, there is a file called CACHE. If you open it, it will show you all the root hint servers.
Let’s go back to Advanced Tab to discuss about 2 more options which are not enabled by default Enable Bind Secondaries and Fail on load if bad zone data and other options we can find there.
Enable Bind Secondaries
If the DNS server is replicating with Berkeley Internet Name Domain (BIND) DNS servers this option will increase the compatibility with those servers. What it does is it disables some of the compression options used in replicating (It disables some fast transfer options for zone transfers and thus enabling this will slow down zone transfers). The reality is, these options have been supported in BIND since version 4.94 which was released in the late 90’s. Unless you are replicating with a very old Linux or Unix DNS server there should not be the need to ever enable this option. Since it changes the replication compression options, it effectively increases the amount of replication data required and thus should only be switched on if you are experiencing problems.
Fail on load if bad zone data
If this option is ticked, if there are an errors detected in the zone file it will not be loaded. (Example: If a dns record contained any illegal characters) In most cases you would not enable this option as this would prevent the DNS server from answering queries for this DNS zone if any errors were in the file for any reason. If you are more worried that data is accurate rather than the DNS server answering requests, tick this option.
Enable Round Robin
This option is enabled by default but only comes into effect when there are multiple records that exist with the same name. When this occurs the records will returned in sequence which provides very basic load balancing. To understand how it works consider DNS server which has 2 DNS records on it. The first one is an A record TSFARM – 192.168.0.10 and the second one is once again A record for TSFARM- 192.168.0.11. DNS allows you to have more than one dns record with the same name however this time it has a different IP address. Let’s say that we have 3 computers that asks to resolve this record TSFARM one after the other. First computer will obtain the first dns record (TSFARM – 192.168.0.10), when the dns server receives the request resolve TSFARM from the second computer it will give the second dns record (TSFARM 192.168.0.11) to the second computer. Now when the third computer asks to resolve TSFARM, dns server has no more records for that and it will go back to the first dns record (TSFARM – 192.168.0.10) and it will continue in that order.
Enable Netmask Ordering
When this option is enabled the DNS server will attempt to return dns records that are in the same network as the client. To understand how this works consider that you have 2 networks and in each of these networks is a web server that you want to respond to requests for www. If we have 2 clients in the first network, the first client will contact the dns server asking for the ip of www. It will obtain address of the server on the first network. (We learned that when DNS Round Robin is enabled and there are multiple DNS records with the same name they will be returned in sequence) When you have NETMASK ORDERING enabled the second computer will obtain the same dns record even when Round Robin is also enabled.
Round Robin and Netmask Ordering do work together. Let’s see how?
I will add second web server to the second network and 2 computers. Like before when the first client asks for the IP of www dns will give a record that is in the same network as the client. When second client asks for www (round robin will kick in) because there are 2 records in the same network and this time client will be directed to the second web server.
Secure Cache against pollution
This option helps prevent false records from being added to the cash. To understand this consider that you have an attacker on the network who has a fake website and who wants people directed to. A form of attack is for the attacker to ask the dns server the address of the website. DNS server does not know the address so what it will do is ask another dns server. What the attacker will do now is send multiple responses back to the dns server trying to make these responses look like legitimate responses to make answering the original query. When the responses from query come back the attacker is hopping his response will be accepted and not the response from the other dns. What was happened is the fake dns record is now in the cache of the dns server. When the client requests the dns record he will obtain the fake dns record and be directed to the attackers website.
What we covered.
- What is Conditional Forwarder (Difference between Stub Zone and Conditional Forwarder)
- What is DNS Forwarder (Difference between Forwarder and Conditional Forwarder)
- What are Root Hints and when to use/disable them
- What are Server Options ( Disable Recursion (also disables forwarders), Enable Bind Secondaries, Fail on load if bad zone data, Enable Round Robin, Enable Netmask Ordering, Secure Cache against pollution
No comments:
Post a Comment