Advisory: Support Portal Maintenance. Login is currently unavailable, more info available here.

DNS best practice

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 (8.8.4.4 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 172.16.20.0/24, 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 8.8.4.4 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



Tags
[edited by: FloSupport at 11:06 AM (GMT -7) on 18 Sep 2020]
  • 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.

    Barry
  • 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".

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

    Thanks!

    • 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
    eclipse79
  • 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 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.

    Cheers - Bob


    I have tried this configuration, but in the reports I see "No hostname found" [:(]
    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
  • You might have seen the model we use as I've described it in many places here:


    Hi, can anyone explain why I should use ASG as a DNS forwarder at all? What's behind the suggested model? I did some reading already and still cannot understand it.

    Basically, I am having difficulties with my current configuration which I inherited and I want to do it right if I decide to change it. But first I need to fully understand what I am doing.

    Someone who configured ASG for us seems to have done it totally wrong.
    - there is an internal DNS on the DC
    - it has our ISP DNS as forwarders (2), then the google DNS
    - on ASG there is nothing in the list of allowed networks on the Global tab
    - in the forwarders list on ASG there is the internal DNS, google, and the checkbox "use forwarders assigned by ISP" is selected

    We were experiencing DoS attacks from the outside on UDP/TCP ports 53. Desperate to stop it and not having enough time to figure out how to configure this properly I just blocked the ports 53 coming to the external IP address of our network.

    What I need is just that the PCs which are on the internal network and are all in the same domain could use the internet, i.e. resolve internal and external names. We use DHCP.

    So what would you recommend me to do? The suggested (best) configuration still?
  • Hi Bob,

    I have tried the solution that you gave, but its not working.
    I m not an expert, maybe i do wrongly.
    Please guide me and explain the steps in more easy way (like along with the example) ?
    our Astaro UTM 9 version is 9.209-8 (latest version).
    Thanks
  • I know this is an old thread but I wanted to ask a question anyway.  At this link, https://community.sophos.com/kb/en-us/120283, the first thing to do is add "Allowed Networks".  Its states: 

    1. Browse to: Network Services | DNS | Global
    2. Depending on network configuration either add:
      • Your internal networks if clients use UTM as DNS server
      • Your DNS servers if clients use an internal DNS server for DNS requests

    All of my clients use our Internal DNS servers for requests, so I would pick the option to add my DNS Servers to the allowed networks list.  But in your comment above, you are only entering internal networks.  Which would be better?  I understand the rest of this but the first part confused me.  

    Thanks

  • The reason for that, David, is to create a faster, more-robust name resolution scheme.  If the DC is running, it will have the quickest answer.  If the DC is down, the clients will get their next-fastest response from the UTM.  If both the DC and the UTM are failing to provide name resolution, the clients will query the OpenDNS or Google name server(s).

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hmm, in most cases, domain-joined clients will ask their DC, which in most cases will often be their DHCP server as well.
    If the DC is down - even if I had given the UTM as 2nd DNS server in DHCP options - I'll normally have bigger problems than people not being able to surf... :D

    And if the UTM in your constellation is also down, how do the people connect to the internet then or how do they connect to any external dns server?
    In most cases an UTM will be the (only) gateway in the network, maybe the 1st/only or 2nd dns server and if 1st it will be serving DHCP, too.

    What I was wondering... we (my company) are configuring new windows dns servers regularly to allways and ever use the root servers only. Often we do not get any dns servers from the ISPs with the static IP configuration and in the rare times we had forwarded to 8.8.8.8 and 8.8.4.4 DNS requests weren't noticeably faster than using only the root servers. What are your experiences with that Bob?

    Cheers

    Kevin

    Gruß / Regards,

    Kevin
    Sophos CE/CA (XG+UTM), Gold Partner