DNS

Best Practices for DNS Forwarding

Q: What is a DNS Forwarder?

In Domain Name System (DNS) terms, a DNS forwarder is a DNS server that is used to forward DNS queries for external DNS names to DNS servers outside that network. It does it to DNS queries that it cannot resolve locally, meaning DNS queries that it has no personal knowledge of. By using DNS forwarders you can improve the efficiency of name resolution for the computers in your network that query for DNS names outside your network (such as names on the Internet).

Windows-based DNS servers come pre-installed with an automatic method of querying Internet names using a method called “DNS Root Hints.” Once you install the DNS role on a Windows-based server the Root Hints will be automatically added, and practically speaking, will allow you to resolve any Internet name as long as you have Internet connectivity for that server and there is no firewall rule that blocks it from querying those servers. You do not have to perform any additional configuration. You can find an updated list of root hints at ftp://ftp.rs.internic.net/domain/db.cache.

sample listing of root hints

Sponsored Content

Maximize Value from Microsoft Defender

In this ebook, you’ll learn why Red Canary’s platform and expertise bring you the highest possible value from your Microsoft Defender for Endpoint investment, deployment, or migration.

A sample listing of root hints from ftp://ftp.rs.internic.net/domain/db.cache. (Image: Jeff James)

When forwarders are configured on a DNS server, when it receives a DNS query for a name for which it is not authoritative, meaning a query outside the scope of its control, one it has no knowledge of, the server will forward the request to whatever forwarder(s) were configured on it, instead of using root hints. Forwarders will always take precedence over Root Hints.

Note: You can also configure your server to forward queries to different servers depending on the DNS suffix that is specified in the DNS query. To do so, configure conditional forwarding appropriately. I will cover this in a later article.

Best Practices for DNS Forwarding with Windows Server 2012 R2

If you only have one DNS server, you may want to configure it as a forwarder. DNS plays a critical role in today’s Internet-connected IT world. Imagine all the services that we consume from the Web and from cloud-based providers. You want to have more than one DNS server for obvious redundancy purposes. When you have two or more DNS servers, you can configure one of them, some of them, or all of them to use forwarders.

From a network and performance efficiency perspective, having a single forwarder is generally more efficient than using multiple forwarders. This is because of the way DNS queries work. Whenever a DNS server receives a query and resolves it using forwarders (as with Root Hints), it caches the results it sent back to the client. Since query results are concentrated in one forwarder’s cache, any subsequent queries to the same names will be resolved locally from that DNS’s cache. This decreases the Internet traffic over the network and improves the response time for DNS clients.

However, having said that, you may want to have at least 2 working DNS servers acting as forwarders because if one fails you will still have name resolution.

The Difference Between Using DNS Forwarders and Root Hints

Which is the best decision, to use Root Hints, or use my local ISP’s DNS servers as forwarders? For me, this is a frequently asked question.

I recommend using your ISP DNS servers as forwarders. The main reason is related to performance. By using your ISP’s DNS servers as forwarders you will have a much lower number of hops to reach your ISP DNS server when compared to the number of hops needed to access the root hints.

ISP DNS servers are quite reliable and do not change that often, a vast improvement over the last ten years. You also get the benefit of having the ISP cache most of the frequently-used DNS queries for your country or geographical region in their DNS servers’ cache, further improving DNS query performance.

In all these cases you will need the correct names and IP addresses of your ISP. The best ways to get the correct names and IP addresses of your ISP would be either to search for the list on your favorite search engine or simply contact your ISP’s technical support line.

Another reason for my recommendation is related with firewall configuration. It’s relatively easy to allow DNS queries to the 2 or 3 specific ISP DNS servers used for forwarders rather than allowing the DNS to query a large list of external root hints servers and the associated recursive traffic that will result from these queries.

There is one critical thing you need to remember. If you change your ISP in the future you must also change the DNS forwarder information because it’s most likely that the new ISP will block the old ISP’s DNS queries based on your external IP address. In addition, when you are using an Internet connection that is load-balancing connections from several ISPs, you may need to check with all your ISPs to see how to properly configure DNS forwarders or you might experience name resolution failure whenever your connection switches to the other ISP. You do not need to worry about this if you use Root Hints.

One last thing to remember when you are about to perform changes in your Domain Controller topology such as adding, removing or changing IP addresses of DCs. In most cases the DCs (or at least some of them) will also act as DNS servers. When you make a change to these DCs, you must remember to also change the forwarders, firewall rules and any other manual configuration settings you made.

Related Topics:

DNS
BECOME A PETRI MEMBER:

Don't have a login but want to join the conversation? Sign up for a Petri Account

Register
Comments (11)

11 responses to “Best Practices for DNS Forwarding”

  1. Thank you for starting this discussion thread. I have had philosophical “discussions” about this topic quite often in the past several years.

    I respect your opinion and perspective but offer the following counterpoints. Feel free to correct, or shred, them as appropriate.

    For small- and medium-sized organizations, rich, high-performance bandwidth is not that common with regard to Internet connectivity. Furthermore, it is not uncommon to count up three or more hops through chokepoints between a client’s network and an ISP’s DNS server. These chokepoints can include routers, firewalls, web-filtering appliances, cable modems, and/or metro Ethernet switches. All of these chokepoints can introduce latency into the name resolution process, even if that process only involves contacting the ISP’s DNS server(s).

    For years, I have relied on Microsoft’s DNS servers, plus root hunts, for all DNS name resolution, and have never experienced user-impacting name resolution issues. Indeed, a rarely accessed site might take a few minutes longer for an on-site DNS server to resolve using root hints, but unless one’s organization is attempting to crawl the entire web, mist usage patters involve accessing a site and then interacting with it for a period of time. After the initial name resolution results are cached, there is no additional impact of local versus ISP name resolution.

    What I have found over the years is that many ISPs will introduce DNS issues when forwarders are relied upon due to maintenance, mistakes, network peering connectivity problems, etc. Granted, the more one pays, in general the better ones ISP service will be, but for small- to medium-sized orgs, the ISPs within their budget range rarely offer 99.999% reliability.

    Of course, this is all anecdotal. I would live it if some PhD candidate did a thorough analysis over an extended period of time and with multiple ISPs to give us a meaningful statistic for both approaches. Both obviously work, although with services such as OpenDNS, the ONLY approach possible is configuring forwarders.

    • Dear Daniel,

      As Chris shortly points out, you could also consider configuring the DNS forwarders to use tools like OpenDNS. You can use a home or corporate edition for filtering web results of adult, offensive content and malware hosting sites. There are currently 60 categories to filter the web pages that you do not wish to confront your employees with and thus providing a safer workspace.

      Kind regards,
      Johan van Soest
      Web :http://www.vansoest.it
      LinkedIn :http://nl.linkedin.com/in/johanvansoest

    • Hi Chris –

      This is actually a reply from Daniel Petri, who emailed me a response to post here:

      “Great feedback Chris. I guess YMMV, as different ISPs behave differently across the world. Overall, the concept of using a forwarder is much more straightforward from a connectivity and FW perspective than using Root Hints, but this doesn’t mean that they cannot be used. It’s just more hops, more packets going back and forth as their replies cause your DNS to perform additional recursive queries, and must harder to secure across FWs. ” – Daniel Petri

  2. Thank you for starting this discussion thread. I have had philosophical “discussions” about this topic quite often in the past several years.

    I respect your opinion and perspective but offer the following counterpoints. Feel free to correct, or shred, them as appropriate.

    For small- and medium-sized organizations, rich, high-performance bandwidth is not that common with regard to Internet connectivity. Furthermore, it is not uncommon to count up three or more hops through chokepoints between a client’s network and an ISP’s DNS server. These chokepoints can include routers, firewalls, web-filtering appliances, cable modems, and/or metro Ethernet switches. All of these chokepoints can introduce latency into the name resolution process, even if that process only involves contacting the ISP’s DNS server(s).

    For years, I have relied on Microsoft’s DNS servers, plus root hints, for all DNS name resolution, and have never experienced user-impacting name resolution issues. Indeed, a rarely accessed site might take a few milliseconds longer for an on-site DNS server to resolve using root hints, but unless one’s organization is attempting to crawl the entire web, most usage patters involve accessing a site and then interacting with it for a period of time. After the initial name resolution results are cached, there is no additional impact of local versus ISP name resolution.

    What I have found over the years is that many ISPs will introduce DNS issues when forwarders are relied upon due to maintenance, mistakes, network peering connectivity problems, etc. Granted, the more one pays, in general the better one’s ISP service will be, but for small- to medium-sized orgs, the ISPs within their budget range rarely offer 99.999% reliability.

    Of course, this is all anecdotal. I would love it if some PhD candidate did a thorough analysis over an extended period of time and with multiple ISPs to give us a meaningful statistic for both approaches. Both obviously work, although with services such as OpenDNS, the ONLY approach possible is configuring forwarders.

    • Dear Daniel,

      As Chris shortly points out, you could also consider configuring the DNS forwarders to use tools like OpenDNS. You can use a home or corporate edition for filtering web results of adult, offensive content and malware hosting sites. There are currently 60 categories to filter the web pages that you do not wish to confront your employees with and thus providing a safer workspace.

      Kind regards,
      Johan van Soest
      Web :http://www.vansoest.it
      LinkedIn :http://nl.linkedin.com/in/johanvansoest

    • Hi Chris –

      This is actually a reply from Daniel Petri, who emailed me a response to post here:

      “Great feedback Chris. I guess YMMV, as different ISPs behave differently across the world. Overall, the concept of using a forwarder is much more straightforward from a connectivity and FW perspective than using Root Hints, but this doesn’t mean that they cannot be used. It’s just more hops, more packets going back and forth as their replies cause your DNS to perform additional recursive queries, and must harder to secure across FWs. ” – Daniel Petri

Leave a Reply

External Sharing and Guest User Access in Microsoft 365 and Teams

This eBook will dive into policy considerations you need to make when creating and managing guest user access to your Teams network, as well as the different layers of guest access and the common challenges that accompany a more complicated Microsoft 365 infrastructure.

You will learn:

  • Who should be allowed to be invited as a guest?
  • What type of guests should be able to access files in SharePoint and OneDrive?
  • How should guests be offboarded?
  • How should you determine who has access to sensitive information in your environment?

Sponsored by:

 
Live Webinar: Active Directory Security: What Needs Immediate Priority!Live on Tuesday, October 12th at 1 PM ET

Attacks on Active Directory are at an all-time high. Companies that are not taking heed are being punished, both monetarily and with loss of production.

In this webinar, you will learn:

  • How to prioritize vulnerability management
  • What attackers are leveraging to breach organizations
  • Where Active Directory security needs immediate attention
  • Overall strategy to secure your environment and keep it secured

Sponsored by: