[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!
Thomas

  • In reply to BAlfson:

    How should the DNS config be in distributed setups?

    E.g. a company has 3 sites with own local DNS-servers and VPN is configured to tunnel the whole traffic. Should every DC/DNS has the UTM as forwarding target configured as this setting is not replicated via Active Directory or should the chain be site-DNS -> central-DNS -> Sophos-DNS?

  • In reply to kerobra:

    That's how I would do it, Kevin, but with the sites falling back to the Sophos if the central-DNS is unavailable.

    Cheers - Bob

  • Bob, you might want to edit the following in RED.

    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.

    I was able to figure out why resolution still wasn't working because I forgot to put the period (.) after arpa.  Might want to edit that line to make sure people include the period at the end.

     

    - Chris

    Breakingcustom Technologies, LLC.
    Sophos Silver Solution Partner
    Sophos XG16.5 Certified Architect / Sophos UTM Network Engineer

  • In reply to Breakingcustom:

    Interesting, Chris!  I wonder what is different since I think that this works for my clients with "arpa" instead of "arpa." in the Request Route.  What test are you making to see whether reverse DNS is working - are you looking at the Executive Report?

    Cheers - Bob

  • In reply to BAlfson:

    regarding the anserver from Breakingcustom an yours:

     

    in RFC is the dns trailing dot needed for  fully-qualified (unambiguous) DNS domain names. The . (dot) is the root of DNS. An example: community.sohos.com. is in fact a fully-qualified (unambiguous) DNS domain names for this community. It will "spell" root com sophos community.

     

    Best regads

     

    Georg

  • In reply to MaxPalue:

    Hi Chris and Georg,

    To see what's in the Bind configuration file in the UTM, I did:

    cat /var/sec/chroot-bind/etc/named.conf|more

    The result showed:

            zone "10.in-addr.arpa" IN {
                    type forward;
                    forward only;
                    forwarders {
                            10.x.y.7;
                    };
                    check-names ignore;
    };

    I then Googled to find that this appears to be correct usage in Bind: Configuring Reverse DNS in BIND 9.

    Does anyone have information to the contrary?

  • In reply to BAlfson:

    Hi there, I'm a newbie to Sophos and had a quick read through the thread to find out DNS Best Practices for XG Firewall but I presume the same applies as applies to UTM.

     

    One follow on question I had was - in the aim of avoiding users locally changing their local DNS IP settings, do you recommend as DNS best practice to setup a rule on the XG firewall to allow all tcp/udp on port 53 in/out to our external name servers and then have a rule below that says Block all tcp/udp in/out to all ip addresses on port 53?

    [Edit] Or is there a way for XG to simply forward' people's DNS requests (to your preferred external DNS providers) without them knowing, instead of having the possibility of someone manually configuring DNS and having it just not work.

    Thanks

    Gerry

  • In reply to Gerry Morley:

    Maybe someone else can answer that question, Gerry.  XG doesn't yet do enough to make it worthy of my time to learn it in detail like I know the UTM.

    Cheers - Bob

  • In reply to Gerry Morley:

    You can simply create a NAT rule for all outgoing port 53 traffic where you change the destination to your own specified DNS server(s), but even better is to just forward it to your own UTM or AD (whichever you use in DHCP). In that case even custom specified DNS servers will be diverted to the DNS servers of your choice.

    I'm not a real XG pro, but I assume it's possible to create DNAT rules .

  • In reply to apijnappels:

    Hi Apijnappels  - thanks for the reply and good ideas there. I will be trying a few things this week with DNS. I need to try request routing as well. From what I understand if I put this place I might not need a rule at all for port 53 as it should use the DNS setup on the XG regardless. Will revert back here once I have tested it.

  • Die ganze Anleitung ist irgendwie Schrott, ich kann mir nicht vorstellen das damit die

    Namensauflösung per Nodename klappt. Sie klappt nur mit dem FQDN, aber nicht mit dem

    Nodenamen.

  • In reply to BAlfson:

    BAlfson

    DNS Best Practice

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

    1. ...
    2. On the 'Forwarders' tab, use an Availability Group containing the OpenDNS or Google (8.8.4.4 first, for speed) name servers in 'DNS Forwarders'. 'Use forwarders assigned by ISP' is not checked.*
      ....

    As not everyone here is located in the US, if the UTM uses OpenDNS or GoogleDNS as forwarders, things like geolocation via DNS aren't working anymore. So a lot of CDN and Office365 may perform not in perfect condition.

    I think one should keep that in mind for best practices.

    Best

    Alex

  • In reply to Alexander Busch:

    Could you expand on that, Alex?  Some ISPs hijack DNS and that interferes with RBL lookups, hence the preference for OpenDNS and Google and de-selecting 'Use forwarders assigned by ISP'.

    If one were to use Request Routing for these CDNs and Office365, what domains or FQDNs would one want to direct to one's ISP's name servers?  If you wanted to start and maintain a post in a thread named something like DNS Best Practice and CDNs, Office365, etc., I would link to it from the Best Practice post I maintain at the top of this thread.

    Cheers - Bob

  • In reply to Alexander Busch:

    Alexander Busch

     

     
    BAlfson

    DNS Best Practice

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

    1. ...
    2. On the 'Forwarders' tab, use an Availability Group containing the OpenDNS or Google (8.8.4.4 first, for speed) name servers in 'DNS Forwarders'. 'Use forwarders assigned by ISP' is not checked.*
      ....

     

     

    As not everyone here is located in the US, if the UTM uses OpenDNS or GoogleDNS as forwarders, things like geolocation via DNS aren't working anymore. So a lot of CDN and Office365 may perform not in perfect condition.

    I think one should keep that in mind for best practices.

    Best

    Alex

     

     

    Not a problem; I live in Europe and have used both Google and OpenDNS as forwarders for a long time. I still get geolocation sites directed to European datacenters and also while using those I cannot watch the American Netflix series. Most geolocation works based on you own IP-address, so unless you start using VPN's or other masquerading technology to hide your public IP, its not a problem.

  • In reply to BAlfson:

    Hey Bob,

    BAlfson

    Could you expand on that, Alex?  Some ISPs hijack DNS and that interferes with RBL lookups, hence the preference for OpenDNS and Google and de-selecting 'Use forwarders assigned by ISP'.
    ...

     

    I totally agree with you that there are probably more problems with providers' DNS servers than Google or OpenDNS. Root hints are too slow. As already mentioned, there will probably be problems in connection with Office 365, because the function of the DNS geolocation cannot work properly.
    Essentially, it is about the provider operating a large network itself (MGN - Microsoft Global Network) and trying to connect the client to an access point with low latency. Of course, the geographical distance is important for this. Therefore, the resolution of a certain address e. g. outlook. office365. com to different targets, depending on the geographical position. If the DNS server is Google, for example, I will probably get an access point near the Google DNS servers, although I am in Germany myself.
    This is a short summary
    There are certainly better explanations. You can find one here.
    In any case, this would be a point that speaks in favour of performing the DNS resolution as locally (provider) as possible.
    I do not know now whether there are indeed measures that Google is also taking to counteract this. 

    BAlfson

    ...

    If one were to use Request Routing for these CDNs and Office365, what domains or FQDNs would one want to direct to one's ISP's name servers?  If you wanted to start and maintain a post in a thread named something like DNS Best Practice and CDNs, Office365, etc., I would link to it from the Best Practice post I maintain at the top of this thread.

    I don't think I'm quite ready to contribute enough. Currently I don't even use Office365 productively: -)
    But I thought there might be people here who already have experience with it.
    But in the future I will gladly come back to your offer.

    Best
    Alex