DNS "Fallback" to unknown server

Just finished working through a problem with one of my XG sites.

The site has an XG210 running SFOS 17.5.4 MR-4-1. Under Network > DNS, I have two IPv4 DNS servers configured, both internal to the LAN (.232 and .233, for reference). There is no IPv6 connectivity either in-site or out-of-site. There's a split-horizon DNS in place so that services hosted on premise resolve locally on the LAN, or to the XG on the Internet.

Clients are configured by DHCP to use the XG as primary DNS, and .232 and .233 as secondary/tertiary. I've done this so we get a bit more "intelligence" in Sophos ATP.

Today we restarted the two internal DNS servers for maintenance (patching etc). After doing so, the Sophos was returning the Internet DNS entries for internal services.

Where do I stop the XG from "helping"? This is not the behaviour we need - we had 50 clients reporting certificate errors, failing to connect to services and generally screwing up. I am aware that systemd has been "enhanced" (/s) to fallback to Google - but I wasn't aware this was still enabled on XG, if that's possibly the cause?

  • In reply to LuCar Toni:

    Yes, Pharming protection is enabled, although clients aren't configured to use the proxy. However, I don't see in the list at the bottom of that article, nor in the linked article https://community.sophos.com/kb/en-us/132232, the fallback configuration. If I follow through the steps on KB 132634 and interpret, perhaps you can tell me what I am missing:

    1. User types <domain.com> into their browser and hits enter.

    OK - it's not necessarily a browser, it's Outlook and other apps, but that part of it shouldn't matter because it's still HTTPS. In this case, I'll use the example "service.example.com".

    2. The host will use its host's file or DNS cache or the configured DNS servers to resolve the <domain.com> to IP address.

    Seems clear. In this case, service.example.com is not in the hosts file (or shouldn't be!), nor in cache (because it shouldn't resolve other than to the internal IP and it may have timed out of cache) and the configured DNS servers are not responding.

    3. The host will create a TCP session to that IP address and will send a HTTP GET (80) or Client Hello (443).

    Not sure how this works given the name shouldn't have resolved. Let's assume it works somehow.

    4. The Firewall's web proxy service will look in the host field of the HTTP GET packet or the SNI (server name identifier) field of the Client Hello packet and determine whether the user is allowed to reach this host based on the URL filtering configuration. 

    Yep - they would be permitted. No particularly restrictive filtering in place here, just anti-malware, and no risky downloads.

    5. If they are allowed to reach this host, the firewall will then re-resolve the host <domain.com> using its configured DNS Servers.

    Again - can't resolve because all the configured DNS servers are down.

    6. The proxy will then make the request to the IP that the XG Firewall has resolved for <domain.com> and serve the web page.

    Fair enough.

    7. In case the proxy cannot resolve <domain.com>, XG Firewall will use the IP address resolved by the host in step 2 and serve the web page. however UTM will send a Host not found error page. 

    So this should fall back to step 2, which does not resolve?

    So obviously I have to be missing something - I don't immediately see specific "anti-pharming" DNS servers configured anywhere but I'm still digging through the config for such.

  • In reply to LuCar Toni:

    The post which you shared here is very useful for me and you explained in a detailed way. Thanks for that. AC Market is one of the latest apps which is like a store to download the cracked apps and games for free.