After upgrading from 9.3 to 9.4, WAF Access Control via DNS Host no longer works

Over this past weekend I installed updates to take UTM 9 up to 9.4. 

 We use a DDNS system to define some external home office IPs in UTM9 as `DNS Host`entries. UTM-9 successfully resolves the hostnames to IP addresses. I host some internal web services behind WAF that require the client to be whitelisted on ACL Allowed Networks, and these rules have previously allowed me to have very low maintenance config for some of my users. It's worked great for years.

With the update to 9.4, this no longer works. Sophos still appears to resolve our IP addresses correctly, but the configuration in the end does not work.

In the WAF logs, I see many lines:

2017:06:17-23:59:59 astaro reverseproxy: [Sat Jun 17 23:59:59.613579 2017] [authz_host:error] [pid 5928:tid 2964650864] [client 1.2.3.4:50453] AH01753: access check of 'my.host.name' to /a/resource failed, reason: unable to get the remote host name
2017:06:17-23:59:59 astaro reverseproxy: [Sat Jun 17 23:59:59.613612 2017] [authz_host:error] [pid 5928:tid 2964650864] [client 2.3.4.5:50453] AH01753: access check of 'another.host.name' to /a/resource failed, reason: unable to get the remote host name

These lines were not present before the updates, but are significantly spamming the log now (every connection to this endpoint, regardless of the client requesting the resource, has these lines).

After a substantial amount of digging, I eventually found the generated config file for my WAF reverse proxy, and I think I've found the source of the issue. It has to do with the config written for whitelisting. Notice in my config below, the rules `RequireAll > RequireAny > Require host my.host.name` etc. In the Apache docs (https://httpd.apache.org/docs/2.4/mod/mod_authz_host.html#reqhost) it mentions that the rule requires two way verification of the hostname:

This configuration will cause Apache to perform a double reverse DNS lookup on the client IP address, regardless of the setting of the HostnameLookups directive. It will do a reverse DNS lookup on the IP address to find the associated hostname, and then do a forward lookup on the hostname to assure that it matches the original IP address. Only if the forward and reverse DNS are consistent and the hostname matches will access be allowed.

Whereas the following option `Require forward-dns` explicitly mentions that it is for use when the IP doesn't actually reverse to the hostname, such as situations like DDNS.

Here is the generated config for the reverse proxy (from `var/storage/chroot-reverseproxy/usr/apache/conf/something.conf`

<VirtualHost 1.2.3.4:443>
 ServerName my.server.com
 SSLProxyEngine On
 SSLEngine On
 SSLCertificateFile /usr/apache/conf/ssl/REF_CaHos.pem
 SSLCACertificateFile /usr/apache/conf/ssl/REF_CaHos.CAs
 SSLCertificateKeyFile /usr/apache/conf/ssl/REF_CaHos.key
 ProxyPreserveHost On
 RequestHeader set X-Forwarded-Proto https
 DocumentRoot /var/www/REF_RevFroG
 SetEnv proxy-initial-not-pooled
 <Proxy balancer://0e9f56dedc1c6a43ee0c263a6d1b336b>
   BalancerMember https://192.168.20.230 status=-SE timeout=300
 </Proxy>
 <Location "/">
   SetEnv proxy-aside-c
   ProxyPass "balancer://0e9f56dedc1c6a43ee0c263a6d1b336b/" lbmethod=bybusyness
   ProxyPassReverse "https://192.168.20.230:443/"
   ProxyPassReverse "https://192.168.20.230/"
   SetOutputFilter DEFLATE
   <RequireAll>
     <RequireAny>
       Require host my.host.name
       Require host another.host.name
       Require ip 192.168.20.0/24
       Require ip 192.168.10.28
     </RequireAny>
   </RequireAll>
 </Location>
</VirtualHost>

Something about how this stuff was previously established in 9.3 has changed. Either a change in how UTM9 writes the config, or a change in how Apache interprets it...

Does anyone know of a way to work around this? Such as the ability for the configured apache conf to use `Require forward-dns` instead of `Require host` or to have UTM-9 translate my ACL `Require host Hostname` to a `Require IP 1.2.3.4` automatically before generating the config? (I doubt the latter, as it would get stale easily).

The alternative seems to be to manually update the definitions in utm9 whenever they change, and I'd like to not go back to doing that.

With the number of errors being generated in the logs, I have a feeling this is something that was overlooked by dev/testing of Sophos. But I have no idea where to start with that, so I'm starting here.

Any help moving forward would be appreciated.