DNSSEC Bug in latest Windows Client

StefanS

Hi there,
We are currently testing the openvpnas server in the last version.
We noticed a bug in the openvpn Windows client. We have secured our windows domain with DNSSEC.
Once GPO Configuration -> Name Resolution Policy -> Enable DNSSEC is enabled, DNS name resolution will stop working on the Client.
Maybe the UDP packets are too big because they contain the DNSSEC key.
Other VPN clients (IPSec) do not have these problems. We use DNS split.

Is this problem known and when can one expect a solution?
Thanks for any help.
Stefan

The Johan

I use a VPN server with DNS SEC on the domain and that works fine. So, not exactly a known issue. Maybe there's something more going on here. Does the domain still resolve when you do it on the command line with ping or nslookup, and does the open source client exhibit the same problem?

StefanS

Hi, thanks for your quick reply.
DNSSEC itself in the domain is not the problem.
Once the Windows client is instructed by GPO (Group Policy) e.g. validating mydomain.local via DNSSEC,
does not work on the client a DNS Resolution.

Other VPN clients have no problem with this active GPO.
Once this GPO is disabled, the DNS resolution works fine on the openvpnclient.
So there is a clear link between active DNSSEC validation on the Windows local DNS client (via GPO) and the current openvpn client.
I know routers and also network clients, such as, VPN client have problems with too large UDP DNS packets.

>>Does the domain still resolve when you do it on the command line with ping or nslookup
No, here too there are these problems

>>and does the open source client exhibit the same problem
I will test and report.

StefanS

novaflash,
when can one expect a solution here?
Thanks for any help.

The Johan

To be honest I think this is a very specific problem related to the Windows DNS server, it will have to be tested.

From experience, DNS records with DNSSEC work perfectly fine here. Remember, DNS SEC is only an addition of top of normal DNS. So the normal DNS record is still there. I think the requirement to force DNS SEC may be what is causing the issue, but I don't know.

Don't expect a solution anytime soon. Currently I feel the problem is due to something unique in your situation.

The Johan

I just realized that most likely the problem is that you are configuring your Windows client systems to always force the use of DNS SEC for resolving names in the adatum.com zone. But if the zone does not have DNS SEC or the DNS server configured on the Windows client system can't do DNS SEC, then it will just fail because of that. Nothing to do with connect client then as far as I can see.