[SOLVED]DNS best practice?

There are two ways to configure DNS:

One way:
- Allowing DNS outgoing for your internal nameservers
- internal nameservers forwarding to ISP-DNS
- ASG pointing to internal nameservers 

Another way:
- ASG forwarding to ISP-nameservers
- "request routing" on ASG for internal domain pointing to internal nameservers
- internal nameservers forwarding to ASG
Which way do you use? And why? Which is "officially preferred"?
Both configurations seem working good for me, we run the first alternative on our cluster, the second in branch offices without internal dns (domain dns reachable via site2site-vpn).

Thanks for your ideas!

  • Hi,
    The second is more secure, as it protects your internal nameservers from being 'poisoned'.

    Also, you don't have to do request routing, you can just have DHCP assign the internal nameservers' IPs.

  • DNS Best Practice

    You might have seen the model we use as I've described it in many places here:

    1. The 'Global' tab of 'Network Services >> DNS' lists "Internal (Network)" (also other internal networks, like "DMZ (Network)" and any "VPN Pool" if applicable) as 'Allowed networks'.
    2. On the 'Forwarders' tab, if you use or plan to use the SMTP Proxy, use an Availability Group containing the OpenDNS or Google ( first, for speed) name servers in 'DNS Forwarders' (if using any spamhaus.org RBLs with the SMTP Proxy, don't use Google DNS). 'Use forwarders assigned by ISP' is not checked.*
      1. If the SMTP Proxy is not to be a part of your setup, don't add anything in 'DNS Forwarders' and do select 'Use forwarders assigned by ISP'.  See the Change Log below concerning CDNs.
      2. Alternatively, if you're using a Microsoft CDN like Office365, do use the Availability Group approach above and add a Request Route for office365.com pointing at your ISP's name server.
    3. In 'Request Routing', the internal DNS is used for reverse DNS of internal IPs (for example if your internal subnet is, you would have "20.16.172.in-addr.arpa" in the 'Domain' field and your internal DNS server(s) in 'Target Servers'. With that, the UTM can list machine names instead of internal IP addresses in the reports.
    4. Also, in 'Request Routing', so the UTM can resolve internal FQDNs, add, for example 'yourdomain.loc -> {internal DNS server}'. Do the same for other domains for which you have Forward Lookup Zones in your 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 UTM, then the OpenDNS or Google servers.
    6. The internal DNS server's first forwarder is to the UTM's DNS Proxy, then to the OpenDNS or Google servers.
    7. If you consistently have "connection to server timed out" issues and ECN is not selected ('Advanced' tab of 'QoS'), empty 'Allowed networks' in #1, configure the internal DNS server to bypass the UTM in #6. I suspect this is caused by a problem at the ISP.
    8. In Transparent mode Web Filtering, the client browser resolves FQDNs.  When Pharming Protection is enabled at the bottom of the 'Misc' tab, the Proxy will block a request with "Host Not Found" if it cannot resolve the FQDN to an IP.  If disabling Pharming Protection eliminates such blocks for you, then you have not followed #1 through #7.

    We used to do it the other way, but comments by BarryG, BruceKConvergent and others convinced me to change our approach.

    Cheers - Bob
    * Caution: unchecking 'Use forwarders assigned by ISP' and failing to populate 'DNS Forwarders' will result in degraded performance as the ASG/UTM will fall back to the Root Name Servers.

    Change Log: 2020-02-14 Based on a post by wolfman1, I added a warning in 2. about using Google if spamhaus.org is one of the RBLs used in the SMTP Proxy; 2017-11-13 Added 2.a and 2.b based on further info in Alex Busch's thread; 2017-11-12 Added the caveat to #2 about the SMTP Proxy because of Alex Busch's comments about Content Delivery Networks (CDNs); 2017-08-02 added #8 based on a comment by Sophos' Michael Dunn; 2017-06-09 added "VPN Pool" to #1; 2017-04-08 made #3 clearer based on a question by jlbrown also added "or Google" to #5 & #6; 2017-02-12 added comment to #2 based on a comment here by rfcat_vk; 2017-01-14 added "in the 'Domain' field" in #3; 2015-09-25 In #7 corrected #5 to #6; 2015-09-24 changed Astaro to UTM and added #7 based on comments by vilic in DNS issue?; 2015-06-22 based on a thread by TCF, I improved the wording in #1, #2 & #4; 2015-06-20 changed from .local to .loc as reminded by bimmerdriver; 2015-03-20 Added title; 2014-10-04 DHCP and internal FQDNs; 2013-10-09 Added Availability Group idea from adrienjb in #2; 2013-02-04 reordered; 2012-08-20 Added "* Caution" note for #2 based on a suggestion by BarryG

  • In reply to BAlfson:

    Oh yeah, I forgot about the reports. You have to do the request routing for the reverse zones too, e.g. 1.168.192.in-addr.arpa.

  • In reply to BarryG:

    Thanks for your advice, guys.
    I used the first alternative in the past because of some performance issues and because of Reverse-DNS for internal clients.

    btw: for AD-SSO it is a "must" to resolve the internal domain. 

    The option to use reverse zones in "request routing" is an absolutely great idea I never thought about....  Thanks, BarryG!

    I will give it a try on our "main box".

  • In reply to tbrandl:

    Ok, short and simple:
    Works nice and fast. Reverse DNS for all subnets works fine, too.

  • I use DHCP to point the local machines to our internal DNS server, with the ASG box as the second choice. That allows us to add local DNS names for the machines on our 192.168.x.0 subnet, while maintaining a failover in case the local DNS server becomes unavailable. The local DNS server points to the ASG box, making ASG the sole point of contact with external DNS servers. The external DNS servers used are  Open DNS, with our ISP's regular DNS server as a lower priority alternative. Open DNS, if you have an account with them (which is free) allows for a level of DNS customization that you won't get from your ISP.
  • In reply to BAlfson:

    • The Astaro DNS Proxy lists the OpenDNS name servers as forwarders, and 'Use forwarders assigned by ISP' is not checked.

    Bob, I'm currently using 7.507. After I add dns servers, I cannot modify their order anymore. I have to clear and re-insert them. Can you tell me if in v8 has been added the "order function"?

    Thank you
  • They're ordered alphabetically in V7 and V8, so changing the hostnames is the only way.

    Cheers - Bob
  • In reply to BAlfson:

    They're ordered alphabetically in V7 and V8, so changing the hostnames is the only way.

    Thank you Bob, but the alphabetical order is also used by astaro for establish their priority? In other words:

    DNS A
    DNS B

    The primary DNS server is always A, is it right?
  • In reply to BAlfson:

    You might have seen the model we use as I've described it in many places here:
    In 'Request Routing', the internal DNS is used for reverse DNS of internal IPs (for example if your internal subnet is, 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.

    Cheers - Bob

    I have tried this configuration, but in the reports I see "No hostname found" Sad
    If I use NSLoockup function and I ask for workstation.mydomain.local it retrieve the correct ip. If I ask for ***.yyy.168.192.in-addr.arpa it does NOT retrieve any IP address
  • It depends on how you have your internal name server configured. In Windows Server, for example, workstation.mydomain.local is resolved by entries in the Forward Lookup Zones.  ***.yyy.168.192.in-addr.arpa is reolved by entries in Reverse Lookup Zones.  If you don't have DNS on your server configured to create reverse-zone entries automatically, then there's no information to retrieve. Wink

    Cheers - Bob
  • In reply to BAlfson:

    It depends on how you have your internal name server configured. In Windows Server, for example, workstation.mydomain.local is resolved by entries in the Forward Lookup Zones.  ***.yyy.168.192.in-addr.arpa is reolved by entries in Reverse Lookup Zones.  If you don't have DNS on your server configured to create reverse-zone entries automatically, then there's no information to retrieve. Wink

    Cheers - Bob

    Hi bob, 
    in reverse lookup zone I have a lot of ptr pointer with ipaddress - hostname, so it should work, I think!
  • Can you post a screenshot?

  • In reply to BarryG:

    Can you post a screenshot?


    Screenshot of the reports?
  • Screenshot of the DNS configurations, including the reverse entries.