Is Sophos UTM 9 Firewall or IDS blocking EDNS0 queries (UDP packets that are larger than 512 byte)?

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.)

Debugging thoughts:

It would help to break down your traffic flow, to clarify whether UTM DNS has any involvement in the failed lookups.

• Is UTM running with DNS SEC on or off?
• Does the Active Directory DNS server relay to UTM?  Does UTM relay to Active Directory?
• Can UTM query Active Directory DNS successfully?
• Can Active Directory DNS query UTM successfully?
• Do you use Standard Mode or Transparent Mode filtering?    UTM does DNS lookups when you are using Standard Mode, and when using Transparent Mode with Pharming Protection enabled.
• Are you using a forwarder for all traffic, or do some queries use root hints?   Do your symptoms change depending on the forwarder used - Quad9, Cloudflare, Google, or something else?

You also want to look at the error returned by the failed DNS lookups.   Are you getting:

• a response timeout (no answer), which indicates a blocked packet, or
• a NXDOMAIN (not found), which probably implies a result where DNS SEC signatures are expected.

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.

Bandwidth

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.  

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.)

Debugging thoughts:

It would help to break down your traffic flow, to clarify whether UTM DNS has any involvement in the failed lookups.

• Is UTM running with DNS SEC on or off?
• Does the Active Directory DNS server relay to UTM?  Does UTM relay to Active Directory?
• Can UTM query Active Directory DNS successfully?
• Can Active Directory DNS query UTM successfully?
• Do you use Standard Mode or Transparent Mode filtering?    UTM does DNS lookups when you are using Standard Mode, and when using Transparent Mode with Pharming Protection enabled.
• Are you using a forwarder for all traffic, or do some queries use root hints?   Do your symptoms change depending on the forwarder used - Quad9, Cloudflare, Google, or something else?

You also want to look at the error returned by the failed DNS lookups.   Are you getting:

• a response timeout (no answer), which indicates a blocked packet, or
• a NXDOMAIN (not found), which probably implies a result where DNS SEC signatures are expected.

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.

Bandwidth

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.