On 2018-09-13T12:31:28, email@example.com wrote:
On Thu, Sep 13, 2018 at 06:49:45AM -0700, Pallissard, Matthew wrote:
I had to add "dnssec-validation yes;" to /etc/named.conf. I have a
Are you sure you didn't want these values?
dnssec-enable no; dnssec-validation no;
Well, prior to the recent BIND releease, the default had been "yes" - which means "no" for me. I just wanted to make it behave the same way as it had before. I don't know if there's a difference between that and the options you suggested:
If set to auto, DNSSEC validation is enabled, and a default trust anchor for the DNS root zone is used. If set to yes, DNSSEC validation is enabled, but a trust anchor must be manually configured using a trusted-keys or managed-keys statement. The default is yes.
Here's my SU question BTW:
Matthew, do you know more about this stuff or were you just as confused as I was by the "yes means no" syntax? I didn't necessarily want to get into that in this thread, although it could potentially be something for us to complain to the BIND maintainers about. (viz., people thinking they had enabled dnssec-validation when in fact they hadn't)
A few things.
1. Google's public DNS servers are DNSSEC validating forwarders, your router evidently is not. 2. I'm not sure what you mean by the yes-means-no syntax. The URL that you provided seems pretty cut and dry.
dnssec-enable yes; # returns dnssec resource records dnssec-enable nol # does not, validation cannot be performed dnssec-validation no; #does not validate dnssec-validation yes; #does validate (requires a trusted-keys or managed-keys statement, which you DO NOT have in your example) dnssec-validation autol #does validate (uses trusted/manged-keys blocks or the trust anchor compiled into named)
TL;DR If you want to 'make it behave the same way as it had before', it sounds like you need to disable DNSSEC validation. If you want to make it honour DNSSEC set dnssec-validation to 'auto' or 'yes' with the related keys statement.