DNS-over-TLS from Edge fronting VDOMs

DNS-over-TLS from Edge fronting VDOMs

A post about a possible way to configure your edge fronting DNS requests over DoT/DoH services and this from your FortiGates units configured in multi-vdom operation mode. In order to make it easier to describe, find below a quick drawing of the idea behind this post:

As seen above, I'm hosting (pretty much as always..) a global DNS server within my root VDOM. This DNS server is the only DNS in use for any "outbound" resolutions.

I'm not showing it on this drawing, although lately, I've shifted my main DNS server settings (the one distributed over DHCP etc) towards my FortiProxy appliance. This mainly because my FPX box is reachable all over my different networks and locations. Also, it helps in order to centrally manage my local DNS databases and this from a single entity and finally, in my schemes, only a very few entities are able to do outbound recursive DNS queries, FPX is one of them.

Nevertheless, this is not really relevant here as the forwarder or recursive DNS server on the FPX box is nothing else than the root VDOM DNS server at my central location, as shown above.

Within FortiOS there are a few DNS related configurations settings we have to detail a bit before going further:

  1. VDOMs sepcific DNS Server settings (VDOM specific where to query)
  2. VDOMs specific DNS Servers/Databases (enabling DNS services)
  3. FortiOS global "system DNS" setting (global FortiOS where to query)

Hence, the idea here is to use the FortiOS available toolset in order to enforce DNS over TLS for any outbound name resolutions happening at the Edge/WAN side of our network. To do so, here is what I've enabled and configured.

1st, we'll need a WAN VDOM specific DNS setting/forwarder on our WAN fronting VDOM (referring to point #1 above).

fgt # c v
fgt (vdom) # ed vWAN 
fgt (vWAN) # conf sys vdom-dns
fgt (vdom-dns) # sh
config system vdom-dns
    set vdom-dns enable
    set primary
    set secondary
    set dns-over-tls enforce
    set server-hostname "dns.quad9.net"
    set interface-select-method specify
    set interface "wan1"

Here, I'm setting within the vWAN VDOM a DNS settings specific to that VDOM. Meaning that our vWAN VDOM will now convey recursive DNS queries over the set in parameters shown above. I'm here leveraging the Quad9 services which support DNS over TLS amongst many other good things.

The next step is for us to host a local DNS server (referring to point #2 above) within that same WAN fronting VDOM in order to convey clear text DNS resolutions back and forth the backend/frontend VDOMs of our configuration.

fgt (dns-server) # sh
config system dns-server
    edit "vWAN-EMAC"
        set mode forward-only
    edit "LB_vWAN"
        set mode forward-only

Here, I'm setting up DNS Server(s) on my vWAN VDOM, here setting it on two interfaces, a physical interface and a loopback interface, the latter that will be our FortiOS global DNS Server entry used later. You might ask yourself why the need of the EMAC-VLAN interface in that config? the answer is here.

The parameter set mode forward-only would usually fall back to the globally set FortiOS DNS Server(s), although here, we've shifted that using the config system vdom-dns settings within that particular vWAN VDOM. Hence, from the WAN fronting VDOM, recursive DNS resolutions will now hit the Quad9 DoT settings entered previously.

Finally, our last "DNS" step is now to instruct our FortiGate to globally use our newly created clear text DNS Server seated within our WAN fronting VDOM (refering to point #3 above).

fgt # c g
fgt (global) # conf sys dns
fgt (dns) # sh
config system dns
    set primary "IP_of_the_loopback_DNS_server_in_vWAN"
    set secondary "IP_of_the_loopback_DNS_server_in_vWAN"
    set domain "your_lan_domain.local"
    set source-ip "IP_you_want_such_traffic_to_originate_from"

Obviously, we'll need an IPv4 Firewall Policy within our vWAN VDOM in order to grant backend access to the WAN VDOM loopback interface acting as our clear text DNS Server. I'm not detailing it here although, obviously, routing shall know where that loopback interface is reachable amongst your backend... Note as well that the shown policy is an "open/fortistudent" type of policy. I'll advise to enforce the "srcaddr" object(s) according to your schemes and this only from DNS recursive tolerated/trusted sources:

config firewall policy
    edit 0
        set name "_to_WAN_DNS"
        set srcintf "zLAN"
        set dstintf "LB_vWAN"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL_ICMP" "DNS"
        set logtraffic all

Once this is in place, we're ready to roll. We can verify that our DNS over TLS is working using the builtin packet sniffer:

fgt (vWAN) # d sniffer packet wan1 'port 853' 4 0a
filters=[port 853]
2.391256 wan1 -- REDACTED.13668 -> syn 62457838 
2.393536 wan1 -- -> REDACTED.13668: syn 4085796624 ack 62457839 
2.393596 wan1 -- REDACTED.13668 -> ack 4085796625 
2.394480 wan1 -- REDACTED.13668 -> psh 62457839 ack 4085796625 
2.396939 wan1 -- -> REDACTED.13668: ack 62458245 
2.397901 wan1 -- -> REDACTED.13668: 4085796625 ack 62458245 
2.397931 wan1 -- REDACTED.13668 -> ack 4085798073 
2.397940 wan1 -- -> REDACTED.13668: 4085798073 ack 62458245 
2.397965 wan1 -- REDACTED.13668 -> ack 4085799521 
2.397973 wan1 -- -> REDACTED.13668: psh 4085799521 ack 62458245 
2.397995 wan1 -- REDACTED.13668 -> ack 4085799845 
2.414470 wan1 -- REDACTED.13668 -> psh 62458245 ack 4085799845 
2.416980 wan1 -- -> REDACTED.13668: psh 4085799845 ack 62458325 
2.417019 wan1 -- REDACTED.13668 -> psh 62458325 ack 4085800084 
2.417109 wan1 -- -> REDACTED.13668: psh 4085800084 ack 62458325 
2.437200 wan1 -- -> REDACTED.13668: psh 4085800323 ack 62458387 
2.437260 wan1 -- REDACTED.13668 -> ack 4085800417 

Obviously as well, we shouldn't witness any clear text UDP/53 traffic outbounding our premises:

fgt (vWAN) # d sniffer packet wan1 'port 53' 6 0a
filters=[port 53]

Another neat thing about such a setup is that of course, you're in full control over DNS Filters applicable within your premises, where DNS traffic occurs in clear text. Meaning that you can and should at least record all the DNS queries sent in clear text from within your premises (ex: on the vWAN VDOM clear text DNS server itself). You could also further apply DNS Filtering if needed/wanted.

While I've been conducting some testings regarding this post, it seemed that the default FortiGuard DNS Servers (the ones factory configured within FortiOS) aren't supporting either DoT/DoH, hence the Quad9 integration.

Finally, on the outbound, you gain the privacy of using cyphered DNS resolutions using the excellent services offered by Quad9, from which privacy is crystal clear.

Hope you've found this post useful.
Thanks for all the emails =)


Image Credits: localservers 2 by Simon Stålenhag https://www.simonstalenhag.se

Also, check Simon's radical music here: https://simonstalenhag.bandcamp.com/

Show Comments