20 Sep
2018
20 Sep
'18
3:37 a.m.
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