UTM 9.201-23 DNS Issues

5 - You can use UTM as a DHCP and Windows Server as DNS. DHCP doesn't depend on AD but I myself prefer to configure Windows servers as DHCP servers.

6 - Don't go with the last one, because in AD environments clients and other servers should point to your Domain Controllers in DNS settings. DNS settings should be set at the properties of your server object, tab Forwarders (scrshot).

Thank you Vilic! I understand now point 6 (The internal DNS server's first forwarder is to the Astaro DNS Proxy, then to the OpenDNS servers). If someone else has the same question, then I would strongly suggest reading:
Understanding forwarders: Domain Name System(DNS)
Using forwarders: Domain Name System(DNS)
I never found good explanation when I googled “astaro” AND “windows server” key words. I was able to find the above articles after the Vilic’s screenshot.
To make sure I (and other readers) understand how the query works, let say:
A client computer sends a query to the internal windows dns server, then the query will be resolved if it is found in any of the zones or in the cashe. If it is not there then it will use the "Forwarders". We have astaro dns proxy server as the first forwarder. So the query goes there, and astaro will forward it to the opendns or isp servers (depending what we decided to use, as explained in Bob’s dns best practices – either or, but not both). I understand that the default ip for astaro DNS proxy will be the default gateway (192.168.2.100). Does it matter if I create a 2nd interface (isolated from the first one) in different subnet with 192.168.3.100? Is astaro proxy’s ip the same (in our example 192.168.2.100)?
I have three interfaces, “internal”, “domain”, and “workgrp”. The first interface is only used by one computer for astaro’s webadmin. The second one has a windows DC and computers joined to the domain. The third interface has a couple computers not part of any domain. For the third interface (workgrp) I manually updated astaro’s Static Entries. Astaro in this interface is DHCP server. In the 2nd interface (domain), I had Astaro as DHCP server and Windows Server 2012 as DNS server. However, I can disable the DHCP server for the “domain” interface and add DHCP in Windows Server. And, here referring to the bullet points of DNS best practices collected by Bob, I am going to add astaro proxy IP in the windows server forwarders, then OpenDNS or google dns since OpenDNS is not supporting dnssec. Here, I need to make sure that despite the different interfaces we create, the astaro proxy Ip remains the same (so it shoud be 192.168.2.100 in my example). Does astaro have to be joined to the windows domain? If it has to join the domain then how does this impact my third interface, “workgrp”? I also understand, that Williams suggests I can (alternatively) use opendns as a forwarder in my windows server instead of astaro’s proxy ip. And if I do that, I would use “forwarders assigned by ISP in astaro forwarders. Again, following Williams suggestion I still have to use point 4 from Bob’s dns best practices. If that is correct then what about point 3? 
Quoted:
1. The Astaro DNS Proxy lists "Internal (Network)" (also other internal networks, like "DMZ (Network)" if applicable) as 'Allowed networks'.
2. The Astaro DNS Proxy uses an Availability Group containing the OpenDNS name servers in 'DNS Forwarders', and 'Use forwarders assigned by ISP' is not checked.*
3. In 'Request Routing', the internal DNS is used for reverse DNS of internal IPs (for example if your internal subnet is 172.16.20.0/24, you would have '20.16.172.in-addr.arpa -> {Internal DNS}'. With that, the Astaro can list machine names instead of internal IP addresses in the reports.
4. Also, in 'Request Routing', so the Astaro can resolve internal FQDNs, add, for example 'yourdomain.local -> {internal DNS server}'
5. Configure Windows Server (or other) DHCP server for internal devices to point at your internal name server for DNS, then the Astaro, then the OpenDNS servers.
6. The internal DNS server's first forwarder is to the Astaro DNS Proxy, then to the OpenDNS servers
. 

In summary, a computer (not part of any domain) in my third interface can have astaro to resolve internal name for my third interface since I manually updated the static entries for this interface. Point 4 from the above quote will resolve internal names since the query will go to the windows server dns. Is this correct? Or, does the query for internal names go directly to the windows server dns by ignoring my static entries I created in astaro itself? 
In my second interface, “domain” the computer will go directly to windows server dns (point 5), and if it is not cashed or recorded on one the dns zones then can either go (according to Bob) to astaro as first forwarder or (according to William) to either opendns, google dns as the first forwarder.
Also, I understand that the best dns practices is a set that Bob has collected from user’s output and it is made available as a reference.
So, am I understanding correctly? This questions have bothered me for a couple of months.
Please, someone could shed light in my confusion. This will help other readers, too. Playing with dns is not an easy game.
Thank you,
Martin

Martin if you were my client i would advice you the following (keep in mind that I am Windows Server/Networking veteran and relatively new in Sophos UTM world, so listen to other suggestions regarding to UTM also..[:)]

• Since you already have DNS services running on your Windows servers (as a prerequisite for having Active Directory environment), use it as a single management point for your DNS infrastructure. Remove all static created entries from UTM and recreate them on Windows DNS.
  
•  Point all your clients and servers including Workgroup ones to your Windows DNS servers.
  
•  Join UTM to Domain. It is required for AD SSO, but even if you don't need this funcionallity it will not harm it.
  
•  Stick with Bob's advices from 3&4 points, even UTM is not used as DNS server from client side it should be aware of your interal forward and reverse lookup DNS infrastructure.
  
•  Migrate your DHCP services from UTM to Windows servers. I guess that you have 2 Domain Controllers for AD redundancy, use them also for DHCP service redundancy.
  

I agree with these suggestions to use DNS and DHCP on the Windows servers. Remember to make a Request Route for each internal domain. 

Cheers -  Bob

Sorry for any short responses.  Posted from my iPhone.

Thank you very much! It is very appreciated.

Martin

Vilic,
Thank you for the guide. I was hopping i could take a little bit more from your time.
When you say, "Point all your clients and servers including Workgroup ones to your Windows DNS servers.", do you do it by going to network adapter properties and manually adding the dns server IP under "use the following DNS server addresses"?
I thought we don't need to do that because it will be done by specifying the "Request Routing" in Astaros.
In addition, I have set firewall rules to drop the packets between different interfaces. Would that impact the workgroup computers communicating with my internal dns server? 
Thank you

Hi Martin,

You can use request routing, or you can point to the windows servers without it.
I'm not sure which is best from a windows networking perspective.

If your internal DNS server is on a different interface than your workgroup computers, then you need to allow them to make DNS queries, or use request routing.
Also note that if you have an AD server, Windows PCs expect to be able to make NTP or TIME requests to the server, authentication requests, etc.
Check your logs to see if you are blocking anything important.

Barry

Martin, you could also leave it as it is now. If yor goal was to separate AD and Workgroup interfaces that is better solution.

DNS resolution should work correctly in both scenarios anyway.

Berry and Vilic,
Thank you for your advices!
Martin

Martin is your DNS Request Routing setting on your UTM working correctly currently? 


I too have 9.201-23 running and it failes to resolve the internal DNS server thru the DNS request routes in the UTM.