Re: rndc status command hangs in bind 9.14.2
Hi Andi, > Is there something different about 9.14 defaults that I now need to include > in my config to get past this ? I am unable to reproduce this, things seem to work fine, at least on a fresh amd64 NetBSD 7.2 VM: # bin/rndc/rndc status version: BIND 9.14.2 (Stable Release) running on vm0: NetBSD amd64 7.2 NetBSD 7.2 (GENERIC.201808291900Z) boot time: Wed, 12 Jun 2019 07:08:35 GMT last configured: Wed, 12 Jun 2019 07:08:35 GMT configuration file: /etc/named.conf CPUs found: 4 worker threads: 4 UDP listeners per interface: 4 number of zones: 100 (99 automatic) debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is OFF recursive clients: 0/900/1000 tcp clients: 2/150 server is up and running What hardware platform are you experiencing this on? What is your "named -V" output? What is your build process? If you are still hitting this, please open a bug report on gitlab.isc.org, providing the answers to the questions above and any other information that may be helpful. -- Best regards, Michał Kępień ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Useful tip on nsupdate -- readline support.
Mukund Sivaraman wrote: > On Tue, Jun 11, 2019 at 10:03:30AM -0400, Warren Kumari wrote: > > > > I manually use nsupdate to make some changes to some of my zones - > > most recently I had to add a bunch of reverse DNS records. These are > > all very similar - the first octet changes, and then the target name > > changes. Unfortuniatly nsupdate doesn't support readline, This annoyed me too, so I added readline support to BIND in 2011 ish - I think it was one of my earliest contributions :-) See CHANGES 3244. You might also like my `nsvi` program. https://dotat.at/prog/nsdiff/ > * readline is GPL There are non-GPL readline clones, e.g. the BSDs have libedit which I think should work with BIND, though I can't conveniently check right now. Tony. -- f.anthony.n.finchhttp://dotat.at/ the market alone does not distribute wealth or income fairly ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Useful tip on nsupdate -- readline support.
Hey list, I believe this needs addressing from the BIND team. > * readline is GPL BIND 9 supports compilation with libedit which is 99% drop-in replacement since 2015 (017cbd44). The well-established open-source distributions are well aware of the readline firm stand on the GPL vs LGPL for the downstream users of the library. > libcap (POSIX capablities) is GPL similarly. No, it’s really not. libcap is 3-clause BSD with following exception added: > ALTERNATIVELY, this product may be distributed under the terms of the > GNU General Public License (v2.0 - see below), in which case the > provisions of the GNU GPL are required INSTEAD OF the above > restrictions. (This clause is necessary due to a potential conflict > between the GNU GPL and the restrictions contained in a BSD-style > copyright.) e.g. the primary license is 3-clause BSD, but in case you need to use libcap in GNU GPL project, you are allowed to do so without considering potential conflicts between 3-clause BSD and GPL 2.0 Cheers, Ondrej -- Ondřej Surý ond...@isc.org > On 11 Jun 2019, at 16:58, Mukund Sivaraman wrote: > > * readline is GPL, and so you'll link your code to GPL if you link to it > (which can be esp. bad for you if you modify libisc, libdns, > etc. also). It's best to either remove readline from such build > environments (libedit may be a suitable drop-in replacement), or > configure without it, or patch out the code. > > There is some interesting GPL license enforcement history with readline: > > > https://en.wikipedia.org/wiki/GNU_Readline#Choice_of_the_GPL_as_GNU_Readline's_license > https://gitlab.com/gnu-clisp/clisp/blob/master/doc/Why-CLISP-is-under-GPL > > * libcap (POSIX capablities) is GPL similarly. An alternative is > libcap-ng which is LGPLv2+, but it has a different API. > > I think these are the only two libraries that are copyleft vs. BIND's > ISC (before) and MPL2 (now) licenses, and because they're GPL, your work > will be covered by GPL if you link against them. > > This is usually not bad for the general public (and good for free > software), but if you're a commercial re-distributor of BIND and are > linking to GPL, good luck. I'm sure you'll even miss seeing this > thread. :) > > Mukund > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Useful tip on nsupdate -- readline support.
Hi Ondrej On Wed, Jun 12, 2019 at 04:08:20PM +0200, Ondřej Surý wrote: > Hey list, > > I believe this needs addressing from the BIND team. > > > * readline is GPL > > BIND 9 supports compilation with libedit which is 99% drop-in replacement > since 2015 (017cbd44). I had mentioned libedit in my email too. However, readline is more likely to be found in a Linux distribution (that an appliance bases off) unless the packager knows about the GPL linkage and includes libedit as a dependency. While BIND is MPL licensed, linkage to GPL makes the overall work (of that program) be covered by GPL. So even supporting readline adds in additional restrictions past the MPL implicitly for the covered programs (and arguably modified BIND library code). Perhaps you may consider a warning about less permissive dependencies than MPL in the documentation or at configure time, so BIND customers are aware of it. (My comment was not based on just a random observation that it could happen, but I'm not at liberty to discuss it.) > The well-established open-source distributions are well aware of the readline > firm stand on the GPL vs LGPL for the downstream users of the library. The comment was directed at commercial (closed-source) re-distributors of BIND such as appliance vendors, so they can check their builds. > > libcap (POSIX capablities) is GPL similarly. > > > No, it’s really not. libcap is 3-clause BSD with following exception added: > > > ALTERNATIVELY, this product may be distributed under the terms of the > > GNU General Public License (v2.0 - see below), in which case the > > provisions of the GNU GPL are required INSTEAD OF the above > > restrictions. (This clause is necessary due to a potential conflict > > between the GNU GPL and the restrictions contained in a BSD-style > > copyright.) > > e.g. the primary license is 3-clause BSD, but in case you need to use libcap > in GNU GPL project, you are allowed to do so without considering potential > conflicts between 3-clause BSD and GPL 2.0 I was not aware of the BSD option. Fedora lists it as a GPL package. That clears linking vs. libcap. BTW, if this revelation was somehow problematic, then I take it back and will go mind my own business. Mukund ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc status command hangs in bind 9.14.2
On Wed, 12 Jun 2019, Micha? K?pie? wrote: Hi Andi, Is there something different about 9.14 defaults that I now need to include in my config to get past this ? I am unable to reproduce this, things seem to work fine, at least on a fresh amd64 NetBSD 7.2 VM: # bin/rndc/rndc status version: BIND 9.14.2 (Stable Release) running on vm0: NetBSD amd64 7.2 NetBSD 7.2 (GENERIC.201808291900Z) boot time: Wed, 12 Jun 2019 07:08:35 GMT last configured: Wed, 12 Jun 2019 07:08:35 GMT configuration file: /etc/named.conf CPUs found: 4 worker threads: 4 UDP listeners per interface: 4 number of zones: 100 (99 automatic) debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is OFF recursive clients: 0/900/1000 tcp clients: 2/150 server is up and running What hardware platform are you experiencing this on? What is your "named -V" output? What is your build process? If you are still hitting this, please open a bug report on gitlab.isc.org, providing the answers to the questions above and any other information that may be helpful. I filed https://gitlab.isc.org/isc-projects/bind9/issues/1085. The build process is: - cd /opt/pkgsrc/bind914 - cvs update - make update In other words, I'm using the netbsd 7.2 pkgsrc source distribution and build framework. I did not build bind 9.14.2 from directly downloaded sources myself. In particular, it seems that the netbsd 7.2 pkgsrc build applies around 37 patch files. I think the named -V and log excerpts answer all the other questions you asked above. I'm very sorry to see that the issue interface completely munged my formatting :-( Thank you for your assistance ! Andi.. -- Best regards, Micha? K?pie? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
dnssec-validation auto vs yes
Hi,
The default BIND9 installation for CentOS7 has dnssec-validation set to "yes"
and it also includes managed-keys as well. Do those managed-keys get updated
automatically? It is not clear from reading
https://ftp.isc.org/isc/dnssec-guide/html/dnssec-guide.html#dnssec-validation-explained
that these managed-keys will get updated automatically if dnssec-validation is
not set to "auto".
[root@centos-linux ~]# named -vBIND 9.9.4-RedHat-9.9.4-73.el7_6 (Extended
Support Version)[root@centos-linux ~]# grep named.root.key
/etc/named.confinclude "/etc/named.root.key";[root@centos-linux ~]# cat
/etc/named.root.keymanaged-keys { # ROOT KEYS: See
https://data.iana.org/root-anchors/root-anchors.xml # for current trust
anchor information. # # This key (19036) is to be phased out
starting in 2017. It will # remain in the root zone for some time after
its successor key # has been added. It will remain this file until it is
removed from # the root zone. . initial-key 257 3 8
"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=";
# This key (20326) is to be published in the root zone in 2017.
# Servers which were already using the old key should roll to the # new
# one seamlessly. Servers being set up for the first time # can use
either of the keys in this file to verify the root keys # for the first
time; thereafter the keys in the zone will be # trusted and maintained
automatically. . initial-key 257 3 8
"AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN R1AkUTV74bU=";};
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Strange DNS problem
Thanks > On 13 Jun 2019, at 1:17 am, Rune Hassel wrote: > > Hi! > > This problem should now be completely resolved. > > Regards > Rune Hassel > > > -Original Message- > From: Mark Andrews > Sent: Tuesday, June 11, 2019 6:08 AM > To: Jukka Pakkanen > Cc: Stephane Bortzmeyer ; c...@cam.ac.uk; > bind-us...@isc.org; hostmas...@datatower.fi > Subject: Re: Strange DNS problem > > You solve that by complaining to the operators of the servers that their DNS > servers mis-implement DNS COOKIE (RFC 7873) and could they request a fix from > their DNS vendor. > > Not that they make things easy to contact them. No email in whois. Just a > PO box and a phone number and I don’t intend to call it from here. > > name...: DATATOWER AB > register number: 0708753-2 > address: PB 144 > address: 67101 > address: KOKKOLA > country: Finland > phone..: +358 20 7789 564 > holder email...: > > https://datatower.fi is just a login form with a bad CERT (for > mail.datatower.fi). > > Mark > >> On 11 Jun 2019, at 4:36 am, Jukka Pakkanen wrote: >> >> Yeah, another advertising company turned to an ISP... >> >> Solved *our* problem now by including the suggested server clause for both >> of their broken servers, to our servers. Of course does not solve the real >> problem, the broken servers of theirs. >> >> Thanks for help. >> >> Jukka >> >> -Original Message- >> From: Stephane Bortzmeyer >> Sent: 10. kesäkuuta 2019 20:01 >> To: Jukka Pakkanen >> Cc: c...@cam.ac.uk; bind-us...@isc.org >> Subject: Re: Strange DNS problem >> >> On Mon, Jun 10, 2019 at 05:43:02PM +, Jukka Pakkanen >> wrote a message of 58 lines which said: >> >>> Then, unfortunately our nameservers won't resolve ns.kpk.fi either. >> >> Same authoritative name server, same problem. See my email. >> >> % dig @ns.datatower.fi. NS kpk.fi. >> >> ;; Warning: Client COOKIE mismatch >> >> ___ >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >> unsubscribe from this list >> >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-validation auto vs yes
On Wed, Jun 12, 2019 at 11:40:27PM +, Shawn Zhou via bind-users wrote: > The default BIND9 installation for CentOS7 has dnssec-validation set to > "yes" and it also includes managed-keys as well. Do those managed-keys > get updated automatically? Yes, if the "managed-keys" statement is in named.conf (or included in it via an "include" statement) then the keys will be updated automatically. Based on what you copy-pasted, that appears to be the case. "dnssec-validation auto" causes named to use its built-in key for the root zone, so you don't have to put your own "managed-keys" statement into named.conf, but otherwise it's the same as "dnssec-validation yes". (BTW, a note in passing: we're changing the command from "managed-keys" to "dnssec-keys" over the next few years. The new syntax will be available in BIND 9.15.1, which should be out next week; the old syntax will be phased out later.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-validation auto vs yes
Thanks Even. Sounds like "dnssec-validation auto" is a more future-proof option for what want it. I will use that instead. On Wednesday, June 12, 2019, 5:25:51 PM PDT, Evan Hunt wrote: On Wed, Jun 12, 2019 at 11:40:27PM +, Shawn Zhou via bind-users wrote: > The default BIND9 installation for CentOS7 has dnssec-validation set to > "yes" and it also includes managed-keys as well. Do those managed-keys > get updated automatically? Yes, if the "managed-keys" statement is in named.conf (or included in it via an "include" statement) then the keys will be updated automatically. Based on what you copy-pasted, that appears to be the case. "dnssec-validation auto" causes named to use its built-in key for the root zone, so you don't have to put your own "managed-keys" statement into named.conf, but otherwise it's the same as "dnssec-validation yes". (BTW, a note in passing: we're changing the command from "managed-keys" to "dnssec-keys" over the next few years. The new syntax will be available in BIND 9.15.1, which should be out next week; the old syntax will be phased out later.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
