Add variable to disable Bind DNSSEC validation

[janfux]

When UPSTREAM_DNS is set to a DNS server that does not support DNSSEC or does not imlement it correctly, bind reports SERVFAIL on DNS requests that are forwarded to UPSTREAM_DNS. Disabling dnssec validation by setting dnssec_validation to no in /etc/bind/named.conf.options solves this. Adding a new variable to bootstrap.sh to change this setting on user request. Tested with Windows Server 2012 R2 and 2016 DNS and dnsmasq on linux. Default google dns 8.8.8.8 supports dnssec. Reproduce by pointing UPSTREAM_DNS at non-dnssec server and running "nslookup ". Observe Servfail message in container logs.

[jamesyale]

Given that this breaks a lot of DNS resolution, I wonder if the default should be to disable dnssec_validation and have the option to enable it?

[janfux]

Most BIND9 installations default to setting dnssec_validation to "auto". I experienced this breaking my setup when a Microsoft DNS Server was used as dns forwarder. Haven't tested with other implementations but found disabling dnssec_validation works for me (tm). I think breaking the default behavior is probably a bit strong, given that DNSSEC implmentation rate is probably going to go up. But being able to disable it if necessary is nice to have.

[jamesyale]

I was approaching this from the POV of a user who picks up the https://github.com/steamcache/docker-compose and expects it to work out of the box.

Perhaps then a PR against the docker-compose repo is appropriate, making the default there to set this variable. This makes the default choice a visible thing, rather than having the default of queries quietly failing against some forwarders unless you check the logs?

[janfux]

Yeah, that's probably right, new users could be frustrated by this default behavior. Then again, more testing against common DNS implementations is necessary, as the default - Google's 8.8.8.8 - works out of the box. We needed Active Directory authentication alongside, so we opted for our MS DNS servers. It would be interesting to see how many of the common public DNS work and which implementations raise erros. I do not have the time to test right now, but if a majority of DNS servers in standard configuration errors out, it might be better to just set a default.

[JasonRivers]

Hi @janfux Sorry this is taking a while.

Could you reverse DNSSec in your PR so that it's disabled by default with the option to enable it? having DNSSec enabled really does appear to be breaking more than expected.

Once that's done we shouldn't have a problem merging this in, We've just had a chat on Discord about this issue and what was noticed at StratLAN over the last weekend was that turning DNSSec off fixed all of the problems that they were seeing.

J

[VibroAxe]

@janfux I've rolled a new PR ( #63 ) for this with your commits and some adjustments to tweak the design to a disable by default model. I didn't want to commit directly to your master branch in case you were using this specific functionality somewhere (it removes the disable variable in favour of an enable)

Thanks for the awesome work on this already, if we'd found this at stratlan (my fault for not looking) it might have saved us quite a bit of debugging!

[janfux]

Thanks @VibroAxe for rolling this! I didn't find the time to clean this up, it was quite messy :) Wanted to do that but time... Again, thanks for getting it merged 👍