Re: New BIND releases are available: 9.18.28, 9.20.0
Brian, > We use the COPR to install BIND on our servers, and I wanted to mention that > it looks like in both the isc/bind and isc/bind-esv repos, the build of the > package “isc-bind-bind” failed for version 9.18.28-1.1 in (as far as I can > tell) only the EPEL 7 repo in Build 7776636. Could someone look at that? > We’re on RHEL 8 and 9 for our BIND servers and it looks like the EPEL 8 and 9 > versions build successfully, but I want to make sure that I’m not missing > something. Thanks! You are correct: only EL7 builds failed; EL8 and EL9 builds are fine. The reason for this is that Copr's epel-7-x86_64 chroot uses CentOS 7 repositories and these are no longer available as that system has reached End-of-Life last month: https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux/rhel-7-end-of-maintenance We will shortly disable epel-7-x86_64 builds in our Copr repositories to prevent confusion in the future. -- Best regards, Michał Kępień -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Question about ISC BIND COPR repositories for 9.16->9.18 ESV transition
We have just upgraded the "bind-esv" repository from BIND 9.16.50 to BIND 9.18.27, i.e. the same version as in the "bind" repository. We will try to keep everyone informed about further major version upgrades in our package repositories in the coming months. -- Best regards, Michał Kępień -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Question about ISC BIND COPR repositories for 9.16->9.18 ESV transition
> Have you considered scheduling the change in version published in each COPR > repository so it doe /not/ coincide with the release of a new version of > BIND? > > I have some hosts tied to the COPR for BIND-ESV, and some tied to BIND. I > hit a stumbling block during the last "roll over" event, and it took me a a > bit to figure out if it was due to the switch of BIND-ESV from 9.11 - > 9.16 > in the repository, or the switch from 9.16.x -> 9.16.y in the code-release. > > If we could have the version published in the BIND-ESV repository advance to > the same version which was most recently published in BIND repository (i.e. > ship 9.18.x in BIND, a couple of weeks later roll BIND-ESV to 9.18.x and > BIND to 9.20.x, and a couple of weeks later release 9.18.y and 9.20.y), then > problems with the COPR "roll over" would be a little more obvious. Sure, that's something to consider, thanks. The Copr packages have always been provided on a best-effort basis. We try to do the right thing for the majority of users, but it is clear that there is no "one size fits all" upgrade strategy. The packaging recipes for all our RPMs are publicly available [1], plus every Copr build results in the creation of an SRPM that can be reused/tweaked to produce RPMs differently in case anyone needs that. [1] https://gitlab.isc.org/isc-packages/rpms/ -- Best regards, Michał Kępień -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Question about ISC BIND COPR repositories for 9.16->9.18 ESV transition
Hi Brian, > We’ve been using the ISC BIND 9 COPR repositories at > https://copr.fedorainfracloud.org/coprs/isc/ for a few years now, but I had a > question – is there a planned date to update the “bind-esv” channel to > provide BIND 9.18 rather than BIND 9.16? Since 9.16 is now EOL we’ve > switched to using the stable channel to get 9.18, but I just want to make > sure that we switch back to the ESV channel once it provides 9.18 so we don’t > accidentally switch to a new version once 9.20 becomes the new stable release. If you have been using our repositories for a few years indeed, you might remember that such a switch already happened about two years ago, when "bind-esv" moved from 9.11 to 9.16 (and the other two repositories were "rolled over" accordingly). While I don't have a specific date for you, we plan to do such a "rollover" again when BIND 9.20.1 or 9.20.2 gets released, i.e. in about 2-3 months from now. We will definitely roll all three repositories at the same time, i.e.: - "bind-esv" will move from 9.16 to 9.18, - "bind" will move from 9.18 to 9.20, - "bind-dev" will move from 9.19/9.20 to 9.21. If you would like to see how things turned out in the past in a similar situation, please consult the lists of past builds in all our Copr repositories: - https://copr.fedorainfracloud.org/coprs/isc/bind-esv/builds/ - https://copr.fedorainfracloud.org/coprs/isc/bind/builds/ - https://copr.fedorainfracloud.org/coprs/isc/bind-dev/builds/ Hope this helps, -- Best regards, Michał Kępień -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND >= 9.18, jemalloc and EL7
Hi Anand, > I note that none of the official ISC BIND > packages for EL7 and EL8 link against jemalloc, even though the > documentation recommends it. Could you please double check? This is what I get in a fresh CentOS 7 Docker container: # yum install yum-plugin-copr # yum copr enable isc/bind # yum install epel-release # yum install isc-bind # scl enable isc-bind -- bash # named -v BIND 9.18.6 (Stable Release) # ldd $(command -v named) | grep jemalloc libjemalloc.so.1 => /lib64/libjemalloc.so.1 (0x7f1a9d18) I also checked on RHEL 8 and the result is the same. Copr build logs for BIND 9.18.6 also confirm that named is linked against jemalloc: https://download.copr.fedorainfracloud.org/results/isc/bind/epel-7-x86_64/04742380-isc-bind-bind/builder-live.log.gz https://download.copr.fedorainfracloud.org/results/isc/bind/epel-8-x86_64/04742380-isc-bind-bind/builder-live.log.gz -- Best regards, Michał Kępień -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind v9_18_x compile
> Why command "autoreconf -fi" can only execute in git path? I assume you are referring to the hardcoded use of "git rev-parse" that causes error messages to be printed out if you run "autoreconf -fi" from outside of a Git repository (e.g. from a release tarball). Note that this does NOT cause the build to fail. The binaries built using Autoconf files prepared that way will just have the "srcid" string set to an empty value: $ bin/named/named -v BIND 9.18.4 (Stable Release) (If you really need this to work, I guess you could tweak the value of the PACKAGE_SRCID preprocessor macro in the "configure" file generated by "autoreconf -fi" run from outside a Git repository.) This changed with the move to Automake in BIND 9.17. Context is here: https://gitlab.isc.org/isc-projects/bind9/-/commit/ed212e9c632fe4bc647f12398aadacd8dcf59f15 TL;DR: what we did in the first Automake-based build system was confusing and not perfect, so we replaced it with something that is less confusing, yet still not perfect. -- Best regards, Michał Kępień -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unable to start Bind on a fresh RHEL 8.6 system with enforcing SELinux
Søren, > Oh.. gosh.. You're right.. It works! - It wasn't 100% clear to me that this > was the only correct way to install bind from your repo. We have seen users run into this exact same issue before, so I have now made this particular bit of information more prominent on the "landing pages" of all BIND 9 Copr repositories. > Thanks a lot. Glad I could help. Thank you for your feedback. -- Best regards, Michał Kępień -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unable to start Bind on a fresh RHEL 8.6 system with enforcing SELinux
Søren, > On a fresh install the selinux context are 'var_t', and if I changed it to > 'named_var_run_t' it works! This is the suspicious part for me. How did you install the packages? The only supported way is the one that is documented [1]: dnf install isc-bind That pulls in the SCL metapackage which sets up SELinux file context equivalency rules [2] and relieves you from having to apply any sort of manual SELinux context tweaks. My guess is that you installed one of the "individual" packages directly, e.g. "dnf install isc-bind-bind". Please be aware that if the SELinux contexts are not set up by the metapackage, you may run into other similar issues in the future. [1] https://copr.fedorainfracloud.org/coprs/isc/bind/ [2] https://gitlab.isc.org/isc-packages/rpms/isc-bind/-/blob/7b525a31c2bd9b51c10b2ed2aca8d5244221f359/isc-bind.spec#L77 -- Best regards, Michał Kępień -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: "doth" test failing in 9.18.3
Hi Josef, > I'm in the process of upgrading openSUSE Tumbleweed to bind 9.18.3 and in > doing so, also run the test suite. However, it fails in step > FAIL: doth > > The log file says > I:doth:testing incoming XoT functionality (from the first secondary) (2) > I:doth:timed out waiting for zone transfer > > Is there anything I am missing? I don't think you are missing anything. The symptoms you described look very similar to this issue: https://gitlab.isc.org/isc-projects/bind9/-/issues/3337 We are working on addressing the above, though feel free to open another GitLab issue, attaching the entire contents of bin/tests/system/doth/ after the "doth" system test fails. We could then make sure it is not a different problem. Thanks, -- Best regards, Michał Kępień -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.16.28 vrs. 9.18.2 (on freebsd) resolving foryoudecor.com
> we observed a strange behaviour for the domain foryoudecor.com, > when trying to resolve it using bind 9.18.2, using > > dig -t mx foryoudecor.com > > The bind log for 9.18.2 says: > > May 11 12:00:14 ns named[96774]: fetch: foryoudecor.com/MX > May 11 12:00:14 ns named[96774]: DNS format error from 61.129.70.40#53 > resolving foryoudecor.com/MX for 193.105.105.1#27259: server sent FORMERR > May 11 12:00:14 ns named[96774]: client @0x803bdcd60 193.105.105.1#27259 > (foryoudecor.com): query failed (FORMERR) for foryoudecor.com/IN/MX at > query.c:7657 > > so the domain was not resolvable. > > bind 9.16.28 resolves the MX for this domain. The servers authoritative for foryoudecor.com return broken responses (FORMERR + OPT) to EDNS queries. This is a violation of RFC 6891 section 7. BIND 9.18+ is more strict in processing such responses than the older versions. This is pointed out in the release notes for BIND 9.18.0: [1] > - Previously, ``named`` accepted FORMERR responses both with and without > an OPT record, as an indication that a given server did not support > EDNS. To implement full compliance with :rfc:`6891`, only FORMERR > responses without an OPT record are now accepted. This intentionally > breaks communication with servers that do not support EDNS and that > incorrectly echo back the query message with the RCODE field set to > FORMERR and the QR bit set to 1. :gl:`#2249` If you need a workaround for this particular domain, use the "server" clause in named.conf to disable EDNS for its authoritative servers. [1] https://bind9.readthedocs.io/en/v9_18_0/notes.html#notes-for-bind-9-18-0 -- Best regards, Michał Kępień -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [URL Verdict: Neutral][Non-DoD Source] Re: Attempting to configure an ISC BIND repository on Red Hat Linux 7.9
> Hello--sorry it took so long to respond. And I apologize for the length of > this email. > > Yes, the curl command returns an xml file. I included an excerpt from the > output: > > "About to connect() to download.copr.fedorainfracloud.org port 443 (#0) > * Trying 13.32.153.64... > * Connected to download.copr.fedorainfracloud.org (13.32.153.64) port 443 (#0) > * Initializing NSS with certpath: sql:/etc/pki/nssdb > * skipping SSL peer certificate verification > * SSL connection using TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 > * Server certificate: > * subject: CN=download.copr.fedorainfracloud.org > * start date: Nov 30 00:00:00 2021 GMT > * expire date: May 11 19:03:32 2022 GMT > * common name: download.copr.fedorainfracloud.org > * issuer: CN=DoD WCF Signing CA 2,OU=WCF PKI,OU=DoD,O=U.S. > Government,C=US This really looks like on-path TLS interception to me - note the certificate issuer in your output. This is certainly not the TLS certificate I see for 13.32.153.64 from my vantage point (also note the different cipher suite chosen, despite the same, stock RHEL 7 curl version being used): * About to connect() to download.copr.fedorainfracloud.org port 443 (#0) * Trying 13.32.153.64... * Connected to download.copr.fedorainfracloud.org (13.32.153.64) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * skipping SSL peer certificate verification * SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 * Server certificate: * subject: CN=download.copr.fedorainfracloud.org * start date: Nov 30 00:00:00 2021 GMT * expire date: Dec 28 23:59:59 2022 GMT * common name: download.copr.fedorainfracloud.org * issuer: CN=Amazon,OU=Server CA 1B,O=Amazon,C=US Given this, I am pretty certain that whatever transparent proxy intercepts the HTTPS requests which yum sends from your host does not like *something* about them and returns HTTP 503 Service Unavailable errors. I am afraid you will have to figure out what that "something" is yourself, though, because it looks like an environment-specific issue to me at this point and not a problem with Copr itself. Good luck! -- Best regards, Michał Kępień -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Attempting to configure an ISC BIND repository on Red Hat Linux 7.9
> Dnf is not available. Therefore using yum > > Linux Red Hat 7.9 virtual machine on VMware, has internet connectivity > > Set up local repository in > /etc/yum.repos.d/download.copr.fedorainfracloud.org_results_isc_bind_epel-8-_.repo: Is something (e.g. policy) forcing you to set this repository up manually? IMHO it would have been simpler with the "copr" yum plugin. CentOS 7 allows installing it via "yum install yum-plugin-copr", though RHEL 7 seems to not have heard of a "yum-plugin-copr" package, so you have to prod it a bit (similarly for EPEL, which you are going to need for libnghttp2 if you plan to use the stable "bind" repository, which currently contains BIND 9.18): # yum install http://mirror.centos.org/centos/7/os/x86_64/Packages/yum-plugin-copr-1.1.31-54.el7_8.noarch.rpm # yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm # yum copr enable isc/bind # yum install isc-bind (I just tested these commands on a fresh RHEL 7 Docker image.) > now receiving error: > "https://download.copr.fedorainfracloud.org/results/isc/bind/epel-8-x86_64/repodata/repomd.xml: > [Errno 14] HTTPS Error 503 - Service Unavailable" for each of the sites in > isc: https:// > download.copr.fedorainfracloud.org/results/isc/bind/epel-8-x86_64/(i.e. > repeats 10 x) > > curl -k > https://download.copr.fedorainfracloud.org/results/isc/bind/epel-8-x86_64/ > shows web page content so the connection is good And does: curl -v -k https://download.copr.fedorainfracloud.org/results/isc/bind/epel-7-x86_64/repodata/repomd.xml output an XML file? What IP is it trying to connect to? Are you able to verify that yum tries to reach the same IP when you try to install packages? > internet search indicates a possible issue with the target site (which I > doubt) It is certainly within the realm of possibility. Copr is backed by a CDN, so I can imagine a situation in which the specific host you are connecting to from your vantage point is dysfunctional in some way while others are working just fine. -- Best regards, Michał Kępień -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 9.11 -> 9.16 via COPR
Hi John, > We're happily running the BIND 9.11 ESV on CentOS 7 by way of: > isc-bind-esv/x86_64 Copr repo for bind-esv owned by isc > > The roadmap I recall indicates 9.11 will move to "security only" updates at > the end of 2020, at which time 9.16 is slated to become the ESV. Correct. > I figure it > is time for me to get a 9.16 instance running and see what will be involved > in making it work for us. Good call :) > My questions are two: > A) How will the upcoming change in ESV-designation appear to users of the > COPR packages? Will there come a time when the repository/package > "isc-bind-esv" will just deliver 9.16 rather than 9.11? This is what we currently _plan_ to do, but I would not like to make any particular _promises_ at this point yet. Things should become more definite around the end of the year. > B) If I have a host currently using "isc-bind-esv/x86_64", and I want it > instead to use "isc-bind/x86_64", what's the suggested process? Do I "yum > remove", replace the "bind-esv" repository with "bind", and "yum install"? > Is it simpler than that? I would personally just add the "bind" repository and run "yum update", there is no need for a "yum remove" here. Unless your configuration contains statements which prevent BIND 9.16 from starting up, this may be all you need to do to perform the upgrade and it should be fairly seamless (though prior testing is of course strongly recommended when updating across major versions in a production environment). The most recent BIND release in the "bind-esv" repository should never be newer than the most recent BIND release in the "bind" repository. Hope this helps. Feel free to let me know if you have any further questions on this subject. -- Best regards, Michał Kępień ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RPZ wildcard domain passthru not effective in BIND 9.11.21
> RPZ wildcard domain whitelist (passthru) doesn't seem to work as it should > be. > > I have noticed that the last workable version is BIND 9.11.6-P1. I have > tested the same configurations with versions 9.11.8, 9.11.19 and 9.11.21, > and all produce the same issue. > > Has anyone experienced a similar issue here? or have I > mis-configured something? Looks like a match for GL #1619: https://gitlab.isc.org/isc-projects/bind9/-/issues/1619 This will fixed in BIND 9.11.22, which is due in a few weeks. If you urgently need a patch against BIND 9.11.21, try this one: https://gitlab.isc.org/isc-projects/bind9/-/commit/33ae88f08dabea846aee3be3af8a515fd9774ee1.diff Sorry about the trouble! -- Best regards, Michał Kępień ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Log rolling stopped working in 9.11.12 ?
Hi John,
> Thank you for the obvious suggestion, Mark. It hadn't occurred to me that a
> yum update might have clobbered my existing permissions.
>
> Sure enough, there it was -
> 755 root:root /var/opt/isc/isc-bind/log/
> Everything in that directory was still -
> 644 named:named
> but the user "named" was unable to create anything new
>
> Looking at my installation notes from earlier this year, I found the
> following:
> > Adjust the log directory permissions. chown named:named
> > /var/opt/isc/isc-bind/log
> > chmod 775 /var/opt/isc/isc-bind/log
>
> I have re-applied that permission change, and things are happy again. Which
> brings me to two follow-up questions.
>
> A) Should I expect these file permissions be altered by a minor update? I
> know I started at 9.11.8 and have updated to 9.11.9 and 9.11.10 without
> seeing this behavior.
/var/opt/isc/isc-bind/log is part of the isc-bind-runtime package, which
is the runtime package for the isc-bind Software Collection. The
contents of that package are determined by the %{scl_files} macro used
in the *.spec file for the isc-bind metapackage [1]. That is how the
runtime package is supposed to be created according to Software
Collection docs [2]. We do not add that directory explicitly.
Answering your question, this directory is not touched when you update
the isc-bind-bind package (which is usually the only package that gets
updated whenever a new version of BIND is released), but it *will* be
affected (i.e. its permissions will be reset to those specified by the
package) by isc-bind-runtime updates.
We recently had to update the metapackage to make the Software
Collection work on RHEL/CentOS 8, which also caused a revision bump for
the isc-bind-runtime package. That is likely the update that caused the
permissions on your box to be reset. Updates like this are rare, but
can happen from time to time, so I would avoid relying on customized
permissions for packaged directories.
> B) Should I not be logging to /var/opt/isc/isc-bind/log?
> The log path in my named.conf is currently set to a relative path
> "../../log/query.log", but I could easily change it to an absolute path
> "/var/log/named/query.log"
You can really log where you want as long as the permissions are right.
The default named.conf included with our packages causes logs to be
written to /var/opt/isc/isc-bind/named/data/named.run, mimicking what
stock RHEL/CentOS BIND packages do (with the path adjusted to follow the
Software Collection's directory layout).
Note that /var/opt/isc/isc-bind/log is the Software Collection's
equivalent of /var/log; if you configured named to log to the latter, it
would also not work because /var/log is owned by root:root by default,
just like /var/opt/isc/isc-bind/log is.
If you are okay with adhering to the Software Collection's directory
layout, feel free to create a subdirectory in /var/opt/isc/isc-bind/log
with proper permissions - subdirectories should not be affected by the
metapackage updates I mentioned above. But the Software Collection does
not force you to use that location.
Hope this helps,
[1]
https://gitlab.isc.org/isc-packages/rpms/isc-bind/blob/434d4d8a6e436e0943cfc2deac2f1a07fe3136b5/isc-bind.spec#L63
[2]
https://www.softwarecollections.org/en/docs/guide/#bh-Example_of_the_Meta_Package
--
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: 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: bug in ifiter_getifaddrs.c cannot find include file: ??
> Not sure where the need for ifaddrs.h came from but it doesn't exist in > ye old Solaris 10 sparc boxen : It comes from getifaddrs() being the only supported network interface enumeration mechanism supported in BIND 9.14+. Other such mechanisms were removed as part of code cleanups during the 9.13 development cycle: https://gitlab.isc.org/isc-projects/bind9/merge_requests/668 Thus, BIND 9.14+ will not compile on Solaris 10, as indicated in the PLATFORMS.md file. BIND 9.11 will. Both work on Solaris 11. -- 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: A little baffled by bind 9.14.2 wanting some special python?
> For reasons unknown the configure process blows up even if I specify > the option --disable-python and in the config.log I see : The option is actually called --without-python; the fix for that mistake is already committed: https://gitlab.isc.org/isc-projects/bind9/merge_requests/1964 Apologies about the confusion. -- 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: isc-bind-esv Repository - "yum update" doing undesirable things!
> Purely out of curiosity, I did try building libevent which failed > miserably:- > > (...) > > For my part, I am not concerned about this as I am not using DNSTAP and > only mention the issue in case others encounter it. Ah, thanks for checking this. I was wrong - SRPMs for dnstap dependencies published in our Coprs cannot be rebuilt without SCL support. This is due to the fact that when rebuilding an existing SRPM, the initial value of the %name macro is extracted from the RPM header of the SRPM file. This could be worked around by not using certain macros in the arguments for the %setup macro [1], but the proper way of building a non-SCL version of BIND with dnstap support is to regenerate SRPMs straight from the *.spec files [2], using "--without scl" all the way. I originally believed rebuilding SCL SRPMs using "--without scl" would work fine because it worked on Copr, but the build process on Copr starts from the *.spec file, not from an SRPM. Apologies about the confusion and thanks again for checking. [1] Our BIND *.spec file does not use the %pkg_name macro, which is why rebuilding the SRPM created out of it using "--without scl" works fine. [2] See the repositories at: https://gitlab.isc.org/isc-packages/rpms -- 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: isc-bind-esv Repository - "yum update" doing undesirable things!
> Thank you for your most helpful advice. On Centos 7, I have easily managed > to build the non-scl packages using the following method starting with a > default Centos 7 (I was using Linode) logged in as root:- > > (...) > > However, my luck is not quite as good with Centos 6 where my method is > similar:- > > (...) > > but the rpmbuild fails due to a couple of missing dependencies:- > > (...) What you are observing is one of the reasons we decided to provide our own packages - namely, that building BIND with dnstap support on a platform which does not readily supply all relevant build requirements is a bit of a pain in the neck. The reason your CentOS 7 build succeeded is that EPEL 7 contains the required build dependencies for dnstap support in BIND; EPEL 6 lacks these and thus the build fails. > Thus far, I have failed on Centos 6 to identify how or where to install > these two depedencies, for which I would ideally like a package rather than > compiling from source. You have two options here: - build without dnstap support, by using "--without dnstap", - make the build requirements available in the build environment, most likely by first building them from source as well (you can use the SRPMs in our Coprs for convenience), in this order: 1. libevent 2. fstrm 3. protobuf 4. protobuf-c > I have tried (what I thought was obvious) of > installing the current Centos 6 Copr packages on the build machine, but > that did not assist. The development packages in our Coprs can only be used for building a Software Collection [1]. Thus, installing them as they are will not allow you to compile a non-SCL version of BIND with dnstap support. Hope this helps! [1]: unless you rebuild them using "--without scl", of course -- 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: Preferred log location with ISC copr package
> I did a fresh installation from isc/bind-esv onto CentOS 7. It doesn't look > to me like the permissions on the log directory were set correctly. > > > drwxr-xr-x. 2 root root 6 May 15 23:29 /var/opt/isc/isc-bind/log > > drwxr-x---. 3 root named 18 May 20 15:01 /var/opt/isc/isc-bind/named > > drwxrwx---. 2 named named 77 May 20 15:52 /var/opt/isc/isc-bind/named/data > > > The helpful suggestion above had me expecting the log directory would be set > similar to the named/data directory, with write permissions for the process > UID. > > My follow-up question is: Should the package installation have set different > owner:group and permissions on /var/opt/isc/isc-bind/log? My apologies for not making myself entirely clear in my previous message. Let me try again. ISC packages only set up the following directory for logging purposes: /var/opt/isc/isc-bind/named/data If you want to make named write logs to any other directory, you have to set up that directory yourself. -- 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: Preferred log location with ISC copr package
Hi John, > I'm considering changing one of my BIND installations to use the > experimental ISC-provided packages: > https://www.isc.org/blogs/bind-9-packages/ > > With these packages, what it the recommended location for log files? By default, ISC packages try to mimic what stock RHEL/CentOS BIND packages are doing, i.e. named logs are written to the Software Collection counterpart of /var/named/data/named.run, i.e. /var/opt/isc/isc-bind/named/data/named.run. However, this is just a default and you are in no way limited to that. > A directory was created as part of the package installation: > /var/opt/isc/isc-bind/log/ Correct, this directory is a part of the standard Software Collection runtime which is created at package build time according to macros provided by Red Hat. > Since I'm new the "Software Collection" paradigm, I don't know if this is an > acceptable location for my operational logs. It is as acceptable as any other location to which named has write access. The default path I mentioned above is set up automatically upon package installation; if you would like to log to a different file, you will have to take care of ensuring proper filesystem permissions and SELinux labelling yourself. You can also consider logging to a syslog daemon and configuring it to your liking as an alternative to logging directly to a file. > Is that location going to get > trashed when I install the next update? We do our best to ensure our packages do not trash anything in an irreversible manner. Thus, this should not be an issue. You can try it out yourself, e.g. by installing BIND from the isc/bind Copr first, then adding the isc/bind-dev Copr as well and finally running "yum update". Hope this helps, -- 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: isc-bind-esv Repository - "yum update" doing undesirable things!
Matthew, > The tools (dig etc) are used both manually and by a number of scripts. > Following the upgrade without enabling SCL, dig (for example) was the > previous version which came from the previous Copr package. Is there any > official/recommended method for updating server to make the new tools the > default? The tricky part here is that the whole idea of Software Collections is not to influence the base system underneath. For shell use, the way to go would be to remove the old isc-bind-utils package and put the following line e.g. in your .bash_profile file: source scl_source enable isc-bind If you want the Software Collection to be available for all users by default, you can put the above line in a file placed in /etc/profile.d, as hinted by Red Hat [1] (caveats apply). However, that still does not solve the issue of non-interactive scripts as Software Collections requires specific environment variables to be set that are not be set by default e.g. by the cron daemon. You can either put the above "source scl_source..." line in your scripts or try using one of the methods listed in the official Software Collections docs [2]. I am unable to say which solution would work best for you because it really varies on a case-by-case basis. > You also comented about using "--without scl" with SRPMs. Does this give > the previous behaviour? Yes, it results in "classic" packages being built that do not comprise a Software Collection and thus may conflict with stock OS packages, mess with other software's dependencies on the same machine etc. > Also, what is the correct location from which to > download the SRPMs? Since Copr places the SRPM for each package in the same directory as the binary RPMs produced from it, once you add a Copr repository to your yum configuration, you can do e.g. this: $ yumdownloader --source isc-bind-bind Hope this helps, [1]: https://access.redhat.com/solutions/527703 [2]: https://www.softwarecollections.org/en/docs/guide/#sect-Enabling_the_Software_Collection -- 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: isc-bind-esv Repository - "yum update" doing undesirable things!
After running some experiments, our plan is to make the SCL RPMs for the upcoming set of releases (9.11.7, 9.14.2, 9.15.0; all due in two days) use an FHS-compliant directory layout. Scriptlets in the revised RPMs will attempt to adjust existing installations automatically, so that the upgrade is seamless. -- 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: isc-bind-esv Repository - "yum update" doing undesirable things!
> I believe SCL allows multiple versions of the same package ... will ISC be > using SCL in this manner? If you are asking whether it will be possible to install multiple BIND Software Collections side by side on the same machine, then no. All our Copr repositories use the same Software Collection name, so that it is easy to migrate from one Copr to another and so that build recipes can be shared between all Coprs. I think it goes without saying, but just to make it clear: you will still be able to install your chosen BIND Software Collection on a machine which already has stock BIND packages installed. -- 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: isc-bind-esv Repository - "yum update" doing undesirable things!
> If the old XPG4 and POSIX rules are to be at least paid some attention > then the config data should be under /etc/opt/isc/named and the software > binaries and libs stay in /opt/isc/named with logs going to the correct > /var/opt/isc/named. This is a good point, thanks for raising it. Software Collections allow this kind of approach, we just initially rejected it as it makes other things more complicated and one of our primary goals for these packages is simplicity. We will run some further experiments to see whether this route is feasible. One downside of moving to this approach is that it would be another breaking change, though obviously if this would result in a cleaner long-term solution, then now is the time to bite the bullet. I will report back to announce what we are going to do. Thanks again for the feedback. -- 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: isc-bind-esv Repository - "yum update" doing undesirable things!
> While it is an understood intent to move to scl, it is not nesseraly a > welcome change for all. > We were excited and were hoping to start using ISB BIND rpm's as they used to > be prior to the latest build, but I guess we will have to continue building > our own rpm's. FWIW, currently published SRPMs can be rebuilt using "--without scl". -- 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: isc-bind-esv Repository - "yum update" doing undesirable things!
Hi Matthew, > I have been using the isc-bind-esv repository on Centos 7 since it was > created. On each upgrade, a "yum update" has done the correct thing by > upgrading from the running version to the latest version. > > Today (happily on a cloned test server!) I repeated this with the upgrade > being from 9.11.6 to 9.11.6.P1-1.2.el7. > > It seems that the package names have changed and that Bind is now installed > in a new directory structure below /opt/isc. In my case, a previously > working authoratitive configuration is now comprehensively broken. > > Before troubleshooting, I was wondering whether I had missed any release > notes or similar which might explain what is going on. First of all, thanks for trying these packages out and apologies for the trouble caused. This is an intentional change in a repository which ISC has always been describing as experimental [1]. A few months ago, we decided that Software Collections [2] are the preferred long-term solution for our RPM packages. Among other things, this was prompted by the package conflicts people were running into when using our Coprs [3]. What you observed on your server is an update from non-SCL packages to SCL packages. To make your previous setup work with SCL packages, please move your /etc/named.conf to /opt/isc/isc-bind/root/etc/named.conf. If you previously enabled named startup upon boot and you still want that to be the case, please run: systemctl start isc-bind-named BIND utilities (e.g. dig, rndc) are available after enabling the Software Collection, for example using: scl enable isc-bind bash This disruption was a one-off - we plan to soon move our Copr repositories away from their current experimental status. Once that happens, care will be taken not to break existing installations. Once again, apologies for the inconvenience. If you have any further questions, please feel free to ask them. Hope this helps, [1] See https://www.isc.org/blogs/bind-9-packages/ and the description of the Copr itself. [2] https://www.softwarecollections.org/ [3] https://lists.isc.org/pipermail/bind-users/2019-January/101277.html, for example -- 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: bind 9.12 rpm dependency problem
Hi Daniel, > Error: Package: 1:nfs-utils-1.3.0-0.61.el7.x86_64 (@anaconda) >Requires: libevent-2.0.so.5()(64bit) >Removing: libevent-2.0.21-4.el7.x86_64 (@anaconda) >libevent-2.0.so.5()(64bit) >Updated By: libevent-2.1.8-3.el7.x86_64 (isc-bind) > ~libevent-2.1.so.6()(64bit) > Error: Package: libverto-libevent-0.2.5-4.el7.x86_64 (@anaconda) >Requires: libevent-2.0.so.5()(64bit) >Removing: libevent-2.0.21-4.el7.x86_64 (@anaconda) >libevent-2.0.so.5()(64bit) >Updated By: libevent-2.1.8-3.el7.x86_64 (isc-bind) > ~libevent-2.1.so.6()(64bit) There are libevent 2.1.x packages available in the BIND Copr repository, but you appear to have other packages on the host in question that depend on libevent 2.0.x and thus yum is refusing to update it. Since libevent is not a runtime BIND dependency, as a temporary workaround you can try adding the following line to the BIND Copr repository configuration in /etc/yum.repos.d: exclude=libevent* In the long run, we plan to move to Software Collections, which would solve problems like this for good, but unfortunately I am unable to provide you with any estimates as to when exactly that might happen, sorry. Hope this helps, -- 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: Enforcing minimum TTL...
Hi Grant, > > You could setup a DNSMASQ / Unbound service as a front end, which then > > queried bind. Both of those allow the setting of a minimum TTL (max of > > 3600 seconds in DNSMASQ). It cannot be done with bind by itself. > > *nod* > > I was aware that there were other resolvers that could do this. But my > preference is to do it with BIND if possible. You might want to keep an eye on: https://gitlab.isc.org/isc-projects/bind9/issues/613 -- 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: Understanding TTL in "rndc dumpdb"-output
> I've checked the serve-stale status, which is currently off. > # rndc serve-stale status > _default: off (stale-answer-ttl=1 max-stale-ttl=604800) > _bind: off (stale-answer-ttl=1 max-stale-ttl=604800) > > Is this a normal behavior, that in the "rndc dumpdb" nevertheless the TTL in > the form of "serve-stale" is shown (even if the serve-stale-status = off)? Yes, this is normal. Once again (please take another look at the parenthesized part of my previous response), max-stale-ttl is separate from stale-answer-enable. -- 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: Understanding TTL in "rndc dumpdb"-output
> After querying my resolver for "testbla11.example.com", I receive a NXDOMAIN > response with a minimum-ttl (in the soa) of 3600. > When I afterwards dump the cache of my resolver (9.12.2-P1) with "rndc > dumpdb" and look for the negative ttl, then a value much bigger than 3600 is > shown (608363): > # grep testbla /var/named/data/named_dump.db > testbla11.example.com.608363 \-ANY ;-$NXDOMAIN > > This number decrements every second. > > What is this number? The same behavior for positive answers too. The > A-record for "www.google.com" has a TTL for 300 seconds. In the "rndc > dumpdb"-output I have a value for 605082. This happens due to the serve-stale feature being available in BIND 9.12 and later, with max-stale-ttl set to 604800 by default (note that this does *not* mean serving stale answers is enabled by default). The TTLs you are seeing in the cache dump essentially indicate how much longer any given record will be kept in the cache database. The serve-stale "offset" is indicated in a comment near the top of the dump; I am fairly sure it will say "; using a 604800 second stale ttl" in your case. -- 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: bind-9.12.2-P2 fails to compile with baffling undefined symbol issues
> So what is the minimum spec for ISC Bind? If the ISO/IEC 9899:2011 > standard is minimum then perhaps there could be a notation somewhere > on the isc site for that. Platform requirements are specified in the PLATFORMS file inside each BIND source archive since BIND 9.13.1: https://gitlab.isc.org/isc-projects/bind9/blob/master/PLATFORMS.md If you have any comments about it, please open a GitLab issue. -- 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: bind-9.12.2-P2 fails to compile with baffling undefined symbol issues
> /opt/developerstudio12.6/bin/c99 -mt -errfmt=error -erroff=%none > -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xc > -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none > -xdebugformat=dwarf -xunroll=1 -xarch=sparc -I/usr/include/libxml2 -I > /usr/local/include -KPIC -o resolve \ > resolve.o ../irs/libirs.a ../dns/libdns.a -lgss -lkrb5 > ../isccfg/libisccfg.a ../isc/libisc.a -L/usr/local/lib -R/usr/local/lib > -R/usr/local/lib -lcrypto -ldl -lnsl -lsocket -lscf -lrt -lpthread > -L/usr/lib -R/usr/lib -lxml2 -lz -lpthread -lm -lsocket -lnsl > -L/usr/local/lib -latomic > Undefined first referenced > symbol in file > _TG_atomic_fetch_add../dns/libdns.a(tsig.o) > _TG_atomic_fetch_sub../dns/libdns.a(tsig.o) > _TG_atomic_load ../dns/libdns.a(tsig.o) > _TG_atomic_compare_exchange_strong ../isc/libisc.a(rwlock.o) > _TG_atomic_store../isc/libisc.a(stats.o) > ld: fatal: symbol referencing errors. No output written to resolve > gmake[2]: *** [Makefile:464: resolve] Error 2 > gmake[2]: Leaving directory > '/usr/local/build/bind-9.12.2-P2_SunOS5.10_sparc64vii+.001/lib/samples' > gmake[1]: *** [Makefile:82: subdirs] Error 1 > gmake[1]: Leaving directory > '/usr/local/build/bind-9.12.2-P2_SunOS5.10_sparc64vii+.001/lib' > gmake: *** [Makefile:88: subdirs] Error 1 This looks like an Oracle Developer Studio glitch related to C11 atomic operations. To fix it, try fiddling around with the -xatomic compiler option [1] and/or the -std compiler option and/or the CC environment variable. To work around the problem, build BIND with --disable-atomic. Note that atomic operations support is mandatory as of BIND 9.13.3. [1] https://docs.oracle.com/cd/E60778_01/html/E60745/gqico.html -- 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: bind-9-packages: RPS and both '--enable-static' and '--disable-static'?
Hi James, > Thank you for the https://www.isc.org/blogs/bind-9-packages/ > blog post and various binary distributions mentioned in it. > > I am an end user, not a programmer, and I rely on Linux > distributions and application packages and so having up-to-date > content from authoritative sources is both helpful and very > reassuring. > > As a result of this, I now have the "stable" currently-9.12.2 > version from https://launchpad.net/~isc/+archive/ubuntu/bind > installed on Ubuntu 18.04 here on my home desktop in order to > hack away at something. Thanks for giving our packages a shot! > So I was looking forward to RPS having the effect of adding TCP > to the mix and doing a much more respectable job of extracting > the queries. > > Which does lead to the question about some RPS documentation > but that's sorta moot at this point. I am not sure if you are aware of it but writing a library implementing the DNSRPS API is not something entirely straightforward. See the "librpz_0_t" type in lib/dns/include/dns/librpz.h for a list of methods comprising the library interface. Also note that the only working implementation whose existence I am aware of is a proprietary one. Given the above, a strong enough motivation for using --enable-dnsrps in the packages we build and support is lacking. Note that Debian and its derivatives provide tools which make rebuilding a source package with different compile-time options fairly convenient. > Also, when running "named -V", I see both '--enable-static' and > '--disable-static' in the output. I have no idea if this is > sensible or not but it sure looks a little funny: Thank you for catching this, we will fix it. -- 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: Local Slave copy of root zone
> BIND 9.14 will have an improved local root implementation (called a > "mirror" zone) which validates the zone so you don't blindly serve bogus > data. The feature is available now in the 9.13 dev branch; I have not > tried mirroring the arpa zones - the docs suggest that isn't a supported > config for mirror zones. The catch is that, as of current master, you would have to configure trusted-keys/managed-keys for each zone you would like to mirror. In other words, the chain of trust from the root is currently not established automatically when a mirror zone is validated. This might change in the future, but since the root zone is the primary use case and a default trust anchor for the root zone is installed implicitly, I would not hold my breath for it. -- 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: Operational Notification: Extremely large zone transfers can result in corrupted journal files or server process termination
> > What is an "extraordinarily large zone transfer"? We do have regularly > > AXFR and IXFRs around 2GB. Is this "extraordinarily large"? > > > > I've also been curious about this. Are we talking millions of records, > tens or hundreds of millions, or billions? Hopefully this will shed some light on the matter: https://gitlab.isc.org/isc-projects/bind9/issues/339#note_12805 -- 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: configure option --disable-crypto-rand unsupported in 9.12.2?
Hi Daniel, > I have the configure option "--disable-crypto-rand" for some BIND 9.12 > builds. Building BIND with this option fails for the latest BIND 9.12.2: > > BUILDSTDERR: openssl_link.c: In function 'dst__openssl_init': > BUILDSTDERR: openssl_link.c:274:2: error: 're' undeclared (first use in > this function) > BUILDSTDERR: re = ENGINE_get_default_RAND(); > BUILDSTDERR: ^ > BUILDSTDERR: openssl_link.c:274:2: note: each undeclared identifier is > reported only once for each function it appears in > BUILDSTDERR: make[2]: *** [openssl_link.lo] Error 1 > make[2]: Leaving directory `/builddir/build/BUILD/bind-9.12.2/lib/dns' > make[1]: Leaving directory `/builddir/build/BUILD/bind-9.12.2/lib' > > If I remove "--disable-crypto-rand" for building BIND 9.12.2 it works. Thanks for reporting this. It is a backporting error which has now been fixed in the v9_12 branch, which means it will land in 9.12.3: https://gitlab.isc.org/isc-projects/bind9/merge_requests/529 Sorry about the trouble! -- 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: round-robin bug in 9.12.1-P2 for rDNS?
> > This sounds a bit like #336 [1], > > Nope - we got bit by that when we upgraded > to 9.12, which is what resulted in the explicit > config for rrset-order. > > > If you can still reproduce this with current > > master (or with current v9_12 branch), please > > open a new GitLab issue. > > Please forgive my ignorance on this point, > but is running the FreeBSD package for > 9.12.1-P2 sufficient to meet this? It probably is, the #336 bit above was a long shot. Please open a GitLab issue, supplying version information and a configuration which allows reproducing this behavior. Thanks! -- 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: round-robin bug in 9.12.1-P2 for rDNS?
> I have a funny issue that looks buggish > to me. I have an RRSET with two > A records that our auth DNS servers happily > round-robin, which can be observed with > > dig unix.lt.ucsc.edu @adns1.ucsc.edu > > However, our recursive DNS servers, with > the same rrset-order config will not round-robin > these records. > > BUT, if I add a third A record, the rDNS servers > then round-robin. > > I can punch in some config elements here if > it is useful, but this smells like a bug, and > maybe I should be reporting on gitlab. > > Thoughts? This sounds a bit like #336 [1], but you mentioned rrset-order being explicitly set in your configuration, so it might be something else. If you can still reproduce this with current master (or with current v9_12 branch), please open a new GitLab issue. Thanks! [1] https://gitlab.isc.org/isc-projects/bind9/issues/336 -- 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: BIND rejecting key to update a zone
> Hi Michal, thanks for the reply and sorry for the delay on my end. > > I've started a fresh install here and started over and still having the > same issue, even when I crank the debug trace up to 5, I'm not seeing > anything additional in the logs: > > 08-Jun-2018 14:56:50.281 update-security: info: client > 127.0.0.1#32983/key rpz-update: signer "rpz-update" denied > 08-Jun-2018 14:56:50.281 update-security: error: client > 127.0.0.1#32983/key rpz-update: update 'test.rpz/IN' denied Ah, it seems I did not make myself clear enough, sorry. What I was really hoping for is to see debug logs for the entire process of handling the UPDATE query that is being denied, not just the last part where the denial itself is being reported. These logs would probably contain interesting bits that could help prove or disprove my Unicode theory. In any case, since you got the same, unexpected result after starting over, this looks like a potential bug, but I am afraid I really need to take a look at your full configuration to make any headway here, otherwise this will mostly be an exercise in tasseography as it seems to work as expected for me. Tracking this further as a GitLab issue makes most sense to me. I assume that the configuration you are using is not deployed in production, but if you nevertheless have any confidentiality concerns, you can use "named-checkconf -px" to conceal your key secrets and/or mark the GitLab issue as confidential. Also feel free to contact me off-list if that suits you best. Thanks, -- 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: BIND rejecting key to update a zone
Hi Mark, > Jun 1 20:19:34 rpz0 named[30999]: client 127.0.0.1#64585/key > dns-update: signer "dns-update" denied > Jun 1 20:19:34 rpz0 named[30999]: client 127.0.0.1#64585/key > dns-update: update 'test.rpz/IN' denied > > What am I missing here? Interesting, you do not seem to be missing anything: this works as expected for me (i.e. the update is allowed) on a fresh Debian 9 VM. AFAICT without looking at your entire configuration, in order for both of the log messages you quoted to be generated, named would need to recognize the key used for signing the request (otherwise you would get a BADKEY response), but not allow it to update the relevant zone. Perhaps a long shot, but is there any chance there are non-ASCII characters in your configuration file, like some Unicode variant of the hyphen character (‐, ‑, ‒, etc.)? If not, could you please bump the debug level to at least 3, retry, and paste the log messages generated? Please also feel free to open an issue at https://gitlab.isc.org. -- 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: botched KSK rollover
> I added a week to inactivation, > > # dnssec-settime -I+1w Knodns4.us.+005+60073.key > > I thought I should then try deactivating the new one, I am not sure whether this is really what you wanted to achieve, but in any case "dnssec-settime -i ... -S ..." only sets publication and activation dates for the successor key, not its inactivation date. > but > dnssec-settime did not like what I tried: > > # dnssec-settime -i6d -S Knodns4.us.+005+60073.key Knodns4.us.+005+16408.key > dnssec-settime: fatal: Predecessor will become inactive before the > prepublication period ends. Either change its inactivation > date, or use the -i option to set a shorter prepublication > interval. > > I don't understand this error. 1w > 6d, right? I checked the code and it seems to be a bug. A fix is in review: https://bugs.isc.org/Public/Bug/Display.html?id=45806 Thank you for reporting! -- 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
