FortiOS Feature Explorer - Conditional DNS forwarding and translation

This topic is one that we've visited in the past by linking to my friend Manny @ InfoSecMonkey. However, the link itself has been broken.

You may have many reasons to do conditional DNS forwarding, in the original post we advocated for using the FGT as a DNS server and have public traffic queries go public, and private traffic queries go private. The primary driver there was to identify truly compromised hosts instead of wrongfully labelling the DNS servers as infected/compromised due to them performing the recursive lookup.

There are other reasons to do this as well, controlling certain access to certain domains, improving private DNS server performance, visibility, etc..

In this post we will visit a few of the conditional forwarding use cases.

Use Case 1 - Forward traffic for a specific domain to a different DNS server

This use case is very much in line with the original post, and the most common reason to do this, is as stated, only sending private queries to internal DNS servers. Example:

• FortiGate system DNS is pointed to 1.1.1.1 and 9.9.9.9

• Internal resources live in the mydomain.local domain

• I need traffic destined to mydomain.local to go to the internal DNS servers

Traditionally we would just point internal systems to private DNS servers, and that would be that. Anything the private DNS is authoritative for is resolved, anything else is looked up using a recursive lookup.

The challenge with this approach, is if one - or many - device(s) starts performing lookup to known bad domains, or exhibits DNS behavior consistent with a compromised host, the FortiGate will see the DNS server as the compromised host. This can be controlled a number of different ways assuming you have some sort of firewall between the endpoint and DNS server, sure, and this is one way to do so.

CLI Configuration:

config system dns-database
  edit "mydomain.local"
    set domain "mydomain.local"
    set authoritative disable  # It's important to disable authoritative
    set forwarder "x.x.x.x" "y.y.y.y"
    #x.x.x.x/y.y.y.y are private DNS servers separated by a space
  next
end

In this configuration there are 3 config elements we need to be concerned with:

1. the domain name

2. authoritative - we set this to disable because the FortiGate doesn't own the zone, it can override certain hostnames as added, but otherwise will forward to the configured forwarders

3. forwarder - your DNS servers are configured here, maximum of 2 DNS servers

GUI configuration:

1. In the FortiGate admin web interface navigate to Network > DNS

2. In the DNS database section click "create new

   

   
   

3. In the "Create New" dialog configure the following settings:

   

   
   

   1. DNS zone and Domain name should match from a readability stand point. And you should set authoritative to off, and have both DNS forwarders

4. There is an additional section where you can choose to override certain host name lookups

   

   Example: time.mydomain.local resolves to 10.10.10.10, but for traffic traversing this FortiGate you want that to resolve to 192.168.10.10, you would create that override in this section. Here's the gui configuration for said example:

   

   
   

5. It's important to note that the zone/record TTL are set to 1 day in this case, these may not be ideal for your organization. Consider your requirements and set those accordingly.

6. The last step is to point your devices to the FortiGate as the DNS server

Caveat: You already have a DNS management solution (e.g. infoblox) that provides great visibility and control, instead of pointing all devices to the FortiGate for DNS, you could point the DNS management solution's "upstream" lookup to the FortiGate. Allowing you to control access to specific domains not authoritative by the DNS management solution.

Use Case 2 - individual DNS query translations

In short, this allows for the translation/override of resolved inline queries from devices that don't use the FortiGate as a DNS server, to a desired address.

Example:

1. www.mydomain.local is set to resolve to 10.10.10.10, however for a certain segment of the network we would like the response to be overridden to 13.13.13.13

2. In Security Profiles > DNS Filter select your DNS Filter profile you wish to add DNS translation to

3. Under "Static Domain Filter" toggle the the DNS Translation to "ON"

4. Click "Create New"

   

   
   

5. Configure the original destination - in the example above www would resolve to 10.10.10.10, however we want certain users to be redirected to 13.13.13.13, so we set the "Translated Destination" to 13.13.13.13. Netmask of 255.255.255.255 tells the profile to only translate that IP

   

   
   

6. Click OK, and then click OK in the DNS profile

7. To make use of this, the DNS Filter profile now needs to be added to a firewall policy that that would match your DNS traffic.

8. An example policy is configured below:
   

   
   

   

   Top Half of the Policy

   
   

   

   Second half

   
   

9. In the Policy Above we have it configured to allow DNS traffic from local lans to all - yes this is a poor example of a policy from a source/destination perspective - using the service of DNS. The second half shows what needs to be done to add the security profile to the policy.

   
   

In this post we covered some ways of performing conditional DNS forwarding or translation, and why you may want to do this. I want to thank you for reading, and I hope this has been helpful.

-Madman Out!