Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Ysharaf
New Contributor

DNS Advice on 140d/200d

Hello All,

 

I support 5 HA clusters across a few sites, most made up of 140D-POE's other than HQ where we have a pair of 200D-POE's and also our Main DC. Remote sites have no RODC or DC they are not currently on the domain

 

spoke and hub IPSec VPN setup between HQ and remote sites. I am trying to get our remote sites on the domain to help in the rollout of some company wide administration software, machines need to be on the domain to be visible to this remote management tool.

 

Heres the plan in all its half understood glory, please excuse my incorrect terminology use - 

 

Each site has a VPN tunnel to HQ where our Primary DC sits

I will put in place a second VPN tunnel to a cloud based DC as a failover

This ensures remote offices dont go out of service if either link fails

 

I dont want the VPN link to be used for all DNS lookups, this seems like a lot of traffic going over a tunnel,

Heres where my terminology fails me. I want the local fortigates at each side to resolve internet DNS requests e.g. google.com, but any company domain based requests to be forwarded over the VPN to wither HQ or the secondary cloud DC.

 

All the guides/posts I've found seem to be showing how to do it vice versa, relying on the remote DC to resolve everything. Is this the norm? If an office of 30-40 users all have their DNS traffic going over a VPN tunnel would this be seen as unorthodox?

 

So I got as far as turning on advanced DNS controls on the fortigate and getting my head around creating zones but not the process for prioitizing what DNS requests go where.

 

Thanks for your help in advance, much appreciated by a humble IT administrator single handedly supporting 6 offices and in way over his head.

 

Shhhh dont tell the boss!

1 REPLY 1
ede_pfau
Esteemed Contributor III

hi,

 

and welcome to the forums.

 

First off, I wouldn't put any effort into optimizing DNS traffic. Requests are small, bandwidth consumed is comparatively low even for a couple of dozens of users, and the remote FGT caches DNS hits. This alone will reduce DNS traffic to unique requests. If really necessary you could tweak the TTL for cache entries but even that is too much.

If you really want to set up a DNS in each remote FGT the chain of DNS would be

- resolve local domain first

- forward to HQ DNS

and HQ DNS would

- resolve local domain first

- forward to system DNS (which usually is the ISP DNS)

 

Now the perfect setup would be if you didn't have to setup local DNS zone entries but could mirror the HQ DNS zone. I haven't played with the DNS server settings in that respect but I remember that there is a 'shadow' role option. Maybe this is documented by FTNT, either in the Handbook or on the KB.

 

Again, I think it wouldn't be worth it. Shadowing a DNS zone containing all HQ and remote hosts (zone transfer) amounts to some traffic, and more so if it's done frequently. I only set up local DNS in a FGT if the site needs to resolve some (< 10) local names before letting the ISP's DNS resolve the rest. FTNT's implementation is not complete, e.g. there is no automatic PTR domain for reverse resolution and some such.

 

 

 

P.S. we're all overworked and underpaid, and live from the candy in IT...


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
Labels
Top Kudoed Authors