In some cases, forward only may be the only viable option. Where firewalls or other access controls prevent a DNS server contacting and communicating with any other server than those they are configured to forward to the choice is simple - it should be forward only (since requests to contact the root name servers directly would timeout).
Even if there is open access to root name servers (which also requires open access to contact any DNS server that delegation and referrals may lead to, using iterative name resolution), policy or mandate by a group or location may still dictate forward only.
Notwithstanding this recommendation, there is no 100% right or wrong answer. Each approach has benefits and disadvantages.
4.2.1 and 4.2.2 are technical option appraisals provided for further information, assuming a server can be configured and operate properly with either setting.
4.2.1 Forward first
This gives the most control to the server itself. It allows the server to resolve names from the internet (or from root name servers as defined in root hints) without having to rely on or know that the servers being forwarded to have that access. The servers that are being forwarded to would only be needed to provide answers to:
- Queries that are not for domains the forwarding DNS server is authoritative for.
- Specific domains that are not available on the internet.
- Queries for domains that are available both on the internet and internally, but where the specific query cannot be answered from internet-based DNS servers. The server itself can then query the internet, or alternatively the network encompassed by the root name server defined in 'root hints', often referred to as an "Internal Root".
Another advantage of a forward first configuration is that the server doing the forwarding, if it does go to the internet, will cache not only the answers that come back, but also any information obtained along the way (through iteration and referrals). This allows the server to build up its cache on its own, which could reduce the amount of traffic generated by this server, especially if the total number of entries queried for is small and repeatedly asked for.
Be aware that when forwarding is done, should the server being forwarded to have access to the internet, it will respond with answers to internet-bound queries. This is because forwarding is always done first. This may create some difficulties in troubleshooting, since those diagnosing must first determine where a response came from: via a forwarded request, or from an iterative query.
Forward first can also mask the symptoms of a problem - for example, if a timeout or SERVFAIL is returned from a forwarded to server, which is followed by an iterative query to the internet, that latter query may return either an NXDOMAIN or an undesirable answer that is from an internet-facing DNS server. This may lead to false conclusions on what an actual problem may be.
4.2.2 Forward only
Forward only is an excellent way to enforce a clear resolution path. It also allows for better control of responses. For example, if a name typically used on the internet is not one that should be resolved, it can be added to the deny list or blackholed by returning a bogus IP address. This has been very common, especially when public instant messaging (IM) services should not be used on a particular network (the IM server IP addresses are replaced by bogus ones on internal DNS servers).
By having a single resolution path, troubleshooting is made easier. When a query is made, only one path (to the forwarded to server(s) IP address(es)) needs to be checked.
Since forwarding uses recursive queries, it will only get back an answer to the specific question asked. This does not allow the DNS server doing the forwarding to build up more information in cache.
However, by forwarding to a common point, it could take advantage of the sum total of all the queries that many other clients and servers have made. Iterative queries often require multiple packets be sent to get an answer. By concentrating the iterative queries to a common, central point, the overall number of DNS packets that might be generated from a larger number of DNS servers is reduced.