Re: [arch-general] BIND, systemd-resolved, and nscd
On 2018-09-19T11:22:16, frede...@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 signature.asc Description: PGP signature
Re: [arch-general] BIND, systemd-resolved, and nscd
On 2018-09-13T12:31:28, frede...@ofb.net 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: > > ftp://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/Bv9ARM.ch06.html#Configuration_File_Grammar > > 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: > > https://superuser.com/questions/1349213/how-to-debug-local-named-with-broken-dnssec > > 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) > > Frederick 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. Matt Pallissard signature.asc Description: PGP signature
Re: [arch-general] BIND, systemd-resolved, and nscd
> 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; Matt Pallissard signature.asc Description: PGP signature
[arch-general] ISC bind 9.11 and dyndb-ldap
Has anyone successfully used LDAP as a dynamic back-end for bind 9.11? Unless I'm reading the release notes/new features pages incorrectly the bind-dyndb-ldap plugin has been rolled into ISC's official release and I shouldn't have to mess around with patching/building it from source. Yet I get the following errors upon startup; named[9937]: loading configuration from '/etc/named.conf' named[9937]: /etc/named.conf:23: unknown option 'dynamic-db' named[9937]: loading configuration: failure named[9937]: exiting (due to fatal error) systemd[1]: named.service: Main process exited, code=exited, status=1/FAILURE Any advice would be greatly appreciated. Sources. https://www.isc.org/bind-9-11-new-features/ https://kb.isc.org/article/AA-01432/81/BIND-9.11.0-Release-Notes.html Matt Pallissard
