Closed araemo closed 2 years ago
From memory this breaks dns injection as it can't validate the chain if a domain is requesting dnssec validation? Thats why we overrode and set to no @Lepidopterist ring a bell?
I'm not sure what you mean by 'dns injection', lancache is still working as a cache for me. The old issues I saw for DNSSEC involved lancache fully failing if port 53 is blocked if DNSSEC is enabled?
I'd like to get more testing on this, because as it is this is a significant downgrade either in functionality (if DNSSEC is turned on, your local domain needs to be DNSSEC enabled, or if DNSSEC is turned off, DNSSEC failing domains that your upstream resolver could protect you from are now going to not be validated). Leaving the DNSSEC settings missing however just seems to ignore DNSSEC entirely at the lancache layer, neither validating nor requesting no validation, so it should work in both situations.
This issue has been automatically marked as inactive because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically closed after being inactive for 30 days. If you require further assistance please reopen the issue with more details or talk to us on discord
I am disappointed this was closed. Without the change above, anyone using lancache is unable to take advantage of DNSSEC.
With this change, while DNSSEC is not used for the domains lancache is overriding, it will work for all other domains (that have DNSSEC records, assuming your upstream server is doing DNSSEC validation properly).
Will take another look at this
This issue has been automatically marked as inactive because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically closed after being inactive for 30 days. If you require further assistance please reopen the issue with more details or talk to us on discord
I encountered an issue with the behavior of ENABLE_DNSSEC_VALIDATION = false:
When
dnssec-validation no
is set in named.conf, BIND explicitly requests that its upstream DNS server NOT do DNSSEC validation, meaning even if you upstream server is DNSSEC aware and protecting you, BIND will downgrade that protection.When
dnssec-validation yes
is set, BIND does its own validation, even if upstream is properly configured to do the validation itself. This is both wasteful in a controlled local environment, but my local DNS zones hosted by upstream are not set up for DNSSEC, so they fail validation in lancache-dns.If instead,
dnssec-validation
is omitted from named.conf, it sends normal queries only and does not explicitly request no validation from upstream. This allows BIND to play nice with upstream that is hosting a local-only (non-DNSSEC) zone, and also acting as a forwarder or recursive resolver.There's probably a cleaner way to handle this in the generate_config.sh file, but I wasn't sure the best way to handle it - I'm open to suggestions. Perhaps add a #DNSSEC# flag that gets either replaced with
dnssec-validation auto;
if it should be enabled, and removed entirely if it isn't?I have some screenshots of the wireshark parsing of the DNS queries for all 3 scenarios (when querying a record with intentionally broken DNSSEC) and the results on the client side if it would help.