We'd love to hear about it! Click here to go to the product suggestion community
our clients are using the integrated DNS server from Windows Server 2012.Both the clients and the Windows servers are behind the Sophos UTM 9 firewall.
A few days ago we have enabled DNSSec validation for remote queries on the Windows servers. Since then some websites (like gmx.net, web.de) stopped working because of failed DNS resolution. It is toggeling between working and not working.
I've found the following support article from Microsoft:https://support.microsoft.com/en-us/help/832223/some-dns-name-queries-are-unsuccessful-after-you-deploy-a-windows-base
Would it be possible that Sophos UTM firewall or IDS is blocking EDNS0 queries somehow?
Hi,i don't know such behaviour.But first i would check IPS and DNS Log Files. Blockings should be reported there.
In reply to dirkkotte:
thanks for your reply. I've checked die IPS and "DNS Proxy" log, but nothing suspicious there.Since we are using the Windows servers for DNS resolution, the DNS Log should not be relevant I guess?
Hi Christoph Mitasch
I suggest checking the packetfilter.log for the Server IP address and see if there is any Drop/Reject packets. Further, if you see that UTM9 is dropping packets, please refer to this KBA Packetfilter logfiles on the Sophos UTM This will help you get an idea about any drops.
I agree that there should be a log entry somewhere if the traffic is blocked. The packetfilter / firewall live log is abbreviated, so it is better to work from a download of the full log.
(The packetfilter has false positives associated with session termination, because the connection tracker stops tracking as soon as one "bye" message is seen. This causes the reply to be blocked, and is evidenced by "RST" or "FIN" in the tcpflags token.)
It would help to break down your traffic flow, to clarify whether UTM DNS has any involvement in the failed lookups.
You also want to look at the error returned by the failed DNS lookups. Are you getting:
DNS SEC in UTM
This also raises the question of whether UTM DNS SEC should be enabled or disabled. Active Directory will consider UTM to be a remote server, so it will expect DNS SEC to be enabled if it has any reason to query UTM. But enabling DNS SEC on UTM is fraught with challenges. UTM supposedly has embedded support for DNS SEC, but it is not well documented and my attempts to gain more detail have been frustrating, using both support and sales channels. Here is my current understanding:
- If the DNS SEC feature is enabled, UTM requires all DNS servers to have DNS SEC servers to be fully DNS SEC compliant. This appears to prevent it from sending DNS queries to Active Directory, which has a limited implementation of DNS SEC. For most installations, this is not viable. Of course, Active Directory capabilities vary with each Server version, and I am not up to speed on the latest Microsoft changes.
- The UTM implementation of DNS SEC does not appear to support DNS over TCP, a feature which does not appear to be required but does seem to be normative, for performance and security reasons.
- There are a few posts in this forum from users who attempted to enable DNS SEC on their UTM, all of which seem to have failed. I have not found anyone who reported success.
We know that any organization generates a lot of DNS traffic. I have not been able to find any guidelines about how much incremental bandwidth consumption should be expected when switching from DNS to DNS SEC successfully. Any such overhead will grow if DNS SEC becomes more widely adopted.
In reply to Christoph Mitasch:
Hallo Christoph and welcome to the UTM Community!
See #2 in Rulz (last updated 2019-04-17) - please also check the Firewall log.
There is a DNSSEC setting in WebAdmin, but if I understand your configurations, you shouldn't need to use it.
In any case, you might want to read and consider DNS best practice.
Cheers - Bob
In reply to BAlfson:
thanks for your hints.
We ended up to disabling DNSSEC validation again on Windows Server 2012.
I've installed another Windows Server 2016 for testing purposes only.It worked with that behind the same firewall.
So I guess there is problem with Windows Server 2012 and not the firewall.