On 2018-09-19T11:22:16, frederik@ofb.net wrote:
Well, prior to the recent BIND releease, the default had been "yes" - which means "no" for me.
... 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-validation yes; #does validate (requires a trusted-keys or managed-keys statement, which you DO NOT have in your example)
I think you just answered your own question. Except perhaps that the word "requires" is a bit misleading, because when you don't have that statement then 'named' still starts up and responds to queries, it just doesn't do DNSSEC validation. So 'named' itself does not "require" it.
Fair point, maybe raise that on the ISC list.
Your first email wondered if I didn't want "no" instead of "yes" and I was explaining that they are the same for my configuration, which is based on the default named.conf that ships with bind, which doesn't have a trusted-keys or managed-keys statement. In other words, they are also the same for the default configuration. As I explained, "yes" was the default validation setting and I was trying to restore the old behavior, which doesn't do validation. I was wondering why you had asked this question, if you had some kind of expert knowledge that I didn't have - but it looks like we are learning about this together, since you are referring to the URL I provided.
Yea I ran into this as well. I just disabled dnssec locally and relied on my forwarders to handle it. Your question prompted me to look into it a bit more.
The purpose of my original post was to ask whether this sort of change in the defaults of an important package belongs in the Arch news page (https://www.archlinux.org/news/), but I haven't received an answer yet. I'm open to advice on question-asking or if this is the right forum or whatever.
I could be wrong bit I don't think so, it's an upstream change of a default value.
Matt Pallissard