DNS Proxy
Conceptually, FortiWAN’s DNS Proxy is a function to dynamically redirect outgoing DNS requests (UDP 53) to an appropriate DNS server according to FortiWAN’s WAN link loading. It is implemented by dynamically replacing the original destination IP address of outgoing DNS requests with another DNS server IP address. No matter what the DNS server that an internal host is configured with, for any outgoing DNS request passing through FortiWAN, DNS Proxy replaces the original destination IP address of the DNS requests with the DNS server IP address determined by a load balancing algorithm. Basically, FortiWAN’s DNS Proxy selects a WAN link with lighter traffic loading and replace original destination of the DNS query packet with another DNS server that is associated with the WAN link.
How the DNS Proxy works and its configurations
Once DNS Proxy is enabled, any DNS request (UDP 53) received on FortiWAN’s LAN and DMZports will be evaluated. DNS Proxy contains two phases; selecting a WAN link with lighter traffic loading (depends on the specified algorithm) and replacing the destination of DNS queries. Configuration of DNS Proxy contains three basic elements:
- An algorithm used to select a WAN link l Participating WAN links
- The DNS servers used to replace the original destination of packets
DNS Proxy determines the DNS server for replacement by selecting one of the participating WAN links.
DNS Proxy Setting Fields
| Enable DNS Proxy | Enable/disable DNS Proxy. |
| Algorithm | Select an algorithm (See Load Balancing Algorithms) for selecting one of the participating WAN links: |
| l | By Weight: select a WAN link from the participants in weighted round-robin. |
| l | By Down Stream: always select the WAN link that has the lightest downstream traffic. |
| l | By Up Stream: always select the WAN link that has the lightest upstream traffic. |
| l | By Total Traffic: always select the WAN link that has the lightest total traffic.
The algorithm specified here determines a WAN link only for getting the associated DNS server to replace destination of the DNS packets. The selected WAN link is not for routing the packets. Auto Routing determines the WAN link to transfer the packets outward according to the policies. |
| WAN | Select the participating WAN links by specifying the DNS servers and weight. From the drop-down menu, select a WAN link and configure the following fields Weight and Server 1 – 3. Then the WAN link becomes one of the participating WAN links for DNS Proxy selects according to the specified algorithm.
After DNS Proxy selects a WAN link for a DNS request according to the specified algorithm, the destination of the DSN packet will be replaced with the DNS server associated to the WAN link. You can associate maximum of three DNS server IP addresses to a WAN link. DNS Proxy detects availability of the specified DNS servers and chooses the first available server for every replacement. A replacement will not take place if no specified server is available. IP addresses of DNS servers specified here can be internal or external IP addresses. DNS packets processed by DNS Proxy will be transferred toward the internal or external IP address according routing rule set in Network Setting (see Configuring your WAN and LAN Private Subnet) and Auto Routing (see Auto Routing). No matter which algorithm is specified, if only one WAN link is configured here, DNS packets will be always processed with the DNS server associated with the WAN link. In other words, DNS Proxy redirects DNS requests to a fixed DNS server regardless of traffic loading on WAN links. |
|
| Weight | Give a weight to the WAN link. This field is visible when By Weight is selected in Algorithm. | |
| Server 1 | Specify IP address of the first DNS server to the WAN link. This IP address will be used to replace the destination of a DNS packet if the associated WAN link is selected.
Getting this field configured is necessary to have a WAN link participated in DNS Proxy. A WAN link without configuring this field will not participate in DNS Proxy. |
|
| Server 2 | Specify IP address of the second DNS server to the WAN link. This IP address will be used for the replacement if Server 1 is not available. This is optional. | |
| Server 3 | Specify IP address of the third DNS server on the WAN link. This IP address will be used for the replacement if Server 1 and Server 2 are not available. This is optional. | |
| Source | DNS request packets coming from the specified source will be matched. Enter a single IPv4 address, IPv4 range (in format xxx.xxx.xxx.xxx-xxx.xxx.xxx.xxx) or a IPv4 subnet (in format xxx.xxx.xxx.xxx/netmask).Keep it blank for matching any source. | |
| Domain Name | DNS requests for the specified domain name will be matched. A wildcard character is accepted for the left-most label of a domain name, e.g. *.fortinet.com or *fortinet.com.
Note that other formats such as www.*.com, www.fortinet.* or *.fortinet.* are not supported. Keep it blank for any domain name. |
|
What DNS Proxy performs to DNS packets is only replace the destination of DNS packets; it does not involve routing for the packets. DNS Proxy select a WAN link only for the destination replacement, not for routing the packets. Auto Routing determines the route for the outgoing DNS packets (actually, Auto Routing is the only function routing for all outbound traffic, see Auto Routing). For example, although DNS Proxy selects WAN 1 for replacing destination of a DNS packet with IP of the DNS server associated with WAN 1, FortiWAN routing function might transfer it through other WAN links (WAN 2 or WAN 3) or a LAN port.
Scenario
Here is an example using algorithm By Weight to select the DNS server for the destination replacement in the weight WAN1:WAN2 = 2:1.
| Algorithm | ||
| By Weight | ||
| DNS Server | ||
| WAN | 1 2 | |
| Weight | 2 1 | |
| Server 1 | 211.136.28.237 202.106.0.20 | |
| Server 2 | – – | |
| Server 3 | – – | |
According to the configuration, all the DNS requests received on FortiWAN’s LAN ports and DNS ports will be reworked as followings:
| Packet | Source | Request A record
for |
Original destination | Hit WAN
link |
Replaced destination |
| Packet 1 | 192.168.0.10 | www.abc.com | 8.8.8.8 | WAN1 | 211.136.28.237 |
| Packet 2 | 192.168.0.101 | www.def.com | 202.96.209.5 | WAN1 | 211.136.28.237 |
| Packet 3 | 192.168..0.66 | www.ijk.com | 202.96.209.133 | WAN2 | 202.106.0.20 |
| Packet 4 | 192.168.0.23 | www.opq.com | 211.136.150.66 | WAN1 | 211.136.28.237 |
| Packet 5 | 192.168.0.7 | www.rst.com | 223.5.5.5 | WAN1 | 211.136.28.237 |
| Packet 6 | 192.168.0.211 | www.xyz.com | 211.136.112.50 | WAN2 | 202.106.0.20 |
DNS Proxy for peering issue
Actually, DNS Proxy is mainly used to resolve potential traffic congestion on single WAN link due to the usage of Optimum Route for resolving ISP peering issue (certainly, it can also be used for just redirecting DNS requests to another DNS server, which is unrelated to peering issue). As mentioned in Optimum Route Detection, Optimum Route does resolve the inefficient transmission resulted by bad peering between ISPs. No matter which detection mode is used for Optimum Route, traffic to a particular destination will be almost fixed by Optimum Route on particular WAN links (which the WAN links connect to the same ISP subnet that the particular destination is located in) if this ISP has bad peering with other ISPs (other WAN links). In real practice, most of service providers or internet content providers will not deploy their servers in only one ISP network if peering issue exists between ISPs. To provide service to users located in different ISP networks, they will logically deploy servers in several ISP networks, and maintain DNS servers (or appropriate settings on ISP’s DNS) for a common domain in each of the ISP networks. Each of the DNS servers will answer the IP address of corresponding application server that is located in the same ISP network together with the DNS server to any DNS query for the server name. In other words, asking different DNS servers (located in different ISP networks) for the same server name will be responded with different IP addresses, which belong to different ISP networks. Users in an ISP network can access the server located in the same ISP network without passing across others ISPs if they ask an appropriate DNS.
Even if FortiWAN connects to multiple ISP networks, the problem is that users behind FortiWAN are usually configured with a fixed DNS server (that is probably located in one of the connected ISP networks), which means they always ask the same DNS server for a server name and are responded with the same IP address of the server. A user will not know other IP addresses of the same server name in other ISP networks unless they change DNS configuration to others.
For example a FortiWAN transfers outbound traffic by Auto Routing with Optimum Route (see Auto Routing and Optimum Route). In the above diagram, the DNS 1 (10.10.10.100) in ISP-1 network answers 10.10.10.10 to query for server name www.abc.com, while the DNS 2 (20.20.20.100) in ISP-2 network answers 20.20.20.20 to the query for the same server name. In other words, traffic to www.abc.com will be routed to WAN 1 by Optimum Route if a client asks DNS 1 for www.abc.com, or traffic will be routed to WAN 2 by Optimum Route if the client asks DNS 2 for www.abc.com. However, the clients in LAN are configured with a static DNS address no matter manually or by DHCP. If all the clients in LAN are configured with DNS Server = 10.10.10.100, all the traffic to www.abc.com will fixedly be destined to 10.10.10.10 through WAN 1. This is what we mentioned traffic congestion on single WAN link resulted by usage of Optimum Route for resolving ISP peering issue.
For this reason, FortiWAN’s DNS Proxy is a mechanism used to detect a WAN link with lighter traffic loading and redirect a DNS query to the DNS server located in the ISP network connected by the WAN link. For example, if DNS Proxy detects WAN 2 has lighter traffic loading than WAN 1, DNS queries for www.abc.com will be redirected to DNS 2 (20.20.20.100) and the response for www.abc.com will be 20.20.20.20. With appropriate configuration on Optimum Route, traffic to www.abc.com can be routed to WAN 2. No matter what the original DNS server (destination IP) of the query is, DNS Proxy replace it with another DNS according to current WAN link loading. Therefore, accessing to the same service can to distributed into multiple WAN links with Auto Routing by Optimum Route for this case.
To use DNS Proxy with Optimum Route to improve the bad transmission efficiency resulted by bad peering between ISPs, here is the basic premise for using DNS Proxy:
- FortiWAN connects to the bad-peering ISP networks through different WAN links.
- Optimum Route Detection is appropriately configured, and corresponding Auto Routing policy and filters are created for routing traffic by the algorithm: By Optimum Route. Without these configurations, the basic peering issue does not get resolved, and DNS Proxy becomes meaningless for this.
- Make sure that a service provider deploys different servers in the bad-peering ISP networks, and maintains DNS servers to answer corresponding IP address of the server that is located in the same ISP network with the DNS server. DNS Proxy will become helpless for this case if the service is only deployed in a ISP network.
- List these particular DNS servers located in each of the ISP networks. A DNS server must be associated with a WAN link connected to the ISP network that the DNS server is located in.
Scenario
Base on the above example, make sure Optimum Route Detection and Auto Routing are configured before going on DNS Proxy. We assume that the Optimum Route Policy (see Optimum Route Detection) is configured as Static IP Table as followings:
| ISP-1 Network | ISP-2 Network | |
| Table Name | ISP1 | ISP2 |
| Setting | Upload the IP file of ISP 1. The IP subnet 10.10.10.0/24 is maintained in the file. | Upload the IP file of ISP 2. The IP subnet 20.20.20.0/24 is maintained in the file. |
| Parameter | Check WAN1 | Check WAN2 |
You can also set the Optimum Route Policy as Dynamic Detect, Static & Dynamic or Dynamic & Static, see Optimum Route Detection for the details.
The Auto Routing policy and filter rule are correspondingly configured as followings (see Auto Routing for details):
| Label | Algorithm | Parameter | |||||||
| OR_W1_W2 | By Optimum Route | Check WAN1 and WAN2 | |||||||
| When | Input Port | Source | Destination | Service | Routing Policy | ||||
| All-Time | Any Port | Any Address | WAN | Any | OR_W1_W2 | ||||
The above settings provides the basic solution of bad peering between ISP 1 and ISP 2. In this example, servers of www.abc.com are deployed in both ISP 1 and ISP 2 networks, and the DNS server in each ISP network answers corresponding IP to requests for www.abc.com. To introduce DNS Proxy to the case to dynamically distribute sessions to www.abc.com through the two WAN links, it requires the following settings of DNS Proxy configured:
We use algorithm By Total Traffic to select the DNS server associated with the lightest-loaded WAN link for the destination replacement (you can try other algorithms).
| Algorithm | ||
| By Total Traffic | ||
| DNS Server | ||
| WAN | 1 2 | |
| Server 1 | 10.10.10.100 20.20.20.100 | |
| Server 2 | – – | |
| Server 3 | – – | |
| Proxy Domains | ||
| www.abc.com | ||
The configurations guarantees that destinations of DNS packets querying for www.abc.com will be replaced with
DNS servers 10.10.10.100 or 20.20.20.100 in circular order according to weight 2:1. DNS packets processed by DNS Proxy will be transferred outward according the Auto Routing policies. In this case (bad peering exists between the two ISPs), it is better to let DNS packets destined to 10.10.10.100 be routed to WAN 1 and DNS packets destined to 20.20.20.100 be routed to WAN 2. Packets might be stuck by the bad peering if packets destined to 10.10.10.100 be routed to WAN 2. Here, with Optimum Route being used in the Auto Routing policy, DNS packets processed by DNS Proxy will be routed to appropriate WAN link to avoid the bad peering. Possible query loop
Since DNS Proxy forwards queries, you should be careful with the deployments to avoided possible query loop. Here are the two cases that DNS Proxy might cause query loops.
Case 1
If DNS Proxy is configured to forward DNS queries to a DNS server located in FortiWAN’s LAN or DMZ subnets, and this DNS server resolves queries by interacting with other DNS servers in the Internet through FortiWAN, a
SNMP
query loop will happen. DNS Proxy forwards the queries that the DNS server in LAN or DMZ sends to the DNS servers outside FortiWAN back to the DNS server in LAN or DMZ.
Case 2
FortiWAN’s Internal DNS (see Internal DNS) provides service on IP address 223.255.255.2 that FortiWAN uses it for internal operations. However, if the DNS server in Network Setting (System > Network Setting > DNS Server, see Set DNS server to FortiWAN) is configured, Internal DNS will forward queries to the configured DNS servers rather that resolving them itself. Now, if you configure System > Network Setting > DNS Server with DNS servers located in FortiWAN’s LAN or DMZ subnets, enable the Internal DNS, and configure Proxy DNS to forward queries to 223.255.255.2, a query loop will happen.
| Community | Enter the community which the SNMP belongs to. |
| System Name | Enter a string to represent this system. |
All the DNS queries are forwarded by DNS Proxy to 223.255.255.2 which is the Internal DNS, then these queries are forwarded again by Internal DNS to the DNS servers in LAN or DMZ which are configured in System > Network Setting > DNS Server. The DNS servers might resolve queries by interacting with other DNS servers in the Internet through FortiWAN. DNS Proxy forwards the queries that the DNS server in LAN or DMZ sends to the DNS servers outside FortiWAN back to Internal DNS on 223.255.255.2, and the queries are eventually forwarded back to the DNS servers in LAN or DMZ.
Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!