PKCS#11 vs OpenSSL (BIND Future Development Question)
Hi all, BIND 9 currently supports two major cryptography provider libraries - OpenSSL[1] and PKCS#11. The PKCS#11 interface is very fragile, as the different vendors implement different parts of the standard, and BIND needs to be compiled with a specific PKCS#11 provider defined at the compile time. This is certainly suboptimal, and we are looking at ways how to improve that. So, if you are running BIND with PKCS#11 HSM, or you are thinking about such setup, I would be interested to hear answer to couple of questions: 1. What functions of PKCS#11 do you care 1a) getting entropy? 1b) message digests? 1c) HMAC? 1d) symmetric crypto (meaning AES) 1e) public-key cryptography (aka DNSSEC keys) (Background: PKCS#11 as currently used in BIND uses PKCS#11 exclusively for anything related to crypto.) 2. Would you be fine if BIND double linked with OpenSSL and PKCS#11? (Background: if some of the answers to previous question were NO, BIND would have to use OpenSSL as a provider for these functions and it would make the code more slimmer, and easier to test.) 3. Would you care if BIND wouldn’t link directly to PKCS#11 library and used OpenSSL engine: https://github.com/OpenSC/libp11#openssl-engines (Background: the PKCS#11 is full of #ifdefs, for full picture see [1], and it doesn’t really make sense to develop the same work-arounds at two different places.) ~~~ There are three possible course of actions we might take: 1. Convert the PKCS#11 usage to OpenSSL PKCS#11 engine. That would save us from most of the headaches with PKCS#11, but it might require some configuration changes for existing deployments. 2. Convert the non public-key cryptography parts to OpenSSL. This would allow people to keep the DNSSEC private keys inside the HSMs, but all the other crypto would come from OpenSSL. (OpenSSL itself has FIPS 140-2 validation if that means anything to you.) 3. Keep the status quo There are some options to these three: A. Improve the PKCS#11 handling to runtime detection of HSM capabilities B. Support OpenSSL and PKCS#11 DNSSEC keys at the same time, say to store KSKs in PKCS#11 and ZSK on disk... The A is non-issue for 1., likely to happen with 2., and unlikely to happen with 3. The B will happen with 1., likely to happen with 2., and impossible to happen with 3. As usual, the goal is to balance the time we have to spend on improving BIND, and our development resources are limited, so any resources saved by reducing the code we need to maintain would free our hands to do something else (like A or B). Also please note that this is not going to affect any previously released version of BIND, just future releases. 1. https://gitlab.isc.org/isc-projects/bind9/blob/master/lib/isc/include/pk11/site.h 2. https://www.openssl.org/docs/fips.html#background Ondrej -- Ondřej Surý ond...@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: PKCS#11 vs OpenSSL (BIND Future Development Question)
> On 4 Jun 2018, at 10:21, Mathieu Arnold wrote: > > On Sun, Jun 03, 2018 at 06:00:08AM +0000, Ondřej Surý wrote: >> The PKCS#11 interface is very fragile, as the different vendors implement >> different parts of the >> standard, and BIND needs to be compiled with a specific PKCS#11 provider >> defined at the >> compile time. This is certainly suboptimal, and we are looking at ways how >> to improve that. > > My understanding was that you had to choose at compile time wether you > needed PKCS#11 or OpenSSL, and that, even if you could link with a > specific provider during the build, you could opt-out and start named > with -E /path/to/engine.so. At least, it is the way it is done in the > FreeBSD ports tree. That’s only sort of true, see lib/isc/include/pk11/README.site for more detailed description, but there are some HSMs that need compile time flags in site.h, and the default is /* Default is for Thales nCipher */ #ifndef PK11_FLAVOR #define PK11_FLAVOR PK11_THALES_FLAVOR #endif #if PK11_FLAVOR == PK11_THALES_FLAVOR #define PK11_DH_PKCS_PARAMETER_GEN_SKIP /* doesn't work but supported #define PK11_DSA_PARAMETER_GEN_SKIP */ #define PK11_MD5_HMAC_REPLACE #endif So, even if you can specify a runtime PKCS#11 library, it doesn’t mean it will work as expected. To my best understanding, if we keep only the Public-Key crypto for PKCS#11, there’s only one parameter that will need tuning PK11_RSA_PKCS_REPLACE and we could either declare that the HSM must support EMSA-PKCS#1-v1.5 or turn that into runtime detection (as this would be the only workaround that we would need to keep). Ondrej -- Ondřej Surý ond...@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: bug in ifiter_getifaddrs.c cannot find include file: ??
Hi Dennis,
see PLATFORMS.md from the distribution. Unfortunately, Solaris 10 is just too
old
to be supported. You will either need to upgrade to Solaris 11 or use BIND
9.11 ESV
—cut here—
[…]
## Supported platforms
In general, this version of BIND will build and run on any POSIX-compliant
system with a C99-compliant C compiler, BSD-style sockets with RFC-compliant
IPv6 support, POSIX-compliant threads, and the OpenSSL cryptography library.
Atomic operations support from the compiler is needed, either in the form of
builtin operations, C11 atomics or the Interlocked family of functions on
Windows.
ISC regularly tests BIND on many operating systems and architectures, but
lacks the resources to test all of them. Consequently, ISC is only able to
offer support on a "best effort" basis for some.
[…]
## Unsupported platforms
These are platforms on which BIND 9.15 is known *not* to build or run:
* Platforms without at least OpenSSL 1.0.2
* Windows 10 / x86
* Windows Server 2012 and older
* Solaris 10 and older
* Platforms that don't support IPv6 Advanced Socket API (RFC 3542)
* Platforms that don't support atomic operations (via compiler or library)
* Linux without NPTL (Native POSIX Thread Library)
[…]
—cut here—
Ondrej
--
Ondřej Surý
ond...@isc.org
> On 29 May 2019, at 07:34, Dennis Clarke wrote:
>
>
> Not sure where the need for ifaddrs.h came from but it doesn't exist in
> ye old Solaris 10 sparc boxen :
>
> /opt/developerstudio12.6/bin/cc
> -I/usr/local/build/bind-9.14.2_SunOS5.10_sparc64vii+.002 -I../../..
> -I./include -I./../pthreads/include -I../include -I./../include -I./..
> -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> -std=iso9899:2011 -m64 -xarch=sparc -g -errfmt=error -errshort=full
> -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl
> -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -xs
> -xdebugformat=dwarf -errtags=yes -errwarn=%none -erroff=%none
> -D_POSIX_PTHREAD_SEMANTICS -mt -I/usr/local/include/libxml2
> -I/usr/local/include -I/usr/local/include -KPIC-c interfaceiter.c
> "ifiter_getifaddrs.c", line 21: cannot find include file:
> "ifiter_getifaddrs.c", line 81: warning: implicit function declaration:
> getifaddrs (E_NO_IMPLICIT_DECL_ALLOWED)
> "ifiter_getifaddrs.c", line 107: warning: implicit function declaration:
> freeifaddrs (E_NO_IMPLICIT_DECL_ALLOWED)
> "ifiter_getifaddrs.c", line 135: error: undefined struct/union member:
> ifa_name
> "ifiter_getifaddrs.c", line 137: error: improper member use: ifa_addr
> "ifiter_getifaddrs.c", line 137: error: operands have incompatible types:
> struct sockaddr {unsigned short sa_family, array[14] of char sa_data}
> "==" long
> "ifiter_getifaddrs.c", line 140: error: improper member use: ifa_addr
> "ifiter_getifaddrs.c", line 140: error: left operand of "->" must be pointer
> to struct/union
> "ifiter_getifaddrs.c", line 151: error: improper member use: ifa_name
> "ifiter_getifaddrs.c", line 151: warning: improper pointer/integer
> combination: arg #1 (E_BAD_PTR_INT_COMB_ARG)
> "ifiter_getifaddrs.c", line 156: error: improper member use: ifa_name
> "ifiter_getifaddrs.c", line 156: warning: improper pointer/integer
> combination: arg #2 (E_BAD_PTR_INT_COMB_ARG)
> "ifiter_getifaddrs.c", line 160: error: undefined struct/union member:
> ifa_flags
> "ifiter_getifaddrs.c", line 163: error: undefined struct/union member:
> ifa_flags
> "ifiter_getifaddrs.c", line 166: error: undefined struct/union member:
> ifa_flags
> "ifiter_getifaddrs.c", line 171: error: improper member use: ifa_addr
> "ifiter_getifaddrs.c", line 171: error: improper member use: ifa_name
> "ifiter_getifaddrs.c", line 171: error: argument #3 is incompatible with
> prototype:
>prototype: pointer to struct sockaddr {unsigned short sa_family,
> array[14] of char sa_data} : "interfaceiter.c", line 59
>argument : struct sockaddr {unsigned short sa_family, array[14] of
> char sa_data}
> "ifiter_getifaddrs.c", line 171: warning: improper pointer/integer
> combination: arg #4 (E_BAD_PTR_INT_COMB_ARG)
> "ifiter_getifaddrs.c", line 173: error: undefined struct/union member:
> ifa_netmask
> "ifiter_getifaddrs.c", line 174: error: improper member use: ifa_netmask
> "ifiter_getifaddrs.c", line 175: error: improper member use: ifa_name
> "ifiter_getifaddrs.c", line 174: warning: improper pointer/integer
> combination: arg #3 (E_BAD_PTR_INT_COMB_ARG)
> "ifiter_getifaddrs.c", line 175: warning: improper pointer/integer
> combi
Re: BIND 9.14.2 configure problem
The script reports everything is missing. You’ll need to check config.log for more details what’s happening. Anyway it should work with stock OpenSSL, so why don’t you just use that? Cheers, Ondrej -- Ondřej Surý — ISC > On 7 Jun 2019, at 17:12, wrote: > > That makes sense, but unfortunately it does not resolve the problem. I've > tried specifying LD_RUN_PATH and LD_LIBRARY_PATH, and exporting them both as > well, but BIND 9.14 configure script still complains about lack of ECDSA > support in OpenSSL. > > Greg > > -Original Message- > From: Tony Finch [mailto:d...@dotat.at] > Sent: Friday, June 7, 2019 11:03 AM > To: Rabil,AG,A Gregory,JTK2 R > Cc: bind-us...@isc.org > Subject: Re: BIND 9.14.2 configure problem > > greg.ra...@bt.com wrote: > >> However when I specify this freshly built OpenSSL 1.1.1c install >> location when configuring BIND 9.14.2, it still complains: > > Try > > LD_RUN_PATH=/opt/tmp/openssl/lib ./configure --with-openssl=/opt/tmp/openssl > > What's probably happening is that the configure script's OpenSSL test > programs are not being correctly linked to the OpenSSL that you specified on > the command line. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ Viking, North Utsire: > Variable 4 or less, becoming northeasterly 3 to 5 later. > Slight, occasionally moderate in north. Fog patches, rain later. Moderate, > occasionally very poor. > ___ > 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: version 9.14.2 core dump
> On 18 Jun 2019, at 16:43, Witold Krecicki wrote: > > W dniu 17.06.2019 o 17:34, Mayer Hans pisze: > (...) >> My environment: >> Solaris 11.4 on Sparc >> gcc version 5.5.0 (GCC) > (...) > > There's a bug in GCC on Solaris wrt thread-local storage - > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90912 > > As a fix for now I'd suggest using Solaris Studio C compiler. Alternatively, you can comment out whole block in configure.ac after “Check for thread local storage” comment, run `autoreconf -fi` and BIND will now use locking, which is suboptimal, but it should suffice as a workaround. Ondrej -- Ondřej Surý ond...@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: A policy for removing named.conf options.
Hi Warren and everybody, first, let me thank for the fruitful discussion! > On 13 Jun 2019, at 15:18, Warren Kumari wrote: > > Many many people don't look at their logs -- could named also print > stuff to (stdout, stderr) when starting? > > Note that this will require some testing -- various distributions use > various init scripts - in many cases things printed at startup don't > actually make it to the console, and I'm suspecting some init systems > will barf, but… It’s undermentioned in the policy proposal, but the named-checkconf will be loud about the deprecated options. We can then bug distros to integrate the named-checkconf run into the pre/postinst maintainer scripts. (Hey myself, fix the Debian package. Ok, myself…) > Another phased approach would be to require users to acknowledge that > the feature is being deprecated -- initially it could warn, and then > named could require command line flags to enable the (being) > deprecated features, and then in the next release they would stop (e.g > named --enable_deprecated_cleaning-interval). I think that this is way > overkill, but just a thought. That would take 4 full years to deprecate single option, as we need to take people that upgrade from ESV to ESV into account, and we were aiming at slightly “faster” approach :-). Thanks, -- Ondřej Surý ond...@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: A policy for removing named.conf options.
Hey, we’ve been discussing the “call home” feature on several occasions and usually something more pressing crawls at top of the TODO list, but here’s the issue we have as a starter: https://gitlab.isc.org/isc-projects/bind9/issues/421 We would be happy to collect more feedback and don’t get me started on how I just love to receive patches, preferably as merge requests (ping me if you need up the projects limit in our GitLab) ;). Ondrej -- Ondřej Surý ond...@isc.org > On 13 Jun 2019, at 15:55, G.W. Haywood via bind-users > wrote: > > Hello again, > > On Thu, 13 Jun 2019, Matthijs Mekking wrote: >> On 6/13/19 2:40 PM, G.W. Haywood via bind-users wrote: >> > On Thu, 13 Jun 2019, Matthijs Mekking? wrote: >> > >> > > | managed-keys?? | 9.15/9.16 | replaced with dnssec-keys | >> > >> > According to my changelogs for 'named.conf I removed 'managed-keys' and >> > 'trusted-keys' three years ago, but still use 'managed-keys-directory'. >> ... it is likely that you are using managed trust anchors that >> are configured with 'managed-keys' in a bind.keys file. ... > > Correct. It says in that file that I'm not expected to do anything to > it - so I expect you'll take care of that when the time comes, yes? > > To tell you about the use of configuration options, could you not set > up an ISC zone which BIND on startup will ping with a few packets? > You'd get a lot more (and more accurate) feedback than sending out a > plea on a mailing list. You could make it a compile time option, ask > for permission at build time, etc.. > > -- > > 73, > Ged. > ___ > 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: A policy for removing named.conf options.
> On 13 Jun 2019, at 18:10, John Thurston wrote: > > On 6/13/2019 4:37 AM, Lightner, Jeffrey wrote: >> I'd suggest also giving warnings for deprecated options when running >> named-checkconf (and named-checkzone if applicable). You mention the logs >> but not the commands. >> Jeffrey C. Lightner >> Sr. UNIX/Linux Administrator > > I hope this is implemented in named-checkconf/zone. > > It would also be nice to include some sort of option on named-checkconf to > 'whitelist' or ignore the deprecation warnings, as I use named-checkconf two > different ways. "--no-deprecated”-like option is a nice idea, I like it. Thanks! -- Ondřej Surý ond...@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
Upcoming changes to the BIND 9 build system - Introduction of automake
Hey all, I’ve been working on rewriting the build system from plain autoconf (+optional libtool) to the modern toolchain that uses all the kids on the block - autoconf, automake, libtool and pkg-config. The work in progress can be found in 4-convert-to-modern-autotools-autoconf-automake-libtool branch and it passes our on the set of Linux systems we have in GitLab CI. However, if you have less common (but still supported) system[*] (check PLATFORMS.md), and you are willing to spend a little time to test the aforementioned branch, I would like to hear success or failure stories, so I know where to focus next. I would prefer to gather the feedback here: https://gitlab.isc.org/isc-projects/bind9/merge_requests/985 And/or in associated issue here (for more generic comments): https://gitlab.isc.org/isc-projects/bind9/issues/4 The work is more of a rewrite of the whole build system than simple refactoring, so it is crucial to get some testing from the systems we don’t really have access to. Cheers, Ondrej * - In theory, even cross-compilation for Windows msys2 should be possible, but I haven’t had yet time to do that. -- Ondřej Surý ond...@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: A policy for removing named.conf options.
> On 13 Jun 2019, at 17:55, Barry Margolin wrote: > > In article , > Matthijs Mekking wrote: > >> ## Deprecating >> >> A configuration option that is candidate for removal will be deprecated >> first. During this phase the option will still work, but we will be >> communicating to users that the option is going to be removed soon. A >> user that has deprecated options configured will see warnings in their >> logs and needs to take action to get rid of those log messages. >> Configuration options that are deprecated will be identified in the >> Release Note for the release they are deprecated in. > > As others have said, I'm not sure how effective this will be. I suspect > most people don't check the logs routinely, only when something goes > wrong. The policy isn’t intended to take care of people who don’t really care. The policy is here to have a transparent and careful way how to remove options. > Is it really much of a hassle to leave the obsolete options in the > parser, but just ignore them? Unfortunately, yes, it adds to overall entropy of the source code, and we aim to fix the cruft that has accumulated in last 20 years. This is more of high level design decision, but it is something that has to be done because it is connected with maintenance burden. And it’s a burden we don’t have to really carry on our shoulders. Ondrej -- Ondřej Surý ond...@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: 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: version 9.14.2 core dump
Hi Mayer (and other Solaris users), could you please try following patch: https://gitlab.isc.org/isc-projects/bind9/merge_requests/2053.patch on your Solaris boxes with both GCC and Solaris compiler whether it correctly complains about non-GNU ld in GCC case? Thanks, Ondrej -- Ondřej Surý ond...@isc.org > On 17 Jun 2019, at 17:34, Mayer Hans wrote: > > > Dear All, > > My environment: > Solaris 11.4 on Sparc > gcc version 5.5.0 (GCC) > bind 9.14.2 > ./configure '--enable-shared' '--enable-static' '--enable-ipv6' > '--without-libjson' '--with-gssapi=/usr/bin/krb5-config' > > > I tried to use bind 9.14.2 > So far everything is working fine except I try to query this name server over > the loopback interface. And this is independent if it is ::1 or 127.0.0.1 > If I do such a query "dig" hangs. At the same moment named generates a core > file. Below adb traceback and pstack. > Doing the same query through the "normal" interface over the network with > IPv6 or IPv4 everything works fine. > Not sure how I could fix this issue. So I stepped back to version BIND 9.11.7 > (Extended Support Version) > Because this doesn't have this issue. > Any ideas how to solve ? > > > // Hans > > -- > > # adb /usr/local/sbin/named core > core file = core -- program ``/usr/local/sbin/named'' on platform sun4v > SIGSEGV: Segmentation Fault > help > adb: failed to dereference symbol: unknown symbol name > $c > isc_random_buf+0xf4(7d8cb668, 4, 1, 5de9be36, 57f9ca5e, 7bb74494633) > ns_client_addopt+0x408(103608490, 10360b4c0, 103608758, 0, 2306, 0) > client_send+0x10c(103608490, 10, 0, 100567b80, 4, 0) > ns_client_send+0x4c(103608490, 100567b80, 7d8cd7dc, 7d8cd7d0, > 0, 11) > ns_query_done+0x434(7d8cedf8, 7d8cee00, 10360b4c0, 10360b4c0, > 7d8cd7dc, 0) > query_prepresponse+0x544(7d8cedf8, 7d8cdb30, 4, 5, > 7d8cd978, 103608490) > query_gotanswer+0x9c8(7d8cedf8, 0, 2, 1035fbec8, 103608490, 1035fbed0) > query_lookup+0x418(7d8cedf8, 29, 1, 40, 7d8ce3a8, 0) > ns__query_start+0x6b8(7d8cedf8, 0, 0, 103613740, 0, 7d8ce920) > query_setup+0x130(40, 1, 100054960, 0, 7d8cedf8, 0) > ns_query_start+0x4ec(103608490, 1, 103617e98, 1, 1, 10360b4c0) > ns__client_request+0x1914(10360909c, 103608f08, 1003d6578, 7d8cf57c, > 1003d5c88, 1003d5bf8) > run+0x510(10040cce0, 10040cd58, 10040cd5e, 102c629c8, b0, b0) > libc.so.1`_lwp_start(0, 0, 0, 0, 0, 0) > > > > > > root@jump2: pstack core_1 > core 'core_1' of 29584: /usr/local/sbin/named > lwp# 1 / thread# 1 --- > 79fe621c __sigtimedwait (7110, 0, 0, 7fffee90, e, > 7dd61280) + 8 > 79fba864 __posix_sigwait (7110, 70fc, e, 0, > 7dd61280, ff00) + 1c > 0001002b20e8 isc_app_ctxrun (1003e2240, 1003e22b0, 70fc, > 1003e2298, 7110, 1003d5388) + 220 > 0001002b23cc isc_app_run (1003f0680, 1003dc760, 1003dc780, 1003dc7a8, > 100043f38, 1003e22c0) + 2c > 0001000a6a0c main (1003dc7a8, 1003da050, 1003dc748, 1003dc758, 1003dc760, > 10041fcd0) + 1788 > 00010009c484 _start (0, 0, 0, 0, 0, 0) + 64 > lwp# 2 / thread# 2 lname: isc-worker --- > 79fe203c __lwp_park (10040dd08, 10040dcd0, 0, 7dd63280, 0, > 10040dcdc) + 14 > 79fdb814 cond_wait_queue (10040dd08, 10040dcd0, 0, 0, > 7dd63280, 7a130b80) + 4c > 79fdbdd0 cond_wait (10040dd08, 10040dcd0, 0, 0, 0, 1) + 10 > 79fdbe10 pthread_cond_wait (10040dd08, 10040dcd0, 0, 0, 10040dcd0, > ff00) + 8 > 0001002aa418 run (10040cce0, 10040cd58, 10040cd5e, 10040cd5c, 0, 0) + 130 > 79fe1fb0 _lwp_start (0, 0, 0, 0, 0, 0) > lwp# 3 / thread# 3 lname: isc-worker0001 --- > 79fe203c __lwp_park (10040dd60, 10040dd28, 0, 7dd65280, 0, > 10040dd34) + 14 > 79fdb814 cond_wait_queue (10040dd60, 10040dd28, 0, 0, > 7dd65280, 7a130b80) + 4c > 79fdbdd0 cond_wait (10040dd60, 10040dd28, 0, 0, 0, 1) + 10 > 79fdbe10 pthread_cond_wait (10040dd60, 10040dd28, 0, 0, 10040dd28, > ff00) + 8 > 0001002aa418 run (10040cce0, 10040cd58, 10040cd5e, 10040cd5c, 58, 58) + > 130 > 79fe1fb0 _lwp_start (0, 0, 0, 0, 0, 0) > lwp# 4 / thread# 4 lname: isc-worker0002 --- > 0001002a4c24 isc_random_buf (7d8cb668, 4, 1, 5de9be36, 57f9ca5e, > 7bb74494633) + f4 > 0001000ddf44 ns_client_addopt (103608490, 10360b4c0, 103608758, 0, 2306, > 0) + 408 >
ISC GitLab User maintenance (removing user account cruft)
Hi, ISC plans to do a maintenance on the GitLab accounts. There are a lot of accounts that are either unused or just spammy. The spam accounts are just spam SEO accounts (BetPokerOnline, WriteYourThesis, …) and the delete action on the account also means a whois + fail2ban sequence (there’s a possibility of collateral damage, but so far nobody complained). The unused category has two subtypes - clueless spammers, and enthusiasts. There’s no automated way how to distinguish clueless spammers (they create account and do nothing) and enthusiast (they create account and do nothing). And I think the less data we hold on our users the better. As of this moment, I’ve blocked all accounts that show no activity and older than one month and I will proceed to delete accounts with no activity and older than 6 months. If you want your account re-established, please drop me a note. There’s very simple way how to prevent deletion of your account, and you should do one of the following: 1. Setup 2fa on your account 2. Open issue / Comment on issue 3. Ask as to bump your project limit to something bigger than 0 The full script used to do the blocking can be found here: https://gitlab.isc.org/ondrej/gitlab-victor Ondrej -- Ondřej Surý ond...@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
ISC is hiring!
Hey, TL;DR https://jobs.isc.org/ ISC is looking for a talented people to join the BIND 9 team to work on the open source and help improve the Internet. We have two openings - Software Engineer BIND 9 and QA Engineer for BIND 9. You can check the requirements and apply for the job at https://jobs.isc.org/ Ondrej -- Ondřej Surý ond...@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: Statistics-channel json crashes Bind
Hi Ingeborg,
perhaps you can try running BIND by hand and see why it crashes on the console?
Usually the coredump is controlled by ulimit and it needs the directory
(working directory of the binary, on Linux that would be /prof//cwd) from
where you launch the binary writeable.
If BIND 9 crashes again we would need several things:
* a backtrace with symbols, this usually needs:
* unstripped named binary or named binary with matching debug symbols file
* named.conf -px output - this will anonymize any secrets from the file
If this involves remote crash on a remote interface (3rd party triggered
crash), please send the information to security-offi...@isc.org and you can
upload larger files at https://pandora.isc.org/
If this is triggered only locally by authorized users you can optionally fill
new issue https://gitlab.isc.org/isc-projects/bind9 and attach the files there.
To be on the safe side, please mark the issue as confidential. We will make
sure that we redact any files before we make the issue public in the future.
BTW is there any chance that you and Havard share any common bits of
configuration?
Thanks,
Ondřej
--
Ondřej Surý — ISC
> On 8 May 2019, at 20:58, Ingeborg Hellemo wrote:
>
> FreeBSD 11.2
> Bind 9.12.3-P1
>
>
> I have a server which runs several nameservers, each in its own chroot with
> its own assigned IP-address.
>
> They run like this:
> /usr/local/sbin/named -4 -t /resolver -u bind -c /etc/namedb/named.conf
>
> In named.conf:
>
> statistics-channels {
>inet port 5 allow { ; };
> };
>
> On my monitoring server I collect statistics via
> http://:5/json
>
>
> Today I added one more chroot. For this server the statistics collection
> crashes the named daemon without any trace in the log files. Even stranger is
> that "http://:5" and "http://:5/xml" works fine.
>
> All the nameservers run the same binary.
>
>
> Any ideas where to look?
>
>
> --Ingeborg
> --
> Ingeborg Østrem Hellemo -- ingeborg.hell...@uit.no
> Dep. of Information Technology --- Univ. of Tromsø
>
>
>
___
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-users Digest, Vol 3172, Issue 4
Hi, I can only second that. The default cc on OpenBSD comes from Precambrian era, so you’ll need to use at least gcc >= 4.8 or clang to fullfill the build requirements - see PLATFORMS.md. We should probably asd a section on OpenBSD to the file and/or better checks to configure, but I always thought it’s a common knowledge that gcc from ports is needed to compile modern software. Ondřej -- Ondřej Surý — ISC > On 28 Apr 2019, at 00:33, bind-users-requ...@lists.isc.org wrote: > > Send bind-users mailing list submissions to >bind-users@lists.isc.org > > To subscribe or unsubscribe via the World Wide Web, visit >https://lists.isc.org/mailman/listinfo/bind-users > or, via email, send a message with subject or body 'help' to >bind-users-requ...@lists.isc.org > > You can reach the person managing the list at >bind-users-ow...@lists.isc.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of bind-users digest..." > Today's Topics: > > 1. Re: Bind 9.14.1 will not build on OpenBSD 6.5 (amd64) (Mik J) > 2. Re: Bind > 9.12 Will Not Start On FreeBSD (Tim Daneliuk) > 3. Re: Bind > 9.12 Will Not Start On FreeBSD (Tim Daneliuk) > 4. Re: Bind > 9.12 Will Not Start On FreeBSD (@lbutlr) > > > > > ___ > 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
Patches to fix isc_atomic_xadd problem (Solaris, HP-UX and other rare CPU architectures)
Hi, when backporting the patch to fix TCP Client Issue a design decision was made to not use stdatomic.h (as used in 9.14+), but rather use the old ISC atomic API that we believed was more compatible with existing user base. Unfortunately, it has slipped our attention that said API lack support for less common CPU architectures. So far, we’ve been made aware about HP-UX, Solaris sparc and various fringe Linux architectures. As immediate remedy to the problem, we are encouraging users to use following patches: # BIND 9.11.6-P1 Patch replacing isc_atomic_xadd with isc_refcount API in BIND 9.11: https://gitlab.isc.org/isc-projects/bind9/merge_requests/1864.patch The patch will be part of next regular BIND 9.11.7 release. If by any chance your compiler doesn’t support GNU extensions, you might also want to apply: https://gitlab.isc.org/isc-projects/bind9/merge_requests/1826 We introduced this as a fix for alignment problem on Solaris, but it broke HP-UX. # BIND 9.12.4-P1 Patch replacing isc_atomic_xadd with isc_refcount API in BIND 9.12.4-P1: https://gitlab.isc.org/isc-projects/bind9/merge_requests/1879.patch Please note that BIND 9.12 has reached EOL and there will be only new release if there’s serious security issue. We hope not. # BIND 9.14.1 For BIND 9.14.1, a patch would be needed only if you are using GCC with only the old atomic intrinsic, but here it is anyway: - https://gitlab.isc.org/isc-projects/bind9/merge_requests/1880.patch I apologise for the inconvenience this has caused for platforms we don’t have support for old atomics. Ondrej -- Ondřej Surý ond...@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: DS record RRSIG
Yes, the whole RRSet is always signed. Signing individual records would not protect against attacks stripping individual records and their RRSIGs. Ondrej -- Ondřej Surý ond...@isc.org > On 2 Jul 2019, at 19:34, Josh Kuo wrote: > > This may not be the right place to ask, if this is a better question asked in > a different list, please let me know. > > I am curious as to how BIND generates and processes DS RRSIG, and this may > not be unique to BIND, since I've seen this behavior across multiple vendors. > From the following: > > $ dig example.com. DS +dnssec +nocrypto > > ; <<>> DiG 9.12.2-P2 <<>> example.com. DS +dnssec +nocrypto > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48102 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;example.com. IN DS > > ;; ANSWER SECTION: > example.com. 84558 IN DS 43547 8 2 [omitted] > example.com. 84558 IN DS 31406 8 1 [omitted] > example.com. 84558 IN DS 31406 8 2 [omitted] > example.com. 84558 IN DS 31589 8 1 [omitted] > example.com. 84558 IN DS 31589 8 2 [omitted] > example.com. 84558 IN DS 43547 8 1 [omitted] > example.com. 84558 IN RRSIG DS 8 2 86400 20190709042256 > 20190702031256 3800 com. [omitted] > > ;; Query time: 228 msec > ;; SERVER: 10.0.22.1#53(10.0.22.1) > ;; WHEN: Wed Jul 03 01:27:42 PST 2019 > ;; MSG SIZE rcvd: 455 > > There are 6 DS records total, but only 1 RRSIG. This leads me to believe that > the single RRSIG is generated by somehow concatenating all DS records > together. This then leads me to believe that the validating resolver needs to > process _all_ DS records, not just the ones whose key tag matches the child > zone's KSK. Is this true? It seems like a small overhead in the grand scheme > of things, but that seems inefficient, if multiple DS records are left at the > parent zone after a couple of key rollovers. > > Any information on this would be appreciated. > > -Josh > ___ > 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: Algorithm roll-over, unexpected content in dsset-file
When there’s no DNSSEC KEY with SEP bit set, the Algo-13 “chain” has single entry point, e.g. Single-Type Signing Scheme (Combined Signing Key), see https://tools.ietf.org/html/rfc6781#section-3.1 and https://tools.ietf.org/html/rfc8499#section-10 I don’t know exactly know what are you trying achieve, but adding only ZSK with new algorithm serves no purpose. Ondřej -- Ondřej Surý — ISC > On 11 Aug 2019, at 12:59, Mark Elkins wrote: > > Hi, Running BIND 9.14.4 on Gentoo. > > I've been running BIND and DNSSEC for a long time. Years ago - I changed from > Algorithm 5 to 8 and am now changing from 8 to 13. > > My ZSK's have a lifetime of 34 days and my KSK a lifetime of 370 days. I've > chosen to create a new ZSK every 17 days and KSK every 185 days - so usually > have two of each per domain. I've 1532 domains in my system, 74 are NSEC and > 54 are NSEC3 - the rest are unsigned. Currently - resigning happens randomly > over the year - which keeps loads (and changes) scattered over the year. Some > parents - I manage via EPP, others have various other methods of updating - > so having the best part of six month to do a key-rollover has its advantages. > > I've just started allowing the system to add Algo-13 Keys... and this is what > I see: > > 1 - Created a test zone file: contains enough to be legal. > > 2 - Created some old keys, one ZSK and one KSK - Signed the domain and looked > inside the "dsset-" file > # vi db.foo.com > # dnssec-keygen -a RSASHA256 foo.com > # dnssec-keygen -a RSASHA256 -f KSK foo.com > # cat Kfoo.com.*.key >> db.foo.com > # dnssec-signzone -a -o foo.com db.foo.com > # cat dsset-foo.com. > foo.com.IN DS 62014 8 1 6CFC9114C7D0954195C01B488C3B8D6E1BD0F220 > foo.com.IN DS 62014 8 2 > 74112FE6AE6E9DFB5A00EB3C26397E92CAA27038FA176A9B4B67D9FE 4E0154FE > (perfect!) > > 3 - created one additional ZSK - Algo 13, add that to the zone and resigned. > > # dnssec-keygen -a ECDSAP256SHA256 foo.com > # cat Kfoo.com.+013+34805.key >> db.foo.com > > # dnssec-signzone -a -o foo.com db.foo.com > Verifying the zone using the following algorithms: RSASHA256. > Missing self-signed KSK for algorithm ECDSAP256SHA256 > The zone is not fully signed for the following algorithms: ECDSAP256SHA256. > DNSSEC completeness test failed. > Zone verification failed (failure) > > I don't mind the failure - after all there is no complete Algo-13 chain - but > the existing Algo-8 chain is complete. Interestingly, the signed zone > contains no mention of the Algo-13 ZSK. No problem. > > However - WTF is a ZSK doing in the dsset file??? Is this a bug? > > # cat dsset-foo.com. > foo.com.IN DS 34805 13 1 A040C7BC6C03778B20AD4A3AEE3BC0648CE8AC23 > foo.com.IN DS 34805 13 2 > 340DC924A523CAD49E5C22357BBFECC07A2944D7723AD8F44DCE5332 FACD3AB2 > foo.com.IN DS 62014 8 1 6CFC9114C7D0954195C01B488C3B8D6E1BD0F220 > foo.com.IN DS 62014 8 2 > 74112FE6AE6E9DFB5A00EB3C26397E92CAA27038FA176A9B4B67D9FE 4E0154FE > > 4 - If I then add an algo-13 KSK, add it to the Zone and run signzone - > everything looks good again... > > (New KSK) foo.com. IN DNSKEY 257 3 13 > pD6yMHdPCKmLj0hY8oiLA1F2Vdb8a1LgpzU8XiO2c6eIh16n1Dv2Vogc > 9WylTUjOLTZlhRXPDmAcIUTyBUuC2Q== > # dnssec-signzone -a -o foo.com db.foo.com > Verifying the zone using the following algorithms: RSASHA256 ECDSAP256SHA256. > Zone fully signed: > Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked > ZSKs: 1 active, 0 stand-by, 0 revoked > Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked > ZSKs: 1 active, 0 stand-by, 0 revoked > db.foo.com.signed > # cat dsset-foo.com. > foo.com.IN DS 23294 13 1 AADE5856B8EB3BB946DAAD2804A735816B3B3132 > foo.com.IN DS 23294 13 2 > 7FD5F02A2E52A1C6E3DEBD54C05A9A974CE88FA78548E3644B36FA2D 27E0F910 > foo.com.IN DS 62014 8 1 6CFC9114C7D0954195C01B488C3B8D6E1BD0F220 > foo.com.IN DS 62014 8 2 > 74112FE6AE6E9DFB5A00EB3C26397E92CAA27038FA176A9B4B67D9FE 4E0154FE > > I really don't like the bad ZSK DS record in dsset because I currently use > that info to build CDS records in to my Database - which is used to verify > when the DS record is seen in the parent. Anyway - I think this is a bug in > the code of dnssec-signzone. > > I'm trying to wait as long as possible before forcibly creating Algo-13 KSK's > in the hope that they will be created according to the existing schedule. If > the Second Algo-13 ZSK is to be created in under 3 days - then I'll replace > the oldest KSK with an Algo-13 KSK. > > -- > Mark James ELKINS - Posix Systems - (South) Afr
Re: BIND 9.11.9-1+ubuntu18.04.1+deb.sury.org+2 crash
Hi Emmanuel, the crash should not happen because the discrepancy between the GeoIP and GeoIP2 configurations should have been caught earlier, so I would appreciate if you can submit an issue here: https://gitlab.isc.org/isc-projects/bind9/issues with more details on you named.conf. You can use named-checkconf -px to clean any sensitive data, and/or make sure you mark the issue as confidential if there’s still data you don’t want to be seen by general public. We’ll sanitize the issue later. That said - the 9.11.9-1+ubuntu18.04.1+deb.sury.org+2 backport has missed one important commit that disables legacy GeoIP and enables GeoIP2, and I’ve just uploaded version 3+geoip2 to the Ubuntu repositories, so could you please try again with the recompiled version? It should fix the INSIST() that you were hitting. If that fixes your issue, we would still appreciate if you would create the issue, so we can make BIND fail more gracefully that with an crash if there’s error in the configuration related to the switch between GeoIP and GeoIP2. Thank you, Ondrej -- Ondřej Surý ond...@isc.org > On 25 Jul 2019, at 05:51, FUSTE Emmanuel > wrote: > > The new version crash and the BIND 9.11.8-1+ubuntu18.04.1+deb.sury.org+1 > was pulled from the repo. > I'm trying the 9.14.4-1 as I need to resume the service but I have > GeoIP2 migration problems. > Please re-push the previous version in the repo. > > Emmanuel. > > Jul 25 10:54:08 ns1 systemd[1]: Reloading. > Jul 25 10:54:08 ns1 systemd[1]: message repeated 2 times: [ Reloading.] > Jul 25 10:54:08 ns1 systemd[1]: Starting BIND Domain Name Server... > Jul 25 10:54:08 ns1 named[32210]: starting BIND > 9.11.9-1+ubuntu18.04.1+deb.sury.org+2-Ubuntu (Extended Support Version) > > Jul 25 10:54:08 ns1 named[32210]: running on Linux x86_64 4.15.0-54-generic > #58-Ubuntu SMP Mon Jun 24 10:55:24 UTC 2019 > Jul 25 10:54:08 ns1 named[32210]: built with '--build=x86_64-linux-gnu' > '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' > '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' > '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' > '--libexecdir=/usr/lib/x86_64-linux-gnu' '--disable-maintainer-mode' > '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' > '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' > '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' > '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' > '--with-libidn2' '--with-libjson=/usr' '--with-lmdb=/usr' '--with-gnu-ld' > '--with-geoip=/usr' '--with-atf=no' '--enable-ipv6' '--enable-rrl' > '--enable-filter-' '--enable-native-pkcs11' > '--with-pkcs11=/usr/lib/softhsm/libsofthsm2.so' > '--with-randomdev=/dev/urandom' '--enable-dnstap' > 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind > 9-aM_dmU/bind9-9.11.9+dfsg=. -fstack-protector-strong -Wformat > -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks > -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions > -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' > Jul 25 10:54:08 ns1 named[32210]: running as: named -4 -u bind > Jul 25 10:54:08 ns1 named[32210]: compiled by GCC 7.4.0 > Jul 25 10:54:08 ns1 named[32210]: compiled with OpenSSL version: OpenSSL > 1.1.1 11 Sep 2018 > Jul 25 10:54:08 ns1 named[32210]: linked to OpenSSL version: OpenSSL 1.1.1 > 11 Sep 2018 > Jul 25 10:54:08 ns1 named[32210]: compiled with libxml2 version: 2.9.4 > Jul 25 10:54:08 ns1 named[32210]: linked to libxml2 version: 20904 > Jul 25 10:54:08 ns1 named[32210]: compiled with libjson-c version: 0.12.1 > Jul 25 10:54:08 ns1 named[32210]: linked to libjson-c version: 0.12.1 > Jul 25 10:54:08 ns1 named[32210]: compiled with zlib version: 1.2.11 > Jul 25 10:54:08 ns1 named[32210]: linked to zlib version: 1.2.11 > Jul 25 10:54:08 ns1 named[32210]: threads support is enabled > Jul 25 10:54:08 ns1 named[32210]: > > Jul 25 10:54:08 ns1 named[32210]: BIND 9 is maintained by Internet Systems > Consortium, > Jul 25 10:54:08 ns1 named[32210]: Inc. (ISC), a non-profit 501(c)(3) > public-benefit > Jul 25 10:54:08 ns1 named[32210]: corporation. Support and training for BIND > 9 are > Jul 25 10:54:08 ns1 named[32210]: available athttps://www.isc.org/support > Jul 25 10:54:08 ns1 named[32210]: > > Jul 25 10:54:08 ns1 named[32210]: adjusted limit on open files from 4096 to > 1048576 > Jul 25 10:54:08 ns1 named[32210]: found 4 CPUs, using 4 worker threads > Jul 25 10:54:08 ns1 named[32210]: using 3 UDP listeners per interface > Jul 2
Re: BIND 9.11.9-1+ubuntu18.04.1+deb.sury.org+2 crash
The issue was caused by using GeoIP2 configuration with BIND 9.11 compiled with legacy GeoIP, so there’s no need to test it on your side. We are just missing the combination of the options that you have used that caused this, thus the issue. We would be able to test it ourselves then. Thank you, Ondrej -- Ondřej Surý ond...@isc.org > On 25 Jul 2019, at 07:40, FUSTE Emmanuel > wrote: > > Le 25/07/2019 à 12:56, Ondřej Surý a écrit : >> Hi Emmanuel, >> >> the crash should not happen because the discrepancy between the GeoIP and >> GeoIP2 configurations >> should have been caught earlier, so I would appreciate if you can submit an >> issue here: >> https://gitlab.isc.org/isc-projects/bind9/issues with more details on you >> named.conf. >> >> You can use named-checkconf -px to clean any sensitive data, and/or make >> sure you mark the >> issue as confidential if there’s still data you don’t want to be seen by >> general public. We’ll sanitize >> the issue later. >> >> That said - the 9.11.9-1+ubuntu18.04.1+deb.sury.org+2 backport has missed >> one important commit >> that disables legacy GeoIP and enables GeoIP2, and I’ve just uploaded >> version 3+geoip2 to the >> Ubuntu repositories, so could you please try again with the recompiled >> version? It should fix the >> INSIST() that you were hitting. >> >> If that fixes your issue, we would still appreciate if you would create the >> issue, so we can make >> BIND fail more gracefully that with an crash if there’s error in the >> configuration related to the >> switch between GeoIP and GeoIP2. >> >> Thank you, >> Ondrej >> -- >> Ondřej Surý >> ond...@isc.org >> >> > Hello Ondrej, > > Thank you for your quick reply. > I will create the issue shortly. > As explained in my followup message, it is now very difficult for me to > test the updated package. I will try to find a way to test/validate it > as time permit. > > Thank you > Emmanuel. ___ 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: DDNS with extra vhosts...
Hi John, like * foo.example.org. IN CNAME foo.example.org. for each host? If that’s not the case you’ll have to be more specific and less vague about your configuration... Ondrej -- Ondřej Surý — ISC > On 29 Sep 2019, at 19:22, John Robson via bind-users > wrote: > > > Hi all, > > I've set up both ISC dhcpd and ISC bind to provide relevant services to a > virtualised test lab. In the test lab obviously boxes will be brought up and > down fairly frequently, and I'm aiming to minimise the amount of effort that > this takes our users. > > So - the machines get an IP address and dhcpd updates bind, so a specific > internal domain gets updated - let's use example.orghere for ease of reading. > > That all works (after a little fight with permissions). > I set up a machine with a hostname of 'foo' and there is an automagic DNS > entry `foo.example.org`. > > BUT - what I'd like to do is have `*.foo.example.org` (or even a specific > listing of subdomains) point to that IP as well - to enable the various vhost > based services on the test machines to be accessed without having to mess > with local hosts files or further mess with DNS each time. > > e.g. test.foo.example.org should point to the same IP as foo.example.org > (heck, could even be a cname) > > Is there some simple configuration I am missing - or is this not possible? > Is there a better way to get to where I want to be*? > > Cheers, > > John > > > * Previously we had all the test boxes in one /24, so we had `lab123` for the > box whose IP ended in 123... but we're now in a /23, and that gets a lot > messier to handle with fixed names (not particularly keen on the idea of > test341 being for the top half ending in 341-256=85 - nor am I keen on 5 > digit test ids...) > > -- > John Robson > > ___ > 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: Can i remove @0x in my log query message, bind 9.11
Or patch the old version instead. -- Ondřej Surý — ISC > On 4 Nov 2019, at 15:14, Alan Clegg wrote: > > On 11/4/2019 5:57 AM, Tony Finch wrote: >> Nguyen Huy Bac wrote: >>> So, my question is: Can and How to remove @0x in my >>> log query message. >> There is no convenient way. You have to apply this patch: >> diff --git a/lib/ns/client.c b/lib/ns/client.c >> index f16ece8c49..7861f12084 100644 >> --- a/lib/ns/client.c >> +++ b/lib/ns/client.c >> @@ -4066,8 +4066,8 @@ ns_client_logv(ns_client_t *client, isc_logcategory_t >> *category, >> } >> isc_log_write(ns_lctx, category, module, level, >> - "client @%p %s%s%s%s%s%s%s%s: %s", >> - client, peerbuf, sep1, signer, sep2, qname, sep3, >> + "client %s%s%s%s%s%s%s%s: %s", >> + peerbuf, sep1, signer, sep2, qname, sep3, >>sep4, viewname, msgbuf); >> } > > While this patch does what it says, it doesn't mention the fact that all > versions of BIND for the foreseeable future are going to have this additional > field (it's in all currently supported versions of BIND), so you will be MUCH > better off fixing the software that is ingesting the log file than to patch > BIND every time you upgrade. > > AlanC > > ___ > 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: Query failed (timed out)
Hi Wilfred,
BIND is not broken as Mark already pointed out, so we have no plan on fixing
this.
The DNS load-balancers (most probably) that Barclays has deployed need to be
fixed to be RFC compliant.
Not to mention that dropping the queries is always **BAD** as it opens a bigger
window to spoofing attacks for off-path attacker.
Ondrej
--
Ondřej Surý
ond...@isc.org
> On 6 Nov 2019, at 09:18, Wilfred Sarmiento via bind-users
> wrote:
>
> Hi Mark,
>
> The workaround works very well, i also got the same response from Daniel of
> Switch.
>
> Thank you very much!
> Wil
>
>
> On Wed, Nov 6, 2019 at 3:52 PM Mark Andrews wrote:
> The DNS servers for federate-secure.glbaa.barclays.com are *broken* which
> is what federate.secure.barclays.com points to. They do not respond to
> queries with EDNS options present and named sends a DNS COOKIE EDNS option
> by default.
>
> You can work around this by specifying
>
> server 157.83.102.245 { send-cookie no; };
>
> and similarly for all the other IP addresses of the GLB but the real fix
> is for Barclays to deploy RFC compliant DNS servers. Their servers nominally
> support EDNS and unknown EDNS options are supposed to be ignored, not cause
> the query to be dropped.
>
> % dig federate-secure.glbaa.barclays.com +nocookie @157.83.102.245
>
> ; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>>
> federate-secure.glbaa.barclays.com +nocookie @157.83.102.245
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62156
> ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;federate-secure.glbaa.barclays.com. IN A
>
> ;; ANSWER SECTION:
> federate-secure.glbaa.barclays.com. 30 IN A 157.83.124.48
>
> ;; Query time: 356 msec
> ;; SERVER: 157.83.102.245#53(157.83.102.245)
> ;; WHEN: Wed Nov 06 18:49:20 AEDT 2019
> ;; MSG SIZE rcvd: 79
>
> % dig federate-secure.glbaa.barclays.com @157.83.102.245
>
> ; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>>
> federate-secure.glbaa.barclays.com @157.83.102.245
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
>
> [beetle:~/git/bind9] marka% dig federate-secure.glbaa.barclays.com +nocookie
> @157.83.102.245
>
> ; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>>
> federate-secure.glbaa.barclays.com +nocookie @157.83.102.245
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20094
> ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;federate-secure.glbaa.barclays.com. IN A
>
> ;; ANSWER SECTION:
> federate-secure.glbaa.barclays.com. 30 IN A 157.83.124.48
>
> ;; Query time: 383 msec
> ;; SERVER: 157.83.102.245#53(157.83.102.245)
> ;; WHEN: Wed Nov 06 18:50:19 AEDT 2019
> ;; MSG SIZE rcvd: 79
>
> %
>
>
> > On 6 Nov 2019, at 18:32, Wilfred Sarmiento via bind-users
> > wrote:
> >
> > Hi Bind Users,
> >
> > Anyone have a similar issue we are encountering with the subdomain of
> > Barclays.com specifically federate.secure.barclays.com
> > Our cache server could not resolve the said subdomain, but was able to
> > resolve their root domain barclays.com and any other known domains.
> > Debug just showed below little details of logs.
> > That subdomain was resolvable using Google DNS and other OpenDNS.
> >
> > client @0x7f6a14a7b6a0 xxx.xxx.xxx.xxx#63852
> > (federate.secure.barclays.com): query: federate.secure.barclays.com IN A +
> > (x.x.x.x)
> > client @0x7f6a4a4cd070 xxx.xxx.xxx.xxx#63852
> > (federate.secure.barclays.com): query: federate.secure.barclays.com IN A +
> > (x.x.x.x)
> > client @0x7f6a14a7b6a0 xxx.xxx.xxx.xxx#63852
> > (federate.secure.barclays.com): query failed (timed out) for
> > federate.secure.barclays.com/IN/A at query.c:6786
> > client @0x7f6a31216e30 xxx.xxx.xxx.xxx#63852
> > (federate.secure.barclays.com): query: federate.secure.barclays.com IN A +
> > (x.x.x.x)
> > client @0x7f6a31216e30 xxx.xxx.xxx.xxx#63852
> > (federate.secure.barclays.com): query failed (timed out) for
> > federate.secure.barclays.com/IN/A at query.c:6786
> >
> > Thank you,
> > Wil
> >
> &
BIND 9 Windows 32-bit deprecation
Dear BIND 9 Users, We would like to announce proposed changes that affect 32-bit Windows platform. In accordance with our published policy on removing features (https://kb.isc.org/docs/policy-for-removing-namedconf-options), we are giving notice that we plan to gradually wind down our support for the Windows 32-bit operating system as follows: Starting in December 2019, we will stop providing binary packages for Windows 32-bit for BIND 9.11 ESV and BIND 9.14. Note that you can still compile BIND 9.11 on Windows 32-bit yourself. We will continue to support BIND 9.11 and BIND 9.14 on the Windows 32-bit until those versions EOL. BIND 9.16 will become our next ESV after BIND 9.11 is EOL. ISC will not provide Windows 32-bit binary packages for BIND 9.16. We will also not take Windows 32-bit into consideration when fixing bugs or backporting important features, so we do not guarantee that BIND will continue to be usable on that platform. We will actively remove the support for Windows 32-bit target platform in BIND 9.17 and beyond, so it will not be usable. if you are using BIND on Windows 32 and this timeline will cause you difficulty, please let us know. Regards, Ondřej ___ 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: [patch] GNU/Hurd fixes
Samuel, thanks for the patch. Two remarks - if you don’t mind, submitting patches via gitlab.isc.org is generally preferred, I just have to increase a project limit for new contributors. For the patch - I would prefer to have this stuff in lib/isc/include/platform.h(.in) and include the header instead of scattering the defines all over the place. (BTW I never understand the Hurd stubbornness of ignoring the PATH_MAX and forcing all random projects to adjust the code while it could be solved in the system headers...) Ondřej -- Ondřej Surý — ISC > On 10 Nov 2019, at 18:02, Samuel Thibault > wrote: > > Hello, > > Here is a fix for GNU/Hurd builds. GNU/Hurd does not have limitations > such as PATH_MAX/IOV_MAX. bind9 already uses its own default limitations > in a few other files, here is an update. > > Samuel > > ___ > 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: How to set up a dmarc record ?
Hi Edouard, I would start by **not** anonymizing domains you want to help with. What’s the point of using my-domain.fr anyway? $ dig +short IN TXT pasteur-cayenne.fr "v=spf1 a mx -all" There’s no shame in having a problem you can’t solve yourself. We’ve all been there. Disguising the real domain is very often misleading and prevents other people from helping you. I would start by checking the correctness of the zone file (with named-checkzone) and making sure you bumped the serial number in SOA and you reloaded the zone. Ondrej -- Ondřej Surý ond...@isc.org > On 10 Dec 2019, at 13:56, Edouard Guigné wrote: > > Dear all, > > I am using bind 9.11.4-9.P2 installed on a centos 7 with yum. > > I am seting dkim and dmarc record for a mail server. > > I succeeded to set the dkim record ( a test with # dig txt + short ... works) > > But I am stucked with dmarc record. > I filled my zone file like this : > > ... > $ORIGIN my-domain.fr. > ... > @ 86400IN TXT "v=spf1 a mx -all" > > selector._domainkey IN IN TXT ( "v=DKIM1; k=rsa; " > "p=..." ) > > _dmarc IN TXT "v=DMARC1; p=none; rua=mailto:dm...@my-domain.fr; pct=5; > sp=none; aspf=r" > ... > > A test with the dig command does not give answer : > # dig txt +short _dmarc.my-domain.fr > > May someone help me to make it works ? > > Best Regards, > > EdG > > ___ > 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: How to set up a dmarc record ?
Also the record on the next line looks suspicious: IN NS ara.pasteur-cayenne.fr. As you delegated the whole subdomain to ara.p-c.fr again: $ dig IN TXT _dmarc.pasteur-cayenne.fr.pasteur-cayenne.fr. @ara.pasteur-cayenne.fr. ; <<>> DiG 9.11.8 <<>> IN TXT _dmarc.pasteur-cayenne.fr.pasteur-cayenne.fr. @ara.pasteur-cayenne.fr. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52693 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 35c43e4d3150d78270cae65e5defa16cbf8158df5e59c89c (good) ;; QUESTION SECTION: ;_dmarc.pasteur-cayenne.fr.pasteur-cayenne.fr. IN TXT ;; AUTHORITY SECTION: _dmarc.pasteur-cayenne.fr.pasteur-cayenne.fr. 3600 IN NS ara.pasteur-cayenne.fr. ;; ADDITIONAL SECTION: ara.pasteur-cayenne.fr. 3600IN A 186.2.246.17 ;; Query time: 192 msec ;; SERVER: 186.2.246.17#53(186.2.246.17) ;; WHEN: Tue Dec 10 14:45:16 CET 2019 ;; MSG SIZE rcvd: 135 I don’t think it was an intent. Ondrej -- Ondřej Surý ond...@isc.org > On 10 Dec 2019, at 14:37, Niall O'Reilly wrote: > > On 10 Dec 2019, at 13:30, Edouard Guigné wrote: > >> ; DMARC >> _dmarc.pasteur-cayenne.fr IN TXT ( "v=DMARC1; p=none; " >> >> "rua=[mailto:dm...@pasteur-cayenne.fr](<mailto:dm...@pasteur-cayenne.fr>); >> pct=5; " >> "sp=none; aspf=r" ) > > Instead of "_dmarc.pasteur-cayenne.fr", you should put "_dmarc", > leaving out ".pasteur-cayenne.fr", just as you did for the DKIM > record. > > Niall O'Reilly > ___ > 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: What is wrong in the view matching below
There’s a space after com
O.
--
Ondřej Surý
ond...@isc.org
> On 5 Dec 2019, at 13:29, Sten Carlsen wrote:
>
>>
>> zone "internal.nixcraft.com " IN {
>> type master;
>> file "lan.master.nixcraft.com";
>> };
>> };
>
> Looks like the file lan.master.nixcraft.com has no data.
>
>>
>> Dec 05 17:51:54 sataradnsVM1 named[4038]: zone
>> internal.nixcraft.com\032/IN/internal: has 0 SOA records
>> Dec 05 17:51:54 sataradnsVM1 named[4038]: zone
>> internal.nixcraft.com\032/IN/internal: has no NS records
>> Dec 05 17:51:54 sataradnsVM1 named[4038]: zone
>> internal.nixcraft.com\032/IN/internal: not loaded due to errors.
>>
>> Please help
>>
>> Thanks
>>
>> ___
>> 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
___
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 -> subdomains -> keys
It is certainly possible, but it requires some manual changes to the respective public and private key files to match the zones. But I would concur with Chuck that the benefit from doing so is nonexistent and unless you have specific strong reasons to do so, it’s better to have a separate key-pair for every signed zone. Ondrej -- Ondřej Surý — ISC > On 7 Dec 2019, at 18:36, Chuck Aurora wrote: > > On 2019-12-07 08:24, Elimar Riesebieter wrote: >> is it possible to have one key pair for DNSSEC to sign subdomains in >> different zonefiles? > > IIUC how it works, the generation of a key pair includes the zone name, > so no, I do not think it is possible. Also, and more to the point, > there's no benefit to what you are asking. > > What is the problem you are hoping to solve? If we know that perhaps > we can suggest something else. > ___ > 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: How to set up a dmarc record ?
Well, I already told you what’s wrong and you ignored that part. Please read it again and understand what it means to delegate a part of the zone. Your problems are not specific to BIND 9, it’s just your zone file is wrong. Ondrej -- Ondřej Surý — ISC > On 10 Dec 2019, at 17:43, Edouard Guigné via bind-users > wrote: > > > Hello, > > What is wrong with my file zone ? > Why espcially for _dmarc IN TXT > I cannot get the ANSWER SECTION with a dig command ? > > Best Regards, > > Ed > > Message transféré > Sujet : Re: How to set up a dmarc record ? > Date :Tue, 10 Dec 2019 11:51:47 -0300 > De : Edouard Guigné via bind-users > Répondre à : Edouard Guigné > Pour :bind-users@lists.isc.org >> bind-users > > > > Hello, > > I changed to "_dmarc" instead of "_dmarc.pasteur-cayenne.fr" > _dmarc IN TXT ( "v=DMARC1; p=none; " > "rua=mailto:dm...@pasteur-cayenne.fr; pct=5; " > "sp=none; aspf=r" ) > > My zone file is updated : > # named-checkzone pasteur-cayenne.fr /var/named/external/db.pasteur-cayenne.fr > zone pasteur-cayenne.fr/IN: loaded serial 2019120810 > OK > > But It still does not give the dmarc ANSWER SECTION expected : > # dig IN txt _dmarc.pasteur-cayenne.fr. @ara.pasteur-cayenne.fr. > > ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> IN txt > _dmarc.pasteur-cayenne.fr. @ara.pasteur-cayenne.fr. > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4753 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;_dmarc.pasteur-cayenne.fr. IN TXT > > ;; AUTHORITY SECTION: > _dmarc.pasteur-cayenne.fr. 3600 IN NS ara.pasteur-cayenne.fr. > > ;; ADDITIONAL SECTION: > ara.pasteur-cayenne.fr. 3600IN A 186.2.246.17 > > ;; Query time: 0 msec > ;; SERVER: 186.2.246.17#53(186.2.246.17) > ;; WHEN: mar. déc. 10 11:42:21 -03 2019 > ;; MSG SIZE rcvd: 88 > > > > > > Le 10/12/2019 à 10:46, Ondřej Surý a écrit : >> Also the record on the next line looks suspicious: >> >> IN NS ara.pasteur-cayenne.fr. > I am very sorry because I am not very used with bind. > > "ara" is the primary DNS for internet. > > Is this line redundant with the line before ? >NS ara.pasteur-cayenne.fr. > > > >> As you delegated the whole subdomain to ara.p-c.fr again: >> >> >> $ dig IN TXT _dmarc.pasteur-cayenne.fr.pasteur-cayenne.fr. >> @ara.pasteur-cayenne.fr. >> >> ; <<>> DiG 9.11.8 <<>> IN TXT _dmarc.pasteur-cayenne.fr.pasteur-cayenne.fr. >> @ara.pasteur-cayenne.fr. >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52693 >> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2 >> ;; WARNING: recursion requested but not available >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ; COOKIE: 35c43e4d3150d78270cae65e5defa16cbf8158df5e59c89c (good) >> ;; QUESTION SECTION: >> ;_dmarc.pasteur-cayenne.fr.pasteur-cayenne.fr. IN TXT >> >> ;; AUTHORITY SECTION: >> _dmarc.pasteur-cayenne.fr.pasteur-cayenne.fr. 3600 IN NS >> ara.pasteur-cayenne.fr. >> >> ;; ADDITIONAL SECTION: >> ara.pasteur-cayenne.fr. 3600IN A 186.2.246.17 >> >> ;; Query time: 192 msec >> ;; SERVER: 186.2.246.17#53(186.2.246.17) >> ;; WHEN: Tue Dec 10 14:45:16 CET 2019 >> ;; MSG SIZE rcvd: 135 >> >> I don’t think it was an intent. >> >> Ondrej >> -- >> Ondřej Surý >> ond...@isc.org >> >>>> On 10 Dec 2019, at 14:37, Niall O'Reilly wrote: >>>> >>>> On 10 Dec 2019, at 13:30, Edouard Guigné wrote: >>>> >>>> ; DMARC >>>> _dmarc.pasteur-cayenne.fr IN TXT ( "v=DMARC1; p=none; " >>>> >>>> "rua=[mailto:dm...@pasteur-cayenne.fr](<mailto:dm...@pasteur-cayenne.fr>); >>>> pct=5; " >>>> "sp=none; aspf=r" ) >>> Instead of "_dmarc.pasteur-cayenne.fr", you should put "_dmarc", >>> leaving out ".pasteur-cayenne.fr", just as you did for the DKIM >>> record. >>> >>> Niall O'Reilly >>> ___ >>> 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 ___ 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-Efficientip
(This post is not related to EfficientIP specifically...) The ratio of security vulnerabilities found by “code inspection” is really low nowadays. I would even say it’s nonexistent. This doesn’t apply only to BIND 9, but also other open source projects. Most of the issues are found by using the product in non expected ways. The open source gives you the ability to quickly fix the issue. We, at ISC, greatly value transparency and we carefully evaluate every issue for potential security impact of every crash and other issues. Whether this makes BIND 9 more appealing or appalling to you, is a thing you need to decide yourself. I’ve been part of the open source community for more than 20 years now and I don’t ever remember where security by obscurity has ever improved overall state of things, and both open source and proprietary software have seen its share of bugs. In the end, all we as software users can ask is to be treated fairly and honestly. Ondřej -- Ondřej Surý — ISC > On 21 Oct 2019, at 18:01, Kevin Darcy wrote: > > But, it's harder for the bad guys to find. They have to use fuzzing, reverse > engineering, etc. ___ 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: named 9.14.6 memory leak, cannot start
Hi Peter, we had a similar report in the past, so maybe you can chime in and add the information to the issue here https://gitlab.isc.org/isc-projects/bind9/issues/1179 ? That would be helpful... Ondrej -- Ondřej Surý ond...@isc.org > On 16 Oct 2019, at 01:32, Peter wrote: > > > When starting named 9.14.6, before doing any activity it immediately > grows infinitely, hits the system limits and crashes with: > >> mem.c:710: fatal error: >> malloc failed: Cannot allocate memory >> exiting (due to fatal error in library) > > Version 9.14.3 does not have this memory leak and runs flawlessly > (with 100MB VSZ). > > > Here are the detailled messages: > > starting BIND 9.14.6 (Stable Release) > running on FreeBSD i386 11.3-RELEASE-p3 FreeBSD 11.3-RELEASE-p3 #0 >r351611M#N348:361: Fri Aug 30 04:59:55 UTC 2019 > built with '--localstatedir=/var' '--disable-linux-caps' > '--with-libxml2=/usr/local' > '--with-readline=-L/usr/local/lib -ledit' > '--with-dlopen=yes' '--with-openssl=/usr' > '--sysconfdir=/usr/local/etc/namedb' '--with-dlz-filesystem=yes' > '--disable-dnstap' '--disable-fixed-rrset' '--without-geoip2' > '--with-gssapi=/usr' 'KRB5CONFIG=/usr/bin/krb5-config' > '--with-libidn2=/usr/local' '--without-libjson' > '--disable-largefile' '--without-lmdb' '--disable-native-pkcs11' > '--without-python' '--disable-querytrace' > 'STD_CDEFINES=-DDIG_SIGCHASE=1' '--enable-tcp-fastopen' > '--with-tuning=default' '--disable-symtable' '--prefix=/usr/local' > '--mandir=/usr/local/man' '--infodir=/usr/local/share/info/' > '--build=i386-portbld-freebsd11.3' > 'build_alias=i386-portbld-freebsd11.3' 'CC=cc' 'CFLAGS=-O2 -pipe > -march=pentium3 -DLIBICONV_PLUG -fstack-protector-strong -isystem > /usr/local/include -fno-strict-aliasing ' 'LDFLAGS= > -fstack-protector-strong ' 'LIBS=-L/usr/local/lib' > 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp' > 'PKG_CONFIG=pkgconf' > running as: named -t /var/named -u bind -c /usr/local/etc/namedb/named.conf > compiled by CLANG 4.2.1 Compatible FreeBSD Clang 8.0.0 > (tags/RELEASE_800/final 356365) > compiled with OpenSSL version: OpenSSL 1.0.2s-freebsd 28 May 2019 > linked to OpenSSL version: OpenSSL 1.0.2s-freebsd 28 May 2019 > compiled with libxml2 version: 2.9.9 > linked to libxml2 version: 20909 > compiled with zlib version: 1.2.11 > linked to zlib version: 1.2.11 > > BIND 9 is maintained by Internet Systems Consortium, > Inc. (ISC), a non-profit 501(c)(3) public-benefit > corporation. Support and training for BIND 9 are > available at https://www.isc.org/support > > mem.c:710: fatal error: > malloc failed: Cannot allocate memory > exiting (due to fatal error in library) > > > This is 9.14.3: > > starting BIND 9.14.3 (Stable Release) > running on FreeBSD i386 11.3-RELEASE-p3 FreeBSD 11.3-RELEASE-p3 #0 > r351611M#N348:361: Fri Aug 30 04:59:55 UTC 2019 > built with '--localstatedir=/var' '--disable-linux-caps' > '--with-libxml2=/usr/local' '--with-readline=-L/usr/local/lib -ledit' > '--with-dlopen=yes' '--with-openssl=/usr' > '--sysconfdir=/usr/local/etc/namedb' '--with-dlz-filesystem=yes' > '--disable-dnstap' '--disable-fixed-rrset' '--with-ssapi=/usr' > 'KRB5CONFIG=/usr/bin/krb5-config' '--with-libidn2=/usr/local' > '--without-libjson' '--disable-largefile' '--without-lmdb' > '--disable-native-pkcs11' '--without-python' '--disable-querytrace' > 'STD_CDEFINES=-DDIG_SIGCHASE=1' '--enable-tcp-fastopen' > '--with-tuning=default' '--disable-symtable' '--prefix=/usr/local' > '--mandir=/usr/local/man' '--infodir=/usr/local/share/info/' > '--build=i386-portbld-freebsd11.3' > 'build_alias=i386-portbld-freebsd11.3' 'CC=cc' 'CFLAGS=-O2 -pipe > -march=pentium3 -DLIBICONV_PLUG -fstack-protector-strong -isystem > /usr/local/include -fno-strict-aliasing ' 'LDFLAGS= > -fstack-protector-strong ' 'LIBS=-L/usr/local/lib' > 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp' > 'PKG_CONFIG=pkgconf' > running as: named -t /var/named -u bind -c /usr/local/etc/namedb/named.conf > compiled by CLANG 4.2.1 Compatible FreeBSD Clang 8.0.0 > (tags/RELEASE_800/final 356365) > compiled with OpenSSL version: OpenSSL 1.0.2s-freebsd 28 May 2019 > linked to OpenSSL version: OpenSSL 1.0.2s-freebsd 28 May 2019 > compiled with libxml2 version: 2.9.9 > linked to libxml2 version: 20909 > compiled with zlib version: 1.2.11 > linked to zlib version: 1.2.11 > > BIND 9 is maintained by Internet Systems Consortium, > Inc. (ISC), a non-
Re: Zoneformat
Neither analogy would work to the detail here. But search domains is the butt
dial of DNS…
You are better if you don’t use it as it works well until it doesn’t and you
send your data to the wrong party.
Ondrej
> On 28 Oct 2019, at 17:01, Paul Kosinski via bind-users
> wrote:
>
> "... long ago adapted to using full numbers, including area codes, for
> pretty much *all* phone dialing ..."
>
> Except that that proved to be so onerous that people often use "speed
> dialing" for commonly dialed numbers. (Not to mention the fact that
> people usually address their friends and coworkers by short names.)
>
>
> On Mon, 28 Oct 2019 12:19:35 -0400
> Kevin Darcy wrote:
>
>> [ Classification Level: PUBLIC ]
>>
>> My opinion? It's better to wean your users away from shortnames than
>> to try to cobble together kludges, on the client side or the BIND
>> side, to support a bad habit. Shortnames introduce ambiguity, lead to
>> nasty surprises, are inefficient and insecure. Just like we (in the
>> U.S. at least) long ago adapted to using full numbers, including area
>> codes, for pretty much *all* phone dialing, people can adapt to using
>> FQDNs. They've already adapted to it, overwhelmingly, for Internet
>> web traffic (notwithstanding some "helpful" browsers that will tack
>> on "www" to the front of a shortname, and ".com" at the end, which is
>> often *not* what is wanted or safe). Why have a different user
>> experience, when on or off the enterprise network, a perimeter that
>> is quickly eroding? Just use FQDNs everywhere, keep it consistent.
>>
>> Anyway, that's my 2-cents, from someone who has been battling the
>> "shortname disease" for decades, with a substantial amount of
>> (although not perfect) success.
>>
>>
>> - Kevin
>>
>> On Mon, Oct 28, 2019 at 8:56 AM MEjaz wrote:
>>
>>> Noxexistent domain error .
>>>
>>> Here is my configuration.
>>> ===
>>>
>>> zone "crm365app" {
>>> type master;
>>> file "crm365app.cyberia.net.sa.hosts";
>>> allow-query {any;};
>>> };
>>>
>>>
>>> File
>>>
>>>
>>> [root@ns1 ~]# cat /var/named/crm365app.cyberia.net.sa.hosts
>>> $TTL 3600
>>> ; Addresses and other host information
>>> ;
>>> ;
>>>
>>> @ IN SOA ns1.cyberia.net.sa. root.cyberia.net.sa. (
>>> 2015034459 ; serial
>>>43200 ; refresh every 12 hours
>>>4320; retry after 1 hour
>>>1209600 ; expire after 2 weeks
>>>21600 ) ; minimum
>>>
>>> ; Define the name servers and mail servers
>>>
>>>IN NS ns1.cyberia.net.sa.
>>>IN NS ns2.cyberia.net.sa.
>>>
>>>IN MX 10 smtp.cyberia.net.sa.
>>>
>>> ; Define localhost
>>> *INA 127.0.0.1
>>>
>>> ; Define hosts in this zone
>>>
>>>
>>> www IN CNAME webhost.cyberia.net.sa.
>>> crm365app IN A 212.71.33.252
>>>
>>> =zone file
>>> end=
>>>
>>> [root@ns1 named]# host crm365app
>>> Host crm365app not found: 3(NXDOMAIN)
>>> [root@ns1 named]# named-checkzone crm365app
>>> crm365app.cyberia.net.sa.hosts
>>> zone crm365app/IN: loaded serial 2015034459
>>> OK
>>>
>>> -Original Message-
>>> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On
>>> Behalf Of Reindl Harald
>>> Sent: Monday, October 28, 2019 1:46 PM
>>> To: bind-users@lists.isc.org
>>> Subject: Re: Zoneformat
>>>
>>>
>>>
>>> Am 28.10.19 um 11:01 schrieb MEjaz:
*From:* MEjaz [mailto:me...@cyberia.net.sa]
*Sent:* Monday, October 28, 2019 10:27 AM
*To:* 'bind-users-boun...@lists.isc.org'
*Subject:* Zoneformat
Is ther any way I can create the zone without the (.) I mean non
fully qualified domain name just as "example" instead
"example.com"'
>>>
>>>
>>> what is the problem you try to solve?
> ___
> 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: Log rolling stopped working in 9.11.12 ?
Or changes to SELinux policies (since you are running CentOS). Ondrej -- Ondřej Surý ond...@isc.org > On 19 Nov 2019, at 11:49, Mark Andrews wrote: > > There have been no changes. I would be checking directory permissions. > Anything that would > stop rename() succeeding. > >> On 19 Nov 2019, at 08:53, John Thurston wrote: >> >> I recently updated from 9.11.10 to 9.11.12 with the ISC-provided package for >> CentOS 7. Everything looked ok, until today when my monitoring application >> told me I was running out of disk space. >> >> ACK! Log rolling on my servers stopped. >> >> My named.conf has lines like: >> file "query.log" versions 10 size 1000m; >> >> In my directory, I have: >> query.log.9 >> query.log.8 >> query.log.7 >> query.log.6 >> query.log.5 >> query.log.4 >> query.log.3 >> query.log.2 >> query.log.1 >> query.log.0 >> query.log >> >> Log numbers 0-9 are 1001M (as expected). >> The current log is 28G and growing :( >> >> I've looked over the BIND release notes and don't see anything about a >> change to the logging behavior. Did I miss something? >> >> Or maybe some kernel (or other package) patch broke some dependency? >> >> >> I'm looking for ideas here. >> >> >> -- >> Do things because you should, not just because you can. >> >> John Thurston907-465-8591 >> john.thurs...@alaska.gov >> Department of Administration >> State of Alaska >> ___ >> 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 > > ___ > 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: bind 9.11.3 - resolving troubles running as a caching server
Hi, you mentioned “forwarders” - what are these and how does answer look like on the upstream forwarders? I would recommend enabling higher debug level (start with -d 1) and look into logs what was the answer from the forwarders preceding the failure. Ondrej -- Ondřej Surý — ISC > On 20 Nov 2019, at 18:44, Bind Mailinglist wrote: > > Hello list > I'm glad there is such an active list. Hope there is anybody out there > who can help me with my little problem. :-) > We are running six bind server ( all Ubuntu LTS 18.04 with bind 9.11.3 > ), so they are pretty up to date. > Three of them have authoritative zones, one is for testing and two are > just caching servers. And there starts my problem. > 1. It only appears on my caching servers and only if I use my other > servers as forwarders. > 2. At the moment the problem appears on my chaching servers I'm still > able to let it resolve through my forwarders. > 3. Only one organisation with several newspapers are affected. There may > be others but I don't know at the moment. > > Ok, all these newspapers are hosted on oraclecloud with short timers > around 30s. > > # dig www.20min.ch > ;; ANSWER SECTION: > www.20min.ch. 39 IN CNAME > tamedia.a.inregion.waas.oci.oraclecloud.net. > tamedia.a.inregion.waas.oci.oraclecloud.net. 16 IN CNAME > tm.inregion.waas.oci.oraclecloud.net. > tm.inregion.waas.oci.oraclecloud.net. 16 IN CNAME > eu-london.inregion.waas.oci.oraclecloud.net. > eu-london.inregion.waas.oci.oraclecloud.net. 28 IN A 138.1.82.213 > eu-london.inregion.waas.oci.oraclecloud.net. 28 IN A 147.154.234.67 > eu-london.inregion.waas.oci.oraclecloud.net. 28 IN A 147.154.228.138 > > # dig www.tagesanzeiger.ch > ;; ANSWER SECTION: > www.tagesanzeiger.ch. 113 IN CNAME cnp-a-cre-p.newsnetz.ch. > cnp-a-cre-p.newsnetz.ch. 113IN CNAME > tamedia.a.inregion.waas.oci.oraclecloud.net. > tamedia.a.inregion.waas.oci.oraclecloud.net. 11 IN CNAME > tm.inregion.waas.oci.oraclecloud.net. > tm.inregion.waas.oci.oraclecloud.net. 12 IN CNAME > eu-switzerland.inregion.waas.oci.oraclecloud.net. > eu-switzerland.inregion.waas.oci.oraclecloud.net. 12 IN A 192.29.59.121 > eu-switzerland.inregion.waas.oci.oraclecloud.net. 12 IN A 192.29.58.46 > eu-switzerland.inregion.waas.oci.oraclecloud.net. 12 IN A 192.29.58.42 > > > Now if I use my caching servers with forwarders enabled I run quite > often into cases where resolving stops working for theses two domains at > the same time. > When I take a dump I see the following line: > ; answer > tm.inregion.waas.oci.oraclecloud.net. 893 \- ;-$NXRRSET > > I have to clear this host from cache to make it working again, for a few > minutes. > The stupid thing, this NXRRSET cache entry has a much higher lifetime. > And so resolving stops working on my caching servers for more then 15min. > > Any idea how I could find out why this happens? > There must be something between my DNS servers. They are in the same > network, so there is no firewall between. > > Many thanks and regards > Florian > > ___ > 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: bind 9.11.3 - resolving troubles running as a caching server
The cache shows you that the forwarder reported that there’s no such record
returned from the upstream resolvers.
The NXRRSET means - Non-eXistant Resource Record Set, e.g. your resolvers
cached the non-existence of the name returned from the upstream resolvers.
The other option would be running the affected query against the upstream
resolvers in a semi-tight loop and log the results.
while true; do echo "$(date -R): $(dig +short IN A @)“;
sleep 1; done
Ondrej
--
Ondřej Surý
ond...@isc.org
> On 21 Nov 2019, at 01:09, Bind Mailinglist wrote:
>
> Hello Ondřej
> Many thanks for your answer. Hope debugging can help me without server
> overloading.
> They have around 1500 queries/s peakload during eveninghours. It will need
> some time to log exactly this effect.
> At the moment I have the following lines disabled:
> // forwarders {
> //213.160.41.2;
> //213.160.40.34;
> // };
> About the answer. Does it matter if I query A or if there is only a
> CNAME as an answer?
> My last test shows me following cache entry. This has happend around 20min
> after restarting bind with my forwarders enabled.
> ; answer
> tm.inregion.waas.oci.oraclecloud.net. 1697 \-A ;-$NXRRSET
> Could a server timeout ends up in such a cache entry? Or does it need a valid
> answer from the forwarders? What you think.
> I tried to force forwarding by adding "forwarding only" but the result was
> the same.
>
> Regards Florian
>
>
> Am 20.11.2019 um 11:58 schrieb Ondřej Surý:
>> Hi,
>>
>> you mentioned “forwarders” - what are these and how does answer look
>> like on the upstream forwarders?
>>
>> I would recommend enabling higher debug level (start with -d 1) and look
>> into logs what was the answer from the forwarders preceding the failure.
>>
>> Ondrej
>> --
>> Ondřej Surý — ISC
>>
>>
>>> On 20 Nov 2019, at 18:44, Bind Mailinglist
>>> wrote:
>>>
>>> Hello list
>>> I'm glad there is such an active list. Hope there is anybody out there
>>> who can help me with my little problem. :-)
>>> We are running six bind server ( all Ubuntu LTS 18.04 with bind 9.11.3
>>> ), so they are pretty up to date.
>>> Three of them have authoritative zones, one is for testing and two are
>>> just caching servers. And there starts my problem.
>>> 1. It only appears on my caching servers and only if I use my other
>>> servers as forwarders.
>>> 2. At the moment the problem appears on my chaching servers I'm still
>>> able to let it resolve through my forwarders.
>>> 3. Only one organisation with several newspapers are affected. There may
>>> be others but I don't know at the moment.
>>>
>>> Ok, all these newspapers are hosted on oraclecloud with short timers
>>> around 30s.
>>>
>>> # dig
>>> www.20min.ch
>>>
>>> ;; ANSWER SECTION:
>>>
>>> www.20min.ch
>>> . 39 IN CNAME
>>> tamedia.a.inregion.waas.oci.oraclecloud.net.
>>> tamedia.a.inregion.waas.oci.oraclecloud.net. 16 IN CNAME
>>> tm.inregion.waas.oci.oraclecloud.net.
>>> tm.inregion.waas.oci.oraclecloud.net. 16 IN CNAME
>>> eu-london.inregion.waas.oci.oraclecloud.net.
>>> eu-london.inregion.waas.oci.oraclecloud.net. 28 IN A 138.1.82.213
>>> eu-london.inregion.waas.oci.oraclecloud.net. 28 IN A 147.154.234.67
>>> eu-london.inregion.waas.oci.oraclecloud.net. 28 IN A 147.154.228.138
>>>
>>> # dig
>>> www.tagesanzeiger.ch
>>>
>>> ;; ANSWER SECTION:
>>>
>>> www.tagesanzeiger.ch
>>> . 113 IN CNAME cnp-a-cre-p.newsnetz.ch.
>>> cnp-a-cre-p.newsnetz.ch. 113IN CNAME
>>> tamedia.a.inregion.waas.oci.oraclecloud.net.
>>> tamedia.a.inregion.waas.oci.oraclecloud.net. 11 IN CNAME
>>> tm.inregion.waas.oci.oraclecloud.net.
>>> tm.inregion.waas.oci.oraclecloud.net. 12 IN CNAME
>>> eu-switzerland.inregion.waas.oci.oraclecloud.net.
>>> eu-switzerland.inregion.waas.oci.oraclecloud.net. 12 IN A 192.29.59.121
>>> eu-switzerland.inregion.waas.oci.oraclecloud.net. 12 IN A 192.29.58.46
>>> eu-switzerland.inregion.waas.oci.oraclecloud.net. 12 IN A 192.29.58.42
>>>
>>>
>>> Now if I use my caching servers with forwarders enabled I run quite
>>> often into cases where resolving stops working for theses two domains at
>>> the same time.
>>> When I take a dump I see the following line:
>>> ; answer
>&
Re: statistics server access log
Put a proxy between BIND and your monitoring team? Ondrej -- Ondřej Surý ond...@isc.org > On 26 Nov 2019, at 00:38, Veaceslav Revutchi wrote: > > I'm looking for a way to detect and alert when our monitoring team > starts pulling the stats from our resolvers by http://resolver:8080 > instead of http://resolver:8080/xml/v3/server > > as the short url results in a large download and can be service > impacting. Picking up the packets on the wire on that port, and > extracting the url would be one way to do it, but was hoping for > something simpler. > > running: 9.11.4-P2-RedHat > > Thank you, > Slava > ___ > 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: CloudSmith repository missing
Hi Matt, sorry for the confusion with the CloudSmith repositories. We’ve been experimenting with the different models, and we’ve decided to keep the BIND 9 packages closer to the official distributions, that means that the packages for distributions supported by us are located at following places: BIND 9.11 ESV * Fedora/EPEL: https://copr.fedorainfracloud.org/coprs/isc/bind-esv/ * Ubuntu: https://launchpad.net/~isc/+archive/ubuntu/bind-esv * Debian: https://bind.debian.net/bind-esv/ BIND 9.14 * Fedora/EPEL: https://copr.fedorainfracloud.org/coprs/isc/bind/ * Ubuntu: https://launchpad.net/~isc/+archive/ubuntu/bind * Debian: https://bind.debian.net/bind/ BIND 9.15 - Development Release NOTE: don’t use in production NOTE: unless you are willing to do some debugging if you encounter any problems, which in turn would be helpful to us * Fedora/EPEL: https://copr.fedorainfracloud.org/coprs/isc/bind-dev/ * Ubuntu: https://launchpad.net/~isc/+archive/ubuntu/bind-dev * Debian: https://bind.debian.net/bind-dev/ Sorry for any inconvenience our packaging changes might have caused. Thanks, -- Ondřej Surý ond...@isc.org > On 10 Oct 2019, at 00:43, Matthew Pounsett wrote: > > > Hi! It looks like the BIND Cloudsmith repository, which was there earlier > this week, is no longer present. > > Hit:9 https://packages.icinga.com/debian icinga-stretch InRelease > Ign:10 https://dl.cloudsmith.io/public/isc/bind/deb/debian stretch InRelease > Err:11 https://dl.cloudsmith.io/public/isc/bind/deb/debian stretch Release > 404 Not Found > Reading package lists... Done > E: The repository 'https://dl.cloudsmith.io/public/isc/bind/deb/debian > stretch Release' does no longer have a Release file. > > Looking at ISC's Cloudsmith page[0], I see a "public-bind" repository which > seems to be about two weeks old. Has that replaced the "bind" repository, or > is that something else? Or should I not be expecting these repositories to > be stable (yet)? > > [0]: <https://cloudsmith.io/~isc/repos/> > ___ > 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: Questions about DNSSEC in Bind
TL;DR use ECDSA, single algorithm https://tools.ietf.org/html/rfc8624 -- Ondřej Surý ond...@isc.org > On 11 Oct 2019, at 08:38, ego...@sarenet.es wrote: > > Good afternoon, > > I would like to ask you some questions about DNSSEC, which I have not been > able to clarify by my own, reading documentation or testing… they are these > ones : > > - Is it important or should be signed the whole zone with a “compatible" > algorithm as SHA1 and with a stronger one like SHA256 or is it just ok with > SHA256?. I would like to avoid the fact that a resolver could have issues > validating rrsets… I have seen root servers DS has algorithm id 7. Perhaps is > this one the most compatible algorithm for using in DNSSEC?. The most > recommended?. Perhaps we should just use for all keys algorithm 7 as have > seen some root servers use?. Use ECDSA, it’s well-supported. > - If I wanted to sign a zone for instance in 5 and 7 algorithm (if it’s > advisable, as isc.org for instance is signed with two algorithms), should I > run dnssec-sigzone twice and/or perhaps with two different keys?. Can the > same key converted to one kind of key to another (from sha1 to sha256 or > sha256 to sha1) for this purpose?. I have seen isc.org does double signing > with two different algorithms so… what is the recommended practice here?. It’s not advisable. It just increases the response size. > - I have seen the procedure of key rolling over. I have seen there is a > manual procedure. Perhaps the most advantageous aspect of manual handling of > zone signing, can be that you can revoke privileges to Bind to read the > private keys?. I say it, because you generate as root for instance, a signed > zone file and then you just serve it as a master zone… and perhaps the > flexibility you have with it?. Could you please rephrase? I don’t know what you are asking about... For the rest, I would recommend using inline-signing with auto-dnssec and dnssec-keymgr tool from BIND distribution to manage the keys, and set some reasonable times for ZSK rollovers (1 year+). Roll keys only if there’s a security breach. There’s no cryptographic need to roll the keys if you pick ECDSA. If there will be, you will get that in the news :), and we’ll be in much bigger troubles than broken DNSSEC. > - By the way, I have seen that exists too the possibility of a slightly less > complicated way of signing a zone, the dynamic one, but… you have to update > the zone as a dynamic zone with nsupdate for including in the zone the > DNSKEYS and you need to manage by your own equally the key regeneration (the > keys files generation with dnssec-keygen) for avoiding having your zone > signatures expired, am I wrong?…. I think that instead of using this method, > perhaps could be better to use inline signing method instead (if you decide > discarding totally manual method…)?… which by the way… allows you to not > having a ”real” “declared” dynamic zone… with dynamic updates… but… in either > dynamic key roll over method, do you have equally to create by your own, new > keys (mainly talking now about ZSK because KSK needs to update DS in the root > servers) in the key directory of the zone for resigning the zone?. The > recommended method for that is dnssec-keygen -S?. > > - It seems inline signing method of key rolling over does not allow you to > choose the key rolling over method?. How does, inline-signing manage the zone > sign in the terms of which key algorithm, rollover method and so, does use?. > > - Do you have a minimum time a zsk should be enabled?. I say it, because even > setting the zsk key this way : > > ; This is a zone-signing key, keyid 45018, for seranet.es. > ; Created: 20191010111754 (Thu Oct 10 13:17:54 2019) > ; Publish: 20191010111754 (Thu Oct 10 13:17:54 2019) > ; Activate: 20191010111754 (Thu Oct 10 13:17:54 2019) > ; Inactive: 20191010131754 (Thu Oct 10 15:17:54 2019) > ; Delete: 20191010151754 (Thu Oct 10 17:17:54 2019) > seranet.es. IN DNSKEY 256 3 8 > AwEAAdrLnpJilOPdAh8Y1LLPpLCB+600MqhwuaEVYYQ4wWMXdl+JaeFm > wUIVUd3BSR+qz034t7VT/8rtIzc6jXaoOjqvIbnS5NMje49503Fikt7X > WwST61AhtghrGFl6Wl27E3WT5s3IlJFDUo1efLy0E18qm5Q8JPkt38zI BJ9339HL > dig seranet.es a +dnssec > > ; <<>> DiG 9.10.6 <<>> seranet.es a +dnssec > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8734 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;seranet.es. IN A > > ;; AUTHORITY SECTION: > seranet.es. 300 IN SOA ns1.sarenet.es. > dnsmaster.sarenet.es. 2
Re: dhclient hook not overwritten /etc/resolv.conf
You need to ask on your distro user support forum and not here. This topic is beyond the subject of this list as it could include all kinds of integrations that your distribution provides. This is not a bind-users topic. Ondrej -- Ondřej Surý ond...@isc.org > On 19 Dec 2019, at 11:41, Zhengyu Pan(联通集团联通云数据有限公司本部) > wrote: > > I only want to prepend only a IPv6 nameserver. Other ns are added by users. > > Zhengyu > Thanks. > >> 2019年12月19日 下午6:32，Reindl Harald 写道： >> >> >> >> Am 19.12.19 um 10:58 schrieb Zhengyu Pan: >>> Sorry. I sent wrong mailing group. >>> chattr not worked. It prompted: >>> Shutting down inteface eth0: chattr:Operation not permitted while setting >>> flags on /etc/resolv.conf. >> >> the opposite is true >> >> it proves *that* it worked but waht can#t wrk i when you for whatever >> reason need or believe to ned the dynamic nameservers >> >> but that don't make sense anyways >> >> having dozens of namservers in /etc/resolv.conf with your wished ones at >> the bottom is useless because it won't be questioned at all as long the >> first in teh list are responding >> >>>> 2019年12月19日 下午5:28，Reindl Harald 写道： >>>> Am 19.12.19 um 10:01 schrieb Zhengyu Pan: >>>>> My OS is Centos7. I add a bash script dns.sh in >>>>> /etc/dhcp/dhclient-exit-hooks.d . The script content is >>>>> >>>>> #!/bin/bash >>>>> echo“nameserver1.1.1.1”>>/etc/resolv.conf >>>>> >>>>> I want to append a nameserver in /etc/resove.conf. >>>>> However, when I restart network. /etc/resove.conf not changed. >>>>> /etc/resove.conf.save append this line. >>>>> Why happens that? How can I append a nameserver in /etc/resove.conf? >>>> >>>> not a named qurstion at all, however >>>> >>>> becasue something overwrote /etc/resolv.conf after your script which >>>> maybe means your script runs way too early >>>> >>>> chattr +i /etc/resove.conf under normal conditions >>>> >>>> chattr -i /etc/resove.conf at the start of your script >>>> chattr +i /etc/resove.conf at the end of your script >>>> >>>> https://www.tecmint.com/chattr-command-examples/ >>>> >>>> this is a supported way to prevent resolv.conf overwritten by whatever >>>> stuff running on the system, be it dhclient, networkmanager or another >>>> smartass stuff which lives in a authistic world pretend to know what my >>>> nameservers are >> ___ >> 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 > > 如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 > hqs-s...@chinaunicom.cn，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received > this email in error please notify us immediately by e-mail. Please reply to > hqs-s...@chinaunicom.cn ,you can unsubscribe from this mail. We will > immediately remove your information from send catalogue of our. > ___ > 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
Changes BIND 9.15+ source distribution (gz -> xz, and SHA1 deprecation)
Hi, the BIND 9 development team has decided to change the compression method for BIND 9.15.7, and also for the next BIND 9.16.0 release to widely available **xz** compression algorithm. Therefore, the tarball extension has changed from https://downloads.isc.org/isc/bind9/9.15.7/bind-9.15.7.tar.gz to https://downloads.isc.org/isc/bind9/9.15.7/bind-9.15.7.tar.xz xz offers considerable savings in terms of disk space and thus network traffic and the tool is available in the base system for most if not all Linux and BSD distributions. The previous versions of BIND 9 (9.11 and 9.14) are still distributed compressed with gzip. The other change we will introduce early next year (timed with BIND 9.16.0 release) is the deprecation of SHA1 checksums. The MD based algorithms are no longer collision resistant enough and henceforth the SHA1 based checksums no longer bear any real value. Ondrej -- Ondřej Surý ond...@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: bind 9.16 vs. 9.14 tcp client connections
Hi Arsen, we think you are hitting a problem that was reported to us earlier. Since it has been now circulated on the bind-users, we made the merge request public: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3163 and patch: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3163.patch ISC will be issuing a proper Operational Notification later this week and the fix will be included in BIND 9.16.1 due in March. Sorry for the inconvenience. Thanks, Ondrej -- Ondřej Surý ond...@isc.org > On 5 Mar 2020, at 10:11, Arsen STASIC wrote: > > Hi, > > Bind 9.16 was installed on 3/2 15:45 and tcp connections ramped up to maximum: > rndc status | grep -i tcp > tcp clients: 102/150 > TCP high-water: 150 > > Switching back to bind 9.14 on 3/4 15:45 shows "normal" tcp client behavior: > rndc status | grep -i tcp > tcp clients: 29/150 > TCP high-water: 67 > > I have found some tcp related changes in the later versions of 9.15 > <https://ftp.isc.org/isc/bind/9.16.0/CHANGES>, but nothing which is > explaining this kind of behaviour. > (attachment is in logarithmic scale) > Has someone else experienced this too? > > cheers, > Arsen > ___ > 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 signature.asc Description: Message signed with OpenPGP ___ 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: Advice on balancing web traffic using geoip ACls
As far as we know the bug is present in all current BIND releases. We are still investigating the issue, but things are looking positive thanks to Vikor Dukhovni’s help with debugging his coredump. Ondřej -- Ondřej Surý — ISC > On 24 Feb 2020, at 11:08, Jukka Pakkanen wrote: > > > Hi, at the download page the status of 9.16 is “Current-Stable” but it also > states “only for testing & evalution, *not* recommended for production”? > > Can you confirm if the DNSSEC inline-signing problem (signing just stops > sometimes, affects both 9.11 and 9.14 branch) is present in this or not? I > read from the docs that 9.16 had some work to inline signing done, maybe > works better in that regards too? > > Jukka > > Lähettäjä: bind-users Puolesta Victoria > Risk > Lähetetty: 23. helmikuuta 2020 20:35 > Vastaanottaja: @lbutlr > Kopio: bind-users > Aihe: Re: Advice on balancing web traffic using geoip ACls > > … > 9.14 has just been replaced by 9.16, released just this past week. We will > continue offering security releases for 9.14 for a 3-month period to support > migration to 9.16. Someone doing a migration today should look at 9.16 rather > than 9.14. > … > > > Victoria Risk > Product Manager > Internet Systems Consortium > vi...@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 ___ 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.11.13 - inline re-signing stops
Hi Matthew,
we have fixed a data race in a related code in BIND 9.11.15.
However, if you can get us a coredump using gdb and tar it with associated
binary and libraries, we might be able to look into it. ISC GitLab should have
enough limit to accept tar.xz, make sure you set the issue as confidential, we
will sanitize it before making the issue public in the future. You may use
pandora.isc.org to drop of larger files in a confidential matter and link it to
the GitLab issue.
Ondřej
--
Ondřej Surý — ISC
> On 5 Feb 2020, at 19:28, Matthew Richardson wrote:
>
> I have an interesting issue with a hidden master running 9.11.13 and
> configured with inline signing on a number of zones, configured thus:-
>
>> zone "42.201.193.in-addr.arpa" {
>> type master;
>> file "zones/master/42.201.193.in-addr.arpa.db";
>> inline-signing yes;
>> auto-dnssec maintain;
>> };
>
> Prior to 30 January, all the zones configured in this way were regurlarly
> being resigned, logging entries such as:-
>
>> 29-Jan-2020 03:37:02.129 general: info: zone 42.201.193.in-addr.arpa/IN
>> (signed): reconfiguring zone keys
>> 29-Jan-2020 03:37:02.131 general: info: zone 42.201.193.in-addr.arpa/IN
>> (signed): next key event: 29-Jan-2020 15:37:02.129
>> 29-Jan-2020 15:37:02.129 general: info: zone 42.201.193.in-addr.arpa/IN
>> (signed): reconfiguring zone keys
>> 29-Jan-2020 15:37:02.131 general: info: zone 42.201.193.in-addr.arpa/IN
>> (signed): next key event: 30-Jan-2020 03:37:02.129
>> 30-Jan-2020 03:35:01.604 general: info: zone 42.201.193.in-addr.arpa/IN
>> (signed): reconfiguring zone keys
>> 30-Jan-2020 03:35:01.606 general: info: zone 42.201.193.in-addr.arpa/IN
>> (signed): next key event: 30-Jan-2020 15:35:01.604
>
> Since an "rndc reload" at 12:22 on 30 January, this logging has stopped and
> NONE of the signed zones have had any of their RRSIGs re-signed. Today,
> one sees:-
>
>> [root@m70 dns]# rndc zonestatus 42.201.193.in-addr.arpa
>> name: 42.201.193.in-addr.arpa
>> type: master
>> files: zones/master/42.201.193.in-addr.arpa.db
>> serial: 286
>> signed serial: 3829
>> nodes: 140
>> last loaded: Sun, 24 Nov 2019 07:13:00 GMT
>> secure: yes
>> inline signing: yes
>> key maintenance: automatic
>> next key event: Wed, 05 Feb 2020 18:01:42 GMT
>> next resign node:
>> DI2VMBB2GDES2IKFVFRUB7DIDDC7TI8L.42.201.193.in-addr.arpa/NSEC3
>> next resign time: Thu, 30 Jan 2020 21:25:35 GMT
>> dynamic: no
>> reconfigurable via modzone: no
>
> which clearly shows "next resign" as being in the past. The server
> reports:-
>
>> [root@m70 dns]# rndc status
>> version: BIND 9.11.13 (Extended Support Version)
>> running on m70: Linux x86_64 4.14.120-x86_64-linode125 #1 SMP Mon May 20
>> 16:43:35 UTC 2019
>> boot time: Sun, 24 Nov 2019 09:51:27 GMT
>> last configured: Wed, 05 Feb 2020 18:10:21 GMT
>> configuration file: /etc/named.conf
>> CPUs found: 1
>> worker threads: 1
>> UDP listeners per interface: 1
>> number of zones: 773 (0 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: 6/150
>> TCP high-water: 64
>> server is up and running
>
> As a test I tried incrementing the serial number of only one of the signed
> zones and, after a reload, that zone seems to be being resigned normally.
>
> My suspicion is that retarting Bind will simply fix the issue.
>
> However, I was wondering whether there might be any troubleshooting or
> diagnosis which it might be useful to undertake. Were ISC to want, it
> would probably be possible to get them temporary access.
>
> Best wishes,
> Matthew
> ___
> 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: dnssec-policy behaviour
Hi Kal, thanks for testing the new feature. This sounds like a bug to me. Could you please fill issue in our GitLab (https://gitlab.isc.org/), so we don’t lose track of the bug. Thank you, -- Ondřej Surý — ISC > On 2 Feb 2020, at 10:53, Kal Feher via bind-users > wrote: > > I've been testing the dnssec-policy (9.15.8)feature, but either I've > come across a bug, or my understanding of the configuration is incomplete. > > Whenever BIND restarts, it adds a new key (or keys, depending on the > policy) into the configured key directory. It uses this new key or keys > to sign the zone, apparently ignoring previously created keys, although > the DNSKEY records remain within the zone. I have observed the same > behaviour if I initiate an rndc loadkeys . > > I've tried both the default policy and an explicitly configured policy > with the same results. > > There's nothing in the logs indicating an error loading previous keys. > > Am I missing something? > > -- > > Kal Feher > > ___ > 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: Reasons of SERVFAIL
If `dig +dnssec +cd emeraldonion.org mx` will give you answers and `dig +dnssec emeraldonion.org mx` does not, then it’s most probably validation failure. Then of course based on your logging setup, the validation failures might be visible in BIND 9 log. Ondrej -- Ondřej Surý ond...@isc.org > On 8 Feb 2020, at 02:53, Alessandro Vesely wrote: > > Hi, > > thank you for your prompt reply! > > On Sat 08/Feb/2020 11:39:05 +0100 Ondřej Surý wrote: >>> How do I fix this issue? >> >> >> You don’t, their DNSSEC is broken: >> >> https://dnsviz.net/d/emeraldonion.org/dnssec/ > > > I see. Is there a command to diagnose that locally? > > >> They have to either start signing again or remove DS record from the parent >> (org). > > > Fine, I'll forward your suggestion direct-to-mx > > > Best > Ale > -- > > > > > > ___ 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: Reasons of SERVFAIL
> How do I fix this issue? You don’t, their DNSSEC is broken: https://dnsviz.net/d/emeraldonion.org/dnssec/ They have to either start signing again or remove DS record from the parent (org). Ondrej -- Ondřej Surý ond...@isc.org > On 8 Feb 2020, at 02:36, Alessandro Vesely wrote: > > Hi! > > > I find I'm unable to send mail to a domain. I get an NDR saying DNS lookup > failed. Indeed, when I try manually, I get: > > 906-north:src$ dig emeraldonion.org mx > > ; <<>> DiG 9.10.3-P4-Debian <<>> emeraldonion.org mx > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5098 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;emeraldonion.org.IN MX > > ;; Query time: 289 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Sat Feb 08 11:29:41 CET 2020 > ;; MSG SIZE rcvd: 45 > > > SERVFAIL doesn't tell me /which/ server failed. I infer it's my one, because > of the trace below. > > How do I fix this issue? > > TIA > Ale > > 908-north:src$ dig +trace emeraldonion.org mx > > ; <<>> DiG 9.10.3-P4-Debian <<>> +trace emeraldonion.org mx > ;; global options: +cmd > . 493940 IN NS h.root-servers.net. > . 493940 IN NS d.root-servers.net. > . 493940 IN NS c.root-servers.net. > . 493940 IN NS k.root-servers.net. > . 493940 IN NS f.root-servers.net. > . 493940 IN NS l.root-servers.net. > . 493940 IN NS j.root-servers.net. > . 493940 IN NS m.root-servers.net. > . 493940 IN NS g.root-servers.net. > . 493940 IN NS i.root-servers.net. > . 493940 IN NS e.root-servers.net. > . 493940 IN NS a.root-servers.net. > . 493940 IN NS b.root-servers.net. > . 516974 IN RRSIG NS 8 0 518400 2020022105 > 2020020804 33853 . > 2aZlI+r3A/LaC2VEM7BSAupOBbXS/fSNZds49PjuhR38CmDEq6WddgXW > XbxGAJaNBBUOXRYB1U093FqP725t29VoFpSuUfmD8YGwzcbu1gtvBbyW > clLu3OK6X2m5V6AWvQuumcDA/qJRdnQ0/8EepqKL8f+vniQLCKxA5kR1 > HkZAG36QBhj0poGet9no8kQkz5/wBkI88fyId6ZasSbSCrX+68QuNcV/ > N0BwQNhuvY0JEMHEJVjDzTkoJghKySTylWE5R7wxc/p5HuBtBy5v+ITF > zGbbC3ZoXlVdRF3//QzW4aqdcCCBG+0yXDlRQ5ZevZfWABLJV8ds5VEG aXCLpg== > ;; Received 1097 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms > > org. 172800 IN NS a0.org.afilias-nst.info. > org. 172800 IN NS a2.org.afilias-nst.info. > org. 172800 IN NS b0.org.afilias-nst.org. > org. 172800 IN NS b2.org.afilias-nst.org. > org. 172800 IN NS c0.org.afilias-nst.info. > org. 172800 IN NS d0.org.afilias-nst.org. > org. 86400 IN DS 9795 7 1 > 364DFAB3DAF254CAB477B5675B10766DDAA24982 > org. 86400 IN DS 9795 7 2 > 3922B31B6F3A4EA92B19EB7B52120F031FD8E05FF0B03BAFCF9F891B FE7FF8E5 > org. 86400 IN RRSIG DS 8 1 86400 2020022105 > 2020020804 33853 . > QcNTGf7LnnW7XgHNC4VFs9e2hsMw9ruiWZ2J1Ev2+aCRdyuk0ECpxMPd > 8Gb4MYmAsbljnELkPNSCUdlLv7LeN0+mDoESBe9AKQ++l7DMSZXQ5jJh > 9ThjNs12lxWAFLIcRDFb0HXnwVG5bvYFovrorG01TxGDyrPp56eVd2GT > Udprf8kPkyatYVTvthFZrIU72wClEBjBGirOiiWEkPtzOKYSYv+gXKOn > v4lpxcfbgdGdFZLlrv406FqP/1hsGpY5u2dO0ToAuUZ9hBrmJnAYut17 > YXnplS5yD+ZMmXDaOCn6rmeUPkOXNjV7/Onwlo7dDZhFC6QVqt6HVHXJ 8egMVA== > ;; Received 818 bytes from 192.203.230.10#53(e.root-servers.net) in 1 ms > > emeraldonion.org. 86400 IN NS ns0.1984.is. > emeraldonion.org. 86400 IN NS ns1.1984.is. > emeraldonion.org. 86400 IN NS ns2.1984.is. > emeraldonion.org. 86400 IN NS ns1.1984hosting.com. > emeraldonion.org. 86400 IN NS ns2.1984hosting.com. > emeraldonion.org. 86400 IN DS 58282 8 2 > C853155321349E86D675DBB87E839E689582FC193F447DE120242828 31A92EFE > emeraldonion.org. 86400 IN RRSIG DS 7 2 86400 20200222152504 > 20200201142504 63887 org. > HuTit6Jz4FEFoTRpRiWpUFN87YYeLqa5P/rnVnFmC7cm563fklPammF/ > uUUYzAK4JhekTZmrSGG0P3SGrk85nS8A0tcngc8qGdfnmYaE6YRfT7E7 > GsugewjF17oQ+9BwyeeoCorNqXNnBBw6gSSzyywkumTAAAjLCLfyeiLj olE= > ;; R
Re: Bind 9.11.13 - inline re-signing stops
Matthew, thank you for the report. Indeed, we have received some more reports about this particular issue and we are currently investigating it. We would appreciate if anybody who encounters the problem could dump the core first before restarting the named, so we have more evidence to analyze. Ondrej -- Ondřej Surý — ISC > On 18 Feb 2020, at 23:22, Matthew Richardson > wrote: > > Having upgraded to 9.11.15 I am still seeing similar problems, where some > zones stop updating their signatures. I have a suspicion that "rndc > reconfig" might get them re-signing, or perhaps updating the serial of the > unsigned zone. > > I have logged it on GitLab as #1627, and will take your advice of marking > it private as I will be uploading config, zonefiles and logs. If the > attachments are removed, I am happy for it to be public as they are the > only confidential part. > > Best wishes, > Matthew > -- >> From: Ond?ej Surý >> To: Matthew Richardson >> Cc: bind-users@lists.isc.org >> Date: Wed, 5 Feb 2020 20:02:17 +0100 >> Subject: Re: Bind 9.11.13 - inline re-signing stops > >> Hi Matthew, >> >> we have fixed a data race in a related code in BIND 9.11.15. >> >> However, if you can get us a coredump using gdb and tar it with associated >> binary and libraries, we might be able to look into it. ISC GitLab should >> have enough limit to accept tar.xz, make sure you set the issue as >> confidential, we will sanitize it before making the issue public in the >> future. You may use pandora.isc.org to drop of larger files in a >> confidential matter and link it to the GitLab issue. >> >> Ond?ej > > ___ > 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: Bind 9.11.13 - inline re-signing stops
Hi Matthew, we’ll write some generic instruction on how to get a coredump from a running named (without crashing it) - generally you want to use gcore[1]. Then here you can continue as if the named has crashed and get us a thread stack trace[2]. As we need to access very specific data structure, please add the information to the issue you have opened, and we’ll pick it up from there. You can also share the coredump and the binaries with us using pandora.isc.org service, but please be aware that the memory dump can (and probably will) contain the DNSSEC signing private keys. Ondrej 1. https://www.systutorials.com/docs/linux/man/1-gcore/ 2. https://kb.isc.org/docs/aa-00340 Ondrej -- Ondřej Surý ond...@isc.org > On 19 Feb 2020, at 08:36, Matthew Richardson > wrote: > > Dear Ondrej, > > I would be delighted to assist with a core dump. > > However, not being a developer myself (I did do an amount of assembler work > in my youth, but that was long ago now!), I therefore do not know how to > get you "a coredump using gdb and tar it with associated binary and > libraries". > > Do you have any step by step instructions for a novice to achieve this? > The machine is running Centos 7, and Bind is built using rpmbuild from the > source rpm provided by ISC. > > With many thanks. > > Best wishes, > Matthew > -- >> From: Ond?ej Surý >> To: Matthew Richardson >> Cc: bind-users@lists.isc.org >> Date: Wed, 19 Feb 2020 07:16:49 +0100 >> Subject: Re: Bind 9.11.13 - inline re-signing stops > >> Matthew, >> >> thank you for the report. Indeed, we have received some more reports about >> this particular issue and we are currently investigating it. >> >> We would appreciate if anybody who encounters the problem could dump the >> core first before restarting the named, so we have more evidence to analyze. >> >> Ondrej > > ___ > 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: CDS-deletion record "CDS 0 0 0 00" is failing with bind-9.14.9 and bind-9.14.8
Hi Tom, > On 20 Feb 2020, at 17:42, Tom wrote: > > Hi > > With 9.16.0, the CDS deletion > (https://gitlab.isc.org/isc-projects/bind9/issues/1554) is still not working > and is ending with the same error as bind-versions before: > > 20-Feb-2020 17:31:25.381 general: error: zone example.com/IN (unsigned): > CDS/CDNSKEY consistency checks failed > 20-Feb-2020 17:31:25.381 zoneload: error: zone example.com/IN (unsigned): not > loaded due to errors. > > In which version will this issue be fixed? it will be included in the next version when the issue in question gets picked up by a developer, be triaged, test written and code fixed. I can’t really say when this will happen, our developer resources are thin and there are more issues that require our attention. That said - this is open source and we happily accept external contributions in a form of merge request in our gitlab instance (you need to ask for a permission to fork the project) or as a patch. This seems to be fairly trivial bug that might be a good start if anybody wants to help fix bugs in BIND 9. Cheers, Ondrej -- Ondřej Surý ond...@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: Weird behaviour in wildcard CNAME - is this feature or bug? Can it be changed?
The wildcard doesn’t cover empty non terminals. The only nonstandard implementation that did this was djbdns and the behavior was considered to be incompatible with rest of the DNS implementations. Ondrej -- Ondřej Surý — ISC > On 11 Feb 2020, at 15:59, Petr Bena wrote: > > Hello, > > I fail to see that: > > for example test.prod.app.pcp.cn.prod > > step 2) search the available zones - the zone in question here is pcp.cn.prod > which is found > > step 3) no matching name is found but *.prod.app exists inside of pcp.cn.prod > which is returned > > However, with payis.test.prod.app.pcp.cn.prod > > step 2) search the available zones - the zone in question here is pcp.cn.prod > which is found > > step 3) no matching name is found, *.prod.app exists inside of pcp.cn.prod > but NXDOMAIN is returned instead? > > Why? > > How this algorith is broken if something under or above the requested record > is existing? > > >> On 11/02/2020 15:06, Mark Andrews wrote: >> Yes, this is standard behaviour. It falls out of this section of RFC 1034 >> which is part of STD 13 (DNS). Work the algorithm by hand with the records >> you said existed in the zone. >> >> 4.3.2. Algorithm >> >> >> The actual algorithm used by the name server will depend on the local OS >> and data structures used to store RRs. The following algorithm assumes >> that the RRs are organized in several tree structures, one for each >> zone, and another for the cache: >> >>1. Set or clear the value of recursion available in the response >> depending on whether the name server is willing to provide >> recursive service. If recursive service is available and >> requested via the RD bit in the query, go to step 5, >> otherwise step 2. >> >>2. Search the available zones for the zone which is the nearest >> ancestor to QNAME. If such a zone is found, go to step 3, >> otherwise step 4. >> >>3. Start matching down, label by label, in the zone. The >> matching process can terminate several ways: >> >> a. If the whole of QNAME is matched, we have found the >> node. >> >> If the data at the node is a CNAME, and QTYPE doesn't >> match CNAME, copy the CNAME RR into the answer section >> of the response, change QNAME to the canonical name in >> the CNAME RR, and go back to step 1. >> >> Otherwise, copy all RRs which match QTYPE into the >> answer section and go to step 6. >> >> b. If a match would take us out of the authoritative data, >> we have a referral. This happens when we encounter a >> node with NS RRs marking cuts along the bottom of a >> zone. >> >> Copy the NS RRs for the subzone into the authority >> section of the reply. Put whatever addresses are >> available into the additional section, using glue RRs >> if the addresses are not available from authoritative >> data or the cache. Go to step 4. >> >> c. If at some label, a match is impossible (i.e., the >> corresponding label does not exist), look to see if a >> the "*" label exists. >> >> If the "*" label does not exist, check whether the name >> we are looking for is the original QNAME in the query >> or a name we have followed due to a CNAME. If the name >> is original, set an authoritative name error in the >> response and exit. Otherwise just exit. >> >> If the "*" label does exist, match RRs at that node >> against QTYPE. If any match, copy them into the answer >> section, but set the owner of the RR to be QNAME, and >> not the node with the "*" label. Go to step 6. >> >>4. Start matching down in the cache. If QNAME is found in the >> cache, copy all RRs attached to it that match QTYPE into the >> answer section. If there was no delegation from >> authoritative data, look for the best one from the cache, and >> put it in the authority section. Go to step 6. >> >>5. Using the local resolver or a copy of its algorithm (see >> resolver section of this memo) to answer the query. Store >> the results, including any intermediate CNAMEs, in the answer >> section of
Re: Is -DISC_SOCKET_MAXEVENTS still needed in BIND 9.16?
Hi Anand, on the contrary, we set tuning to large by default (it’s default or small now), so with the define you are actually setting it to lower value: #ifndef ISC_SOCKET_MAXEVENTS #ifdef TUNE_LARGE #define ISC_SOCKET_MAXEVENTS 2048 #else /* ifdef TUNE_LARGE */ #define ISC_SOCKET_MAXEVENTS 64 #endif /* TUNE_LARGE */ #endif /* ifndef ISC_SOCKET_MAXEVENTS */ Ondrej -- Ondřej Surý ond...@isc.org > On 20 Feb 2020, at 09:02, Anand Buddhdev wrote: > > Hi BIND developers, > > We build our own RPMs of BIND, and ever since the 9.9 builds, we have > been setting -DISC_SOCKET_MAXEVENTS=256. This is based on advice we > received from someone at ISC. > > Is this setting still relevant in BIND 9.16? > > Regards, > Anand > ___ > 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: Slow recursive query performance on Windows x64
Hi Steve,
I would suggest to either bump debugging level in bind9 or use wireshark to
look what’s happening on the wire. My best guest is broken IPv6 connectivity,
but it could be something completely different. Looking at the packets is a
easiest way to get better understanding of the problem.
Ondrej
--
Ondřej Surý — ISC
> On 17 Jan 2020, at 20:52, Steve Farr via bind-users
> wrote:
>
>
> Hi there,
>
> I'm hoping perhaps someone can point me in a good direction for
> troubleshooting here… I recently upgraded from BIND 9.9.10-P3 running in
> 32-bit Windows, to 9.14.9 running on 64-bit Windows. I've tried it in both
> Windows 10 and Windows 7, and the behavior is the same: Queries for addresses
> that aren't already cached take a long time (long enough that the client
> resolver often gives up and assumes the DNS server failed - perhaps 5-6
> seconds). On a second attempt, it's usually in the cache and responds right
> away. The server has three views, two of which allow recursion, and it hosts
> a couple of authoritative domains (differing in content between the views,
> but present in all three). Queries for addresses in the domains that are
> hosted locally are fast, and so are queries for anything that's cached. I had
> to make a few tweaks to the config, jumping so many versions, in order to
> eliminate warnings about things like DNSSEC… I also downloaded a fresh copy
> of the named.cache / root hints, as well as bind.keys.
>
> It's entirely possible that I just don't know what I'm doing.
>
> Any ideas what could be causing this? The old server occupied the same
> internal IP address (same firewall, same NAT, etc) so I don't tend to suspect
> the network, especially since it's reproducible (the old 32-bit box still
> works fast if I swap it back in). Here's my current config (feel free to
> critique it even if off-topic):
>
> // named.conf
> acl internal { 192.168.63.0/24; 192.168.65.0/24; 127.0.0.1; };
> acl wifi { 192.168.64.0/24; };
> acl notifiers { [public IP removed for anonymity];};
>
> key "transfer-key" {
> algorithm hmac-md5;
> secret "[removed for security]";
> };
> server [same public IP as in acl notifiers] {
> keys { transfer-key; };
> };
>
> options {
> version "1.1.1.1";
> directory "C:\ISCBIND9\etc\namedb"; // Working directory
> pid-file "C:\ISCBIND9\var\named.pid";
> statistics-file "C:\ISCBIND9\var\named.stats";
> memstatistics-file "C:\ISCBIND9\var\named.memstats";
> auth-nxdomain yes;
> listen-on { 192.168.63.23; 127.0.0.1; };
> tcp-clients 1024;
> max-cache-size 128M;
> allow-query { any; };
>recursion no;
>allow-recursion { none; };
>allow-query-cache { none; };
> allow-transfer { none; };
>allow-notify { notifiers; };
> notify no;
>
>dnssec-enable yes;
>dnssec-lookaside no;
>dnssec-validation yes;
>bindkeys-file "C:\ISCBIND9\etc\namedb\bind.keys";
> };
>
> view internal {
>match-clients { internal; };
>recursion yes;
>allow-query { internal; };
>allow-recursion { internal; };
>allow-query-cache { internal; };
>
>zone "." in {type hint; file "named.cache"; };
>zone "localhost" IN {type master; file "localhost.zone"; };
>zone "0.0.127.in-addr.arpa" IN {type master; file
> "named.local"; };
>[authoritative zones follow]
> };
>
> view wifi {
>[basically the same as internal except different match-clients
> statement and different zones]
> };
>
> view external {
>match-clients { any; };
>allow-recursion { none; };
>allow-query-cache { none; };
>recursion no;
>allow-query {any; };
>
>zone "." in {type hint; file "named.cache"; };
>zone "localhost" IN {type master; file "localhost.zone"; };
>zone "0.0.127.in-addr.arpa" IN {type master; file
> "named.local"; };
>[authoritative zones follow]
> };
>
>
> Thanks for any help anyone may be able to offer!
>
> -Steve
>
> ___
> 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: Slow recursive query performance on Windows x64
Run named with -4 option, that will disable IPv6.
Please note that filter--on-v4 was always wrong. You should fix your
network instead. It’s a bandaid, not a fix.
Ondrej
--
Ondřej Surý — ISC
> On 20 Jan 2020, at 04:38, Carl Byington via bind-users
> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>> On Sun, 2020-01-19 at 21:54 -0500, Steve Farr via bind-users wrote:
>> Does anyone know of a functionality that replaced the now-obsolete
>> filter--on-v4?
>
>plugin query "filter-.so" {
>filter--on-v4 yes;
>};
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.14 (GNU/Linux)
>
> iEYEAREKAAYFAl4lII0ACgkQL6j7milTFsEkNgCcDPjGp5r6X7wvC0MJUcW5rFUz
> V4sAn2WL6OOPWwGUyKpMyWo27+5hphqx
> =MrO2
> -END PGP SIGNATURE-
>
>
> ___
> 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: DNSSEC zones not updated
Hi,
did you try stopping BIND, removing journal files and then starting BIND again?
If the signed copy of the zone got corrupted in the memory, you might be
dumping the corrupted version on disk again with `rndc reload`.
Ondrej
--
Ondřej Surý
ond...@isc.org
> On 22 Jan 2020, at 12:11, Jukka Pakkanen wrote:
>
>
> Running BIND 9.14.9 Windows. The zone data is not updated for some reason
> anymore, and same problem in all our signed zones. Example "gemtrade.fi":
>
> zone "gemtrade.fi" {
> type master;
> file "named.gemtrade";
> inline-signing yes;
> auto-dnssec maintain;
> };
>
>
> ;
> ;File: named.gemtrade
> ;
> $TTL 60
> @IN SOAns1.qnet.fi. helpdesk.qnet.fi. (
> 202001234 ; serial number
> 28800 ; refresh every 12 hours
> 7200 ; retry after 2 hours
> 604800 ; expire after 2 weeks
> 33600) ; default ttl is 2 days
> gemtrade.fi.IN A 62.142.217.154
> IN MX 55 qntsrv8.qnet.fi.
> IN MX 25 qntsrv9.qnet.fi.
> IN NS ns1.qnet.fi.
> IN NS ns2.qnet.fi.
> IN NS ns3.qnet.fi.
> www IN A 62.142.217.154
> _autodiscover._tcp IN SRV0 5 443 mail.qnet.fi.
> localhost.gemtrade.fi. IN A 127.0.0.1
>
>
> Used to work fine, now no matter what change I make to the zone file and
> reload, it does not show up in queries, but the old data, weeks behind. The
> SOA & serial numbers *are* updating in the queries, but the actual records
> not. Example the MX records, currently I have priorities 55 and 25, still
> inquiries return the old 20 and 20. Same with any records, the changes does
> not get updated.
>
> Deleting the .jnl file does not help, after "rndc reload gemtrade.fi" a new
> .jnl file is created, but queries still return old data.
>
> The named process has all possible rights in the file structure.
>
> What might be wrong?
>
> ___
> 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
OpenSSL PKCS#11 Support in BIND via engine_pkcs11
Dear bind-users, I wrote a wiki page describing how to integrate stock BIND 9 with PKCS#11 HSMs using OpenSSL PKCS#11 engine (from OpenSC project): https://gitlab.isc.org/isc-projects/bind9/-/wikis/BIND-9-PKCS11 If you ever worked with HSM (and even better with BIND 9 and HSMs), I would appreciate if you can take a look, and perhaps try the method and report back success / failure? I understand that the PKCS#11 interface in BIND 9 isn’t very human friendly, but most of it comes from the fact that PKCS#11 itself isn’t human friendly. That said, we will look how to improve the experience of using HSMs with BIND 9, so don’t be afraid to fill issues and feature requests in BIND 9 GitLab issue tracker: https://gitlab.isc.org/isc-projects/bind9/issues Ondrej -- Ondřej Surý ond...@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: Slow recursive query performance on Windows x64
The problem is that apparently[*] the machines in your network have default
IPv6 routes, but you don’t have IPv6 connectivity. Fix that and you don’t have
to apply any bandaids. I think we should just remove filter- in the next
release cycle of BIND 9, having the feature doesn’t do any good for the health
of the Internet.
* - Normally, the ICMP unreachables are generated by local kernel, and based on
the evidences you provided (timeouts) it doesn’t, so something is misconfigured
either in your network or on that particular machine. Debugging your network is
beyond the scope of this mailing list.
Ondřej
--
Ondřej Surý — ISC
> On 20 Jan 2020, at 15:19, Steve Farr via bind-users
> wrote:
>
> Yeah, it's hard to disagree on the "should" part but we all definitely have
> to administer networks in an imperfect world... To my mind, when there's zero
> ipv6 connectivity beyond the LAN, it would be handy to not ask the firewall
> to create 3x more TCP connections that it can never complete, and/or have it
> send unreachables for all of them, especially on a larger network, so I would
> suggest that even if it is "wrong," filter--on-v4 is probably still
> "helpful" in some situations, particularly where v6 is not available. The
> network that I originally posted about is small, but I administer a number of
> larger ones and this has been very eye-opening, so I do thank you all for
> your contributions to the conversation.
>
> It looks like I'd have to compile the filter plugin separately on Windows
> since it's not already integrated, and I don't see a dll or exe for it in the
> bin folder... That's all right though; I'm just glad to have the query times
> be so much quicker now!
>
> In case it's useful for anyone to know, I did just now try running named with
> the -4 option, taking out the server ::/0 { bogus yes; }; and it still has
> the same delay problem, so it appears that even with -4 it's still trying to
> do something on v6 that it shouldn't be doing. So, server ::/0 { bogus yes;
> }; is still the fix... at least on Windows, anyway. Many thanks again to all
> of you for the insightful responses.
>
> -Steve
>
> -Original Message-
> From: bind-users On Behalf Of Mark Andrews
> Sent: Monday, January 20, 2020 1:45 AM
> To: Lee
> Cc: Ondrej Sury
> Subject: Re: Slow recursive query performance on Windows x64
>
> Devices should return ICMP unreachables when networks are not reachable.
> This allows applications to move onto the next address. Not returning
> unreachables results in timeouts being the mechanism to move to the next
> address.
>
> Additionally applications can make parallel connection attempts. This works
> particularly well for TCP and is what Happy Eyeballs does with a slight delay
> (sub second) between each different address. Once a TCP connection succeeds
> the other connection attempts are aborted. Too many developers have coped
> out on providing fast multi-homing support. It usually only takes small
> while to convert a application from serial connection attempts to parallel
> connection attempts to the addresses returned from getaddrinfo(). What s
> more work is adding MIF (multiple interface) support which allows you to try
> different source addresses as well.
>
> Mark
>
>> On 20 Jan 2020, at 17:16, Lee wrote:
>>
>>> On 1/20/20, Ondrej Sur wrote:
>>>
>>> Please note that filter--on-v4 was always wrong.
>>
>> how so?
>>
>>> You should fix your network instead. It s a bandaid, not a fix.
>>
>> My ISP doesn't offer ipv6, so I'm not sure how to fix my network..
>> unless you mean disable ipv6 on everything? (which I'm not sure is
>> even possible)
>>
>> Lee
>> ___
>> 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
>
> ___
> 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
___
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: NSEC3 salt change - temporary performance decline
Hi Niels, > On 21 Jan 2020, at 15:43, Niels Haarbo via bind-users > wrote: > > Hello BIND users > > Our DNSSEC signer changes NSEC3 salt every 30 days. The signer resigns all > the relevant records and the zone is transferred using IXFR to the > authoritative servers (6 nodes). Just don’t do that, there’s no sensible reason to change salt that often (or ever). I don’t know where the advice to change salt often comes from, but the advice has been wrong for so many years. > Two of the 6 authoritative servers (BIND 9.11.13 and 9.11.14) are affected by > a performance decline shortly after the change of salt. This has happened > after the last 3 changes of salt and the period of performance decline is > within 30 – 90 minutes. Most queries are dropped by the affected nodes during > the period. The normal rate is between 1.000 and 1.500 queries/second. > > Other nodes running NSD and Knot are not affected. > > What could be the reason for the performance decline? We are currently investigating performance degradation related to big IXFRs. Do you use ixfr-from-differences in your BIND configuration? You could try enforcing AFRX on salt change. This is currently tracked as https://gitlab.isc.org/isc-projects/bind9/issues/1447 and associated feature request: https://gitlab.isc.org/isc-projects/bind9/issues/1515 Ondrej -- Ondřej Surý ond...@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: NSEC3 salt change - temporary performance decline
NSEC3 is like a toilet window. You want it translucent, not transparent. For that purpose, it serves well. -- Ondřej Surý — ISC > On 21 Jan 2020, at 17:05, Jim Reid wrote: > > > >> On 21 Jan 2020, at 15:59, Daniel Stirnimann >> wrote: >> >> I agree that re-salting is kind of pointless > > So, just like NSEC3 then? :-) > > ___ > 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: checkzone from stdin?
Matt, this has been merged into March release 9.17.0: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/2552 Unfortunately, we don’t backport new features, so either you need to follow the 9.17 track or backport the patch yourself. It should be fairly straightforward to backport it to 9.16 branch since the codebases don’t differ much yet. Ondrej -- Ondřej Surý — ISC > On 8 Apr 2020, at 20:58, Matthew Pounsett wrote: > > > > It looks to me like named-checkzone isn't able to read a zone file from > stdin. > > % cat example.com.db | named-checkzone example.com - > zone example.com/IN: loading from master file - failed: file not found > zone example.com/IN: not loaded due to errors. > > % cat example.com.db | named-checkzone example.com > usage: named-checkzone [-djqvD] [-c class] [-f inputformat] [-F outputformat] > [-J filename] [-t directory] [-w directory] [-k (ignore|warn|fail)] [-n > (ignore|warn|fail)] [-m (ignore|warn|fail)] [-r (ignore|warn|fail)] [-i > (full|full-sibling|local|local-sibling|none)] [-M (ignore|warn|fail)] [-S > (ignore|warn|fail)] [-W (ignore|warn)] [-o filename] zonename filename > > If I'm missing something in the man page, could someone provide me with the > appropriate clue? If it's not, what are the chances this feature could show > up in a future version? > > In my particular case this would help with reading in zones stored as > compressed files, so that I can pipe the decompression directly into > named-checkzone without having to do an extra write to disk. I can imagine > it may be useful to others, in different situations, as well. > ___ > 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: bind v9.16.2 build, inconsistent GeoIP2 configuration options usage ?
Hi,
you are right this is a bit confusing, but you need to specify both:
--enable-geoip (as the feature independent of used libraries)
--with-maxmindsb (where to find the libraries)
Ondrej
--
Ondřej Surý — ISC
> On 15 Apr 2020, at 22:07, PGNet Dev wrote:
>
> cosmetic config error
>
> building 9.16.2, config options include
>
> --disable-geoip support GeoIP2 geolocation ACLs if available
> [default=yes]
>
> (this^^ is confusing usage; do you DISABLE-geoip in order TO 'support GeoIP2
> geolocation ACLs if available' ?
> shouldn't that be "--enable-geoip" [default=yes]?)
>
>
>
> ...
> --with-geoip2 deprecated, use --with-maxminddb
> --with-maxminddb=PATH Build with MaxMind GeoIP2 support (auto|yes|no|path)
> [default=auto]
>
> since I have installed GeoIP2*,
>
>pkg-config --cflags --libs libmaxminddb
>-I/usr/local/include -L/usr/local/lib64 -lmaxminddb
>
>ls -al /usr/local/{include,lib64}/*maxmind*
>-rw-r--r-- 1 root root 507 Mar 18 18:27
> /usr/local/include/maxminddb_config.h
>-rw-r--r-- 1 root root 8.4K Mar 18 18:27 /usr/local/include/maxminddb.h
>-rwxr-xr-x 1 root root 943 Mar 18 18:27
> /usr/local/lib64/libmaxminddb.la*
>lrwxrwxrwx 1 root root 21 Mar 18 18:27
> /usr/local/lib64/libmaxminddb.so -> libmaxminddb.so.0.0.7*
>lrwxrwxrwx 1 root root 21 Mar 18 18:27
> /usr/local/lib64/libmaxminddb.so.0 -> libmaxminddb.so.0.0.7*
>-rwxr-xr-x 1 root root 122K Mar 18 18:27
> /usr/local/lib64/libmaxminddb.so.0.0.7*
>
>ls -al /var/lib/GeoIP2/
>total 71M
>drwxr-xr-x 2 named root 4.0K Apr 2 03:15 ./
>drwxr-xr-x 85 root root 4.0K Apr 12 19:11 ../
>-rw-rw-r-- 1 named root 6.4M Apr 15 12:09 GeoLite2-ASN.mmdb
>-rw-rw-r-- 1 named root 61M Apr 15 12:09 GeoLite2-City.mmdb
>-rw-rw-r-- 1 named root 3.7M Apr 15 12:09 GeoLite2-Country.mmdb
>
> and *DO* want to "support GeoIP2 geoloc ACLs", building here with
>
>--disable-geoip=yes \
>--with-maxminddb=/var/lib/GeoIP2 \
>
> FAILs with
>
>configure: error: invalid feature name: geoip=yes
>
> switching to
>
> ---disable-geoip=yes \
> +--disable-geoip \
>--with-maxminddb=/var/lib/GeoIP2 \
>
> configure completes, reporting 'old' GeoIP support is correctly DISabled
> but there's NO mention of GeoIP2/Lite support, i.e., *maxminddb
>
>Optional features enabled:
>Mutex lock type: adaptive
>IPv6 support (--enable-ipv6)
>Python tools (--with-python)
>XML statistics (--with-libxml2)
>JSON statistics (--with-json-c): -I/usr/include/json-c -ljson-c
>HTTP zlib compression (--with-zlib)
>LMDB database to store configuration for 'addzone' zones (--with-lmdb)
>IDN support (--with-libidn2)
>Print backtrace on crash (--enable-backtrace)
>Use symbol table for backtrace, named only (--enable-symtable)
>Use GNU libtool (--with-libtool)
>DNSSEC validation active by default (--enable-auto-validation)
>Dynamically loadable zone (DLZ) drivers:
>None
>
> ---
>Features disabled or unavailable on this platform:
>...
>GeoIP2 access control (--enable-geoip)
>...
>
> after subsequent
>
>make depend
>make
>make install
>
>named -v
>BIND 9.16.2 (Stable Release)
>
> checking, the maxmind lib *is* linked
>
>ldd `which named`
>libmaxminddb.so.0 => /usr/lib64/libmaxminddb.so.0 (0x7f94618d8000)
>
>
> so, *is* available GeoIP2 support with available DBs enabled, and this is
> just a _reporting_ error?
> or is it not correctly/completely enabled ... ?
>
> what is the correct, complete config specification for using installed GeoIP2
> support?
> ___
> 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: Debian/Ubuntu: Why was the service renamed from bind9 to named?
> On 15 Apr 2020, at 09:05, Reindl Harald wrote: > > BTW in case Debian/Ubuntu when they do RTFM it wouldn't be an issue at all Is this the case of you being rude instead of getting the facts? bind9 (1:9.15.3-2) unstable; urgency=medium * Fix the section for bind9 alias in the systemd unit [GL #1193] -- Ondřej Surý Wed, 28 Aug 2019 21:35:44 +0200 $ cat named.service [Unit] Description=BIND Domain Name Server Documentation=man:named(8) After=network.target Wants=nss-lookup.target Before=nss-lookup.target [Service] EnvironmentFile=-/etc/default/named ExecStart=/usr/sbin/named -f $OPTIONS ExecReload=/usr/sbin/rndc reload ExecStop=/usr/sbin/rndc stop [Install] WantedBy=multi-user.target Alias=bind9.service -- Ondřej Surý ond...@isc.org signature.asc Description: Message signed with OpenPGP ___ 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: Debian/Ubuntu: Why was the service renamed from bind9 to named?
Klaus, the default and preferred init system on both Debian and Ubuntu is systemd, and the unit has proper Alias, so it is recognized also under "bind9" name. The sysv-rc script doesn’t have the capability of aliases, so unfortunately, there’s a downfall from the renaming, but it would not make sense to have a different name for different init systems. If you are using sysvinit, the choice and the suffering that comes from that choice is all yours. The renaming was done as it was a logical choice, the service is starting a daemon, and not a package, and daemon name is `named`. Also it is the name used by RPM based systems and Arch Linux and Gentoo, so it was also made to make BIND 9 packages in Debian/Ubuntu more unified with rest of the Linux world. Ondrej -- Ondřej Surý ond...@isc.org > On 15 Apr 2020, at 08:51, Klaus Darilion wrote: > > Hello! > > What is the rationale of: > > bind9 (1:9.13.6-1) experimental; urgency=medium > ... > * Rename the init scripts to named to match the name of the daemon > > > Since years, Debian and Ubuntu User, and plenty of scripts and automation > software (Puppet ...), know that the service is called "bind9". I think it is > very confusing and will cause lots of headaches once Ubuntu 18.04 or Debian > 11 is released. > > So I really do not understand this renaming. > > The software is "Bind 9". The package is "bind9". The service for long time > was "bind9". The config is in /etc/bind. Only the binary is named. So it > would have made more sense to rename the binary. (actually the binary is not > so important for end users: they install the package and manage the service > and usually do not have to worry about the name of the binary). > > It would be great if you undo this change before release of 18.04. > > regards > Klaus > ___ > 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 signature.asc Description: Message signed with OpenPGP ___ 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.16.2 on centos6
Carl, I would suggest starting with vanilla libuv from sources, or at least review the patches the RPM applies on top of the RPM. Also please be aware of https://gitlab.isc.org/isc-projects/bind9/-/blob/v9_16/PLATFORMS.md CentOS 6 reaches EOL in few months, so everyone should plan their upgrades now. Ondřej -- Ondřej Surý — ISC > On 18 Apr 2020, at 22:45, Carl Byington via bind-users > wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Centos6, although old, is still supported, so it would be nice to get > 9.16.2 running on that. This is my first attempt at building 9.16.x. > > I pulled the libuv source rpm from Centos7, made some minor changes to > the spec file, and built libuv 1.34.0. > > Using that, bind 9.16.2 builds to an rpm and installs, but crashes on > startup. > > (gdb) bt > #0 0x0033772324f5 in raise (sig=6) >at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > #1 0x003377233cd5 in abort () at abort.c:92 > #2 0x7f2f5fba9cc4 in uv_async_send () from /usr/lib64/libuv.so.1 > #3 0x7f2f5fdf6329 in isc_nm_pause (mgr=0x7f2f5f945010) at > netmgr.c:322 > #4 0x7f2f5fe06e07 in isc_task_beginexclusive (task0= optimized out>) >at task.c:1662 > #5 0x0043613f in load_configuration ( >filename=0x7f2f59eac770 "\030\307\060O/\177", server=0x7f2f5c0a8010, >first_time=true) at ./server.c:8309 > #6 0x0043a27d in run_server (task=, > event=0x0) >at ./server.c:9660 > #7 0x7f2f5fe07b21 in dispatch (queuep=) >at task.c:1152 > #8 run (queuep=) at task.c:1344 > #9 0x003c18807aa1 in start_thread (arg=0x7f2f59ead700) >at pthread_create.c:301 > #10 0x0033772e8c4d in clone () >at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 > > > Is this the same issue previously reported against 9.16.1? That was > apparently resolved by downgrading to libuv 1.35. In my case, I can try > to upgrade to 1.35. > > The test in configure.ac in the bind source checks that the version of > libuv is >= 1.0.0. > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.14 (GNU/Linux) > > iEYEAREKAAYFAl6bZrgACgkQL6j7milTFsFDTQCfUw2AaohJDFUN1NljCf6RDs1X > 6QsAn3Dh+4VK1t+k2f7mO/cNjPM+fvL9 > =Ilbj > -END PGP SIGNATURE- > > > ___ > 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
[dev] Change in the build system - please test
Hey all, the work to upgrade BIND 9 to use automake and more declarative syntax has been completed to a state where the majority of the work was merged to the development branch and it will be included in the next major release (e.g. BIND 9.18). However because this is a big change, I would like to invite people interested in the BIND 9 development to actively go and try it. All you need to do is: git clone --depth=1 https://gitlab.isc.org/isc-projects/bind9.git cd bind9 autoreconf -fi ./configure && make && make install # as usual Few things needs to be said: * You should read the main commit description: https://gitlab.isc.org/isc-projects/bind9/-/commit/978c7b2e89aa37a7ddfe2f6b6ba12ce73dd04528 * You should look at the list of linked issues to the main (#4) issue which contains list of not-yet-done work: https://gitlab.isc.org/isc-projects/bind9/-/issues/4 If there’s an issue you found and it’s small, try to look at the list of existing issues and add it if it fits, or just add a comment on the issue #4. If the problem is reasonable big and contained, feel free to open new issue for it (and probably link it in the comment in issue #4). Thank you, Ondrej -- Ondřej Surý ond...@isc.org signature.asc Description: Message signed with OpenPGP ___ 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: Bind9 shared cache
Hi, in my experience with building yet another DNS resolver from scratch was that the gain from the shared networked cache was heavily paid in the latency. I would encourage you to actually do a performance testing with cold and hot cache and my educated guess is that shared redis cache will help with bootstrapping, but once you reach a state where most of the answers are already in the cache there’s no or negative benefit from it. I believe that in most scenarios the increased complexity in not worth the benefit gained. Ondrej -- Ondřej Surý — ISC > On 19 Apr 2020, at 12:27, Talkabout wrote: > > > Hi all, > > I am considering to switch from Unbound to Bind9 to use as DNS Server, but I > have a requirement that seems to not being possible with Bind9. > > Currently I am using 2 Unbound DNS Servers configured to use Redis (KeyDB as > a drop-in replacement in my case) to make sure that both Servers are sharing > the same Cache. That way, when server1 resolves an address and puts it into > the backend database, server2 does not Need to execute Resolution for this > address any more but gets it fast from the shared Cache. > > I have not found any way in the Bind9 documentation to achieve a similar > Thing. So my Questions are: > > Is there a way to configure a shared Cache that is used by multiple Servers? > Is there a way to configure custom backends for Bind9? > Are there any plans to support similar Scenarios? Maybe via a Synchronisation > mechanism? > > Thanks! > > Bye > > Gesendet von Mail für Windows 10 > > ___ > 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: Machine friendly alternative to nsupdate
I would recommend dnspython as a start. The API is very non-Python, but once you get hang of it, it’s not that bad. Ondrej -- Ondřej Surý ond...@isc.org > On 1 Apr 2020, at 15:21, Petr Bena wrote: > > like a "proper DNS library" you talk about, is there any such a thing? signature.asc Description: Message signed with OpenPGP ___ 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 - many doubts
> On 2 Apr 2020, at 17:58, Warren Kumari wrote: > > If you are running an older machine and older kernel, the > /dev/random source is blocking Then just use /dev/urandom, both random and urandom are CSPRNG. Ondrej -- Ondřej Surý ond...@isc.org signature.asc Description: Message signed with OpenPGP ___ 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: Cannot build on macOS 10.15 (Catalina)
LIBUV_LIBS="-L$/dependencies/libuv/lib“ JFTR this part of the line is wrong as it actually doesn’t contain the library itself (just LDFLAGS). You should really use the pkgconfig. Ondrej -- Ondřej Surý ond...@isc.org > On 28 Apr 2020, at 19:36, Eddy Hahn wrote: > > LIBUV_LIBS="-L$/dependencies/libuv/lib" signature.asc Description: Message signed with OpenPGP ___ 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: Cannot build on macOS 10.15 (Catalina)
> On 28 Apr 2020, at 21:15, Tony Finch wrote: > > (Building autoconfiscated code to link to libraries installed in /opt or > ~/lib or wherever has been utterly horrible since the 1990s and libtool > has made it much slower and harder to debug, so I don't expect it will > ever work well.) On Linux, just put the path to /etc/ld.so.conf.d/local.conf and that should do the trick. I don’t know how to configure the dynamic linker on macOS. Ondrej -- Ondřej Surý ond...@isc.org signature.asc Description: Message signed with OpenPGP ___ 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: Cannot build on macOS 10.15 (Catalina)
Hi Eddy,
as I have already told you in the issue you’ve created, there error when
building comes from the configure step. The way you mangle LIBUV_CFLAGS and
LIBUV_LDFLAGS is wrong. You need to set correct PKG_CONFIG_PATH (to patch that
contains libuv.pc), so configure finds libuv.
To fix the runtime problem you need to configure dynamic linker to find the
libuv library. (Or use rpath linker option.)
Actually both problems stems from the fact that you installed libuv into
nonstandard location. I would suggest to use homebrew or macports to install
the dependencies.
Ondrej
--
Ondřej Surý — ISC
> On 28 Apr 2020, at 19:37, Eddy Hahn wrote:
>
> Hi,
>
> I got the latest source and build tools.
>
> 1) autorecon -If. WORKED!
>
> 2) configure WORKED!
>
> LIBUV_LIBS="-L$/dependencies/libuv/lib"
> LIBUV_CFLAGS="-I$/dependencies/libuv/include"
> CPPFLAGS=“-I$/dependencies/libuv/include" LDFLAGS='-flat_namespace
> -force_flat_namespace' ./configure --prefix=“/opt/target"
> --with-openssl="/dependencies/openssl" --disable-pthread-rwlock
> --with-libxml2=no --enable-full-report
>
>
> There are two issues
>
> 1) make - FAILS
>
> it fails because the declaration of the uv_handle_get_data and
> uv_handle_set_data does not match the declaration between uv-compat.h and
> uv.h
>
> In file included from netmgr/netmgr.c:33:
> In file included from netmgr/netmgr-int.h:34:
> netmgr/uv-compat.h:24:1: error: static declaration of 'uv_handle_get_data'
> follows non-static declaration
> uv_handle_get_data(const uv_handle_t *handle) {
> ^
> /opt/serverplus/dependencies/libuv/include/uv.h:448:17: note: previous
> declaration is here
> UV_EXTERN void* uv_handle_get_data(const uv_handle_t* handle);
> ^
> In file included from netmgr/netmgr.c:33:
> In file included from netmgr/netmgr-int.h:34:
> netmgr/uv-compat.h:31:1: error: static declaration of 'uv_handle_set_data'
> follows non-static declaration
> uv_handle_set_data(uv_handle_t *handle, void *data) {
> ^
> /opt/serverplus/dependencies/libuv/include/uv.h:450:16: note: previous
> declaration is here
> UV_EXTERN void uv_handle_set_data(uv_handle_t* handle, void* data);
>^
> 2 errors generated.
> make[4]: *** [netmgr/libisc_la-netmgr.lo] Error 1
> make[3]: *** [all-recursive] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
>
>
> If I move the declaration from uv-compat.h to uv-compat.c then it compile and
> we removed the inlining.
>
> Comment out these:
>
> #ifndef HAVE_UV_HANDLE_GET_DATA
> static inline void *
> uv_handle_get_data(const uv_handle_t *handle) {
> return (handle->data);
> }
> #endif /* ifndef HAVE_UV_HANDLE_GET_DATA */
>
> #ifndef HAVE_UV_HANDLE_SET_DATA
> static inline void
> uv_handle_set_data(uv_handle_t *handle, void *data) {
> handle->data = data;
> }
> #endif /* ifndef HAVE_UV_HANDLE_SET_DATA */
>
> Add to uv-compat.c
>
> #ifndef HAVE_UV_HANDLE_GET_DATA
> UV_EXTERN void *
> uv_handle_get_data(const uv_handle_t *handle) {
> return (handle->data);
> }
> #endif /* ifndef HAVE_UV_HANDLE_GET_DATA */
>
> #ifndef HAVE_UV_HANDLE_SET_DATA
> UV_EXTERN void
> uv_handle_set_data(uv_handle_t *handle, void *data) {
> handle->data = data;
> }
> #endif /* ifndef HAVE_UV_HANDLE_SET_DATA */
>
>
>
> 2) deployed executable fails to load lib (deployed using make install)
>
> Once the binaries are built and try to start the named up receive the
> following error
>
> ./named -c /named.conf -f -d4
>
>
> dyld: lazy symbol binding failed: Symbol not found: _uv_loop_init
> Referenced from: lib/libisc.1701.dylib
> Expected in: flat namespace
>
> dyld: Symbol not found: _uv_loop_init
> Referenced from: lib/libisc.1701.dylib
> Expected in: flat namespace
>
>
> So, it has something to do with flat namespaces vs. two level namespaces. I
> have tried to add the linker option per macOS documentation as
> LDFLAGS='-flat_namespace -force_flat_namespace’ but the executables and
> libraries still have to level namespaces
>
> Tried to force lib to have flat level as well
>
> otool -hV /lib/libuv.dylib
>
>
> Mach header
> magic cputype cpusubtype capsfiletype ncmds sizeofcmds flags
> MH_MAGIC_64 X86_64ALL 0x00 DYLIB14 1640 NOUNDEFS
> DYLDLINK TWOLEVEL NO_REEXPORTED_DYLIBS
>
>
> otool -hV /lib/libisc.1701.dylib
> Mach header
> magic cputype cpusubtype capsfiletyp
Re: Cannot build on macOS 10.15 (Catalina)
PGK_CONFIG_PATH="/opt/build/tools/pkg-config" ^^^ there’s a typo and if you need to add paths to more libraries, you need to use colon, like this: PKG_CONFIG_PATH=/usr/local/opt/libxml2/lib/pkgconfig:/usr/local/opt/zlib/lib/pkgconfig: (taken from my work machine with homebrew versions of libxml2 and zlib) Ondrej -- Ondřej Surý ond...@isc.org > On 28 Apr 2020, at 22:12, Eddy Hahn wrote: > > > OK. Before I did not give you the full picture because I did not want to be > to verbose :-) > > It should have been > > export SERVERPLUS_DIR="/opt/serverplus” > git clone https://gitlab.isc.org/isc-projects/bind9.git > cd bind9 > autoreconf -if > LIBUV_LIBS="-L$SERVERPLUS_DIR/dependencies/libuv/lib" LIBUV_CFLAGS=" > -I$SERVERPLUS_DIR/dependencies/libuv/include" CPPFLAGS=" > -I$SERVERPLUS_DIR/dependencies/libuv/include" LDFLAGS='-flat_namespace > -force_flat_namespace' ./configure --prefix="$SERVERPLUS_DIR" > --with-openssl="$SERVERPLUS_DIR/dependencies/openssl" > --disable-pthread-rwlock --with-libxml2=no --enable-full-report > > > > After Ondrej suggestion I have removed all the LIBUV_XXX env variables and > change to > > PGK_CONFIG_PATH="/opt/build/tools/pkg-config" > PKG_CONFIG_PATH="$SERVERPLUS_DIR/dependencies/libuv/lib/pkgconfig" > ./configure --prefix="$SERVERPLUS_DIR" > --with-openssl="$SERVERPLUS_DIR/dependencies/openssl" > --disable-pthread-rwlock --with-libxml2=no --enable-full-report > > > I did not had to change the source code :-) and after deploying no more > complaints from dylib! named is running fine! > > All worked! Thank you very much for the help! > > Thanks again, > > Eddy > > > >> On Apr 28, 2020, at 12:22 PM, Ondřej Surý wrote: >> >> LIBUV_LIBS="-L$/dependencies/libuv/lib“ >> >> JFTR this part of the line is wrong as it actually doesn’t contain the >> library itself (just LDFLAGS). >> You should really use the pkgconfig. >> >> Ondrej >> -- >> Ondřej Surý >> ond...@isc.org >> >>> On 28 Apr 2020, at 19:36, Eddy Hahn wrote: >>> >>> LIBUV_LIBS="-L$/dependencies/libuv/lib" >> > signature.asc Description: Message signed with OpenPGP ___ 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: NAT and Question Section Mismatch
There was a setting in Cisco which would handle the host behind the NAT differently when the DNS traffic passed the matching NAT. I found a bug in the Cisco devices more than 10+ years ago when it would mangle the TTL to `0`. I don’t really remember the details though, but it’s not only the `ip inspect` that might be at fault. Ondrej -- Ondřej Surý ond...@isc.org > On 21 Apr 2020, at 21:14, John Wiles wrote: > > The only ip inspect lines that I could find in the current config are: > > ip inspect dns-timeout 7200 > ip inspect name CCP_HIGH dns > > John > >> -Original Message- >> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of >> Matthew Richardson >> Sent: Tuesday, April 21, 2020 2:55 PM >> To: bind-users@lists.isc.org >> Subject: Re: NAT and Question Section Mismatch >> >> Out of interest, what "ip inspect" settings exist in the Cisco 2911 config? >> >> Do any of these reference "dns"? If so, this may be your problem... >> >> Best wishes, >> Matthew >> >> -- >>> From: John Wiles >>> To: Tony Finch >>> Cc: "bind-users@lists.isc.org" >>> Date: Tue, 21 Apr 2020 14:08:24 -0400 >>> Subject: RE: NAT and Question Section Mismatch >> >>>> -Original Message- >>>> From: John Wiles >>>> Sent: Sunday, April 19, 2020 11:18 PM >>>> To: 'Tony Finch' >>>> Cc: bind-users@lists.isc.org >>>> Subject: RE: NAT and Question Section Mismatch >>>> >>>>>> >>>>>> I am running into a problem that I think is caused by either a >>>>>> misconfiguration in Bind9, our Cisco NAT, or perhaps both. >>>>>> >>>>>> When I am on our internal network, I am able to query both >>>>>> servers and get the appropriate external ip address. However, >>>>>> when I try to do the same thing externally I get "Question >>>>>> section mismatch: got 6.1.1.10.in-addr.arpa/PTR/IN." >>>>> >>>>> I bet this is a PIX/ASA fixup fuxup. >>>>> >>>>> Tony. >>>> >>>> Tony thanks for the response. >>>> >>>> I'm assuming that applies to either DNS inspection and/or the fixup >>>> command. I'm asking the person that handles the cisco config to review. >>>> >>>> I also just realized I forgot to mention that it is a 2911 ISR. >>>> >>>> John >>>> >>> >>> After going through the router config my cisco person is pretty sure that >> there is nothing in the configuration that is causing this. >>> >>> But I'm not so certain since it appears to only affect the hosts that are >>> in the >> NAT. For example, my nslookup results from home: >>> >>>> server 72.162.32.4 >>> Default server: 72.162.32.4 >>> Address: 72.162.32.4#53 >>>> 72.162.32.2 >>> 2.32.162.72.in-addr.arpaname = gw.iotis.org. >>>> 72.162.32.3 >>> ;; ;; Question section mismatch: got 17.1.1.10.in-addr.arpa/PTR/IN ;; >>> ;; Question section mismatch: got 17.1.1.10.in-addr.arpa/PTR/IN ;; ;; >>> Question section mismatch: got 17.1.1.10.in-addr.arpa/PTR/IN ;; >>> connection timed out; no servers could be reached >>> >>>> 72.162.32.4 >>> ;; ;; Question section mismatch: got 25.1.1.10.in-addr.arpa/PTR/IN ;; >>> ;; Question section mismatch: got 25.1.1.10.in-addr.arpa/PTR/IN ;; ;; >>> Question section mismatch: got 25.1.1.10.in-addr.arpa/PTR/IN ;; >>> connection timed out; no servers could be reached >>> >>>> 72.162.32.19 >>> 19.32.162.72.in-addr.arpa name = badmx2.iotis.org. >>>> 72.162.32.18 >>> 18.32.162.72.in-addr.arpa name = badmx.iotis.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 >> >> ___ >> 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 signature.asc Description: Message signed with OpenPGP ___ 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
Transparency Report: Code of Conduct
Dear members of the mailing list, in a sake of the transparency, let me report that we have put two members of this mailing list on the moderation queue for a behavior that is unacceptable for the mailing list - personal attacks are not welcome here. You can find the Code of Conduct that covers the BIND 9 project including this mailing list here: https://gitlab.isc.org/isc-projects/bind9/-/blob/master/CODE_OF_CONDUCT.md If you have concerns please report the behavior that you find in violation of the CoC to the cond...@isc.org rather than addressing this publicly on the list which might not be the best way to de-escalate the conflict. Thank you for keeping this place civil, Ondrej -- Ondřej Surý — ISC___ 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: How to define a name with an empty RRset?
Hi, to create a empty non-terminal (ENT) you should do: non-empty.an-empty-name.example.com. IN TXT Ondrej -- Ondřej Surý ond...@isc.org > On 29 Apr 2020, at 12:22, Alessandro Vesely wrote: > > Hi all, > > the doc says each node has a set of resource information, which may be empty. > But how do I create such a node? If I just write, say: > >an-emty-name.example.com. > > named-checkzone complains about unexpected end of input. > > NULL is not usable in master files. For the time being, I try: > >an-emty-name.example.com. IN RP . . > > However, querying ANY reveals that the name is not actually empty. > > Is there a specific syntax to create an empty name? > > > Best > Ale > -- > > > > > > > > > > > > > > > > > > > > > > > > > ___ > 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 signature.asc Description: Message signed with OpenPGP ___ 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: How to disable recursion on ONE domain? (Bind-9.11.14)
Hi Chris,
why don’t you just delegate the x.y.zzz to the server in the VPN?
Generally, the static-stub should work in this case, but your email doesn’t have
enough details why it would not.
I properly get SERVFAILs with this minimal config:
zone "sury.org" {
type static-stub;
server-names {
"192.168.1.1";
};
};
and named -g reports:
15-May-2020 15:25:00.015 network unreachable resolving '192.168.1.1/A/IN':
2001:503:c27::2:30#53
15-May-2020 15:25:00.015 network unreachable resolving '192.168.1.1//IN':
2001:503:c27::2:30#53
Cheers,
Ondrej
--
Ondřej Surý
ond...@isc.org
> On 15 May 2020, at 14:40, Chris Palmer wrote:
>
> Hi Ondřej
>
> That could work for eliminating the caching delay when the VPN comes up. I'd
> just have to get that into the VPN config so people didn't have to do it
> manually.
>
> Is there any way to stop the recursion for that domain happening in the first
> place though?
>
> Thanks, Chris
>
>
> On 15/05/2020 13:34, Ondřej Surý wrote:
>> Hi Chris,
>> when your vpn comes up, you need to issue:
>> rndc flushtree
>> command to the BIND 9 instance.
>> Ondrej
>> --
>> Ondřej Surý
>> ond...@isc.org
>>> On 15 May 2020, at 14:16, Chris Palmer via bind-users
>>> wrote:
>>>
>>> There is much discussion about recursion but I can't find anything that
>>> matches this use case...
>>>
>>> - In-house Bind-9.11.14 server, master for some local zones, recursion
>>> enabled; not accessible from external networks
>>> - Two views for in-house networks
>>> - Intermittent VPN access from in-house network to another private network
>>> that is master for DNS zone x.y.zzz; this network is not publicly reachable
>>> - Need queries from one of our views for x.y.zzz to be sent to the static
>>> address for the x.y.zzz server that is only reachable via the VPN
>>> - When the VPN is not connected, need the lookup on to fail/timeout rather
>>> than go through the recursion path
>>> - When the VPN is again connected need lookups to succeed without undue
>>> delay.
>>>
>>> Within the required view I have tried a zone with type forward (specifying
>>> forwarders and forward only), and also a zone of type static-stub
>>> (specifying server-addresses). Both work fine when the VPN is up. Both have
>>> two problems though when the VPN is disconnected:
>>> (a) the queries are recursed and an NXDOMAIN response cached.
>>> (b) When the VPN comes back up the cached NXDOMAIN is served until it
>>> expires.
>>>
>>> I have been trying to force a SERVFAIL when the specified servers for that
>>> domain are unreachable, rather than recursing. And presumably that would
>>> then cause the queries to quickly flow to the required servers once they
>>> are reachable again. Is that possible, or is there another approach to this
>>> problem?
>>>
>>> Many thanks, Chris
>>> ___
>>> 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
signature.asc
Description: Message signed with OpenPGP
___
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: How to disable recursion on ONE domain? (Bind-9.11.14)
Hi Chris, when your vpn comes up, you need to issue: rndc flushtree command to the BIND 9 instance. Ondrej -- Ondřej Surý ond...@isc.org > On 15 May 2020, at 14:16, Chris Palmer via bind-users > wrote: > > There is much discussion about recursion but I can't find anything that > matches this use case... > > - In-house Bind-9.11.14 server, master for some local zones, recursion > enabled; not accessible from external networks > - Two views for in-house networks > - Intermittent VPN access from in-house network to another private network > that is master for DNS zone x.y.zzz; this network is not publicly reachable > - Need queries from one of our views for x.y.zzz to be sent to the static > address for the x.y.zzz server that is only reachable via the VPN > - When the VPN is not connected, need the lookup on to fail/timeout rather > than go through the recursion path > - When the VPN is again connected need lookups to succeed without undue delay. > > Within the required view I have tried a zone with type forward (specifying > forwarders and forward only), and also a zone of type static-stub (specifying > server-addresses). Both work fine when the VPN is up. Both have two problems > though when the VPN is disconnected: > (a) the queries are recursed and an NXDOMAIN response cached. > (b) When the VPN comes back up the cached NXDOMAIN is served until it > expires. > > I have been trying to force a SERVFAIL when the specified servers for that > domain are unreachable, rather than recursing. And presumably that would then > cause the queries to quickly flow to the required servers once they are > reachable again. Is that possible, or is there another approach to this > problem? > > Many thanks, Chris > ___ > 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 signature.asc Description: Message signed with OpenPGP ___ 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: How to disable recursion on ONE domain? (Bind-9.11.14)
Sorry, my bad. (Actually it doesn’t matter because it serves well as example
that static-stub configuration fails when the servers are unreachable and it
doesn’t recurse.)
But even with server-addresses it properly servfails when the static-stub
addresses are unreachable.
Perhaps it behaves differently when there’s already cached content?
I suggest you run test BIND instance with -d 99 to see what’s happening.
Ondřej
--
Ondřej Surý — ISC
> On 15 May 2020, at 18:22, Chris Palmer wrote:
>
> Hi Ondřej
>
> At first glance your suggestion looked like what I had done. But...
> I used:
>
> view "a" {
> match-clients { 172.16.n.n/24; }
> allow-recursion { any; };
> zone "x.y.zzz" {
>type static-stub;
>server-addresses {
> 10.n.n.n;
> 10.n.n.m;
>};
> };
> };
>
> If the 10.n.n.n addresses are not reachable, it still recurses and does a
> public query resulting in an NXDOMAIN. However, I don't know what I have done
> differently this time, but the NXDOMAIN is no longer being cached. Each
> attempt causes it to query upstream, and when I bring the VPN up it uses the
> 10.n.n.n server correctly. Which is acceptable, although I'm still unsure why
> it is recursing at all (or at least why I can't prevent it).
>
> Out of curiosity I then changed to what you suggested:
>
> view "a" {
> match-clients { 172.16.n.n/24; }
> allow-recursion { any; };
> zone "x.y.zzz" {
>type static-stub;
>server-names {
> "10.n.n.n";
> "10.n.n.m";
>};
> };
> };
>
> This ALWAYS gives a SERVFAIL though regardless of whether the 10.n.n.n
> addresses are reachable or not...
>
> So I have something that works, although it is sub-optimal when the VPN is
> down.
>
> Cheers, Chris
>
>> On 15/05/2020 14:26, Ondřej Surý wrote:
>> Hi Chris,
>> why don’t you just delegate the x.y.zzz to the server in the VPN?
>> Generally, the static-stub should work in this case, but your email doesn’t
>> have
>> enough details why it would not.
>> I properly get SERVFAILs with this minimal config:
>> zone "sury.org" {
>> type static-stub;
>> server-names {
>> "192.168.1.1";
>> };
>> };
>> and named -g reports:
>> 15-May-2020 15:25:00.015 network unreachable resolving '192.168.1.1/A/IN':
>> 2001:503:c27::2:30#53
>> 15-May-2020 15:25:00.015 network unreachable resolving
>> '192.168.1.1//IN': 2001:503:c27::2:30#53
>> Cheers,
>> Ondrej
>> --
>> Ondřej Surý
>> ond...@isc.org
>>>> On 15 May 2020, at 14:40, Chris Palmer wrote:
>>>
>>> Hi Ondřej
>>>
>>> That could work for eliminating the caching delay when the VPN comes up.
>>> I'd just have to get that into the VPN config so people didn't have to do
>>> it manually.
>>>
>>> Is there any way to stop the recursion for that domain happening in the
>>> first place though?
>>>
>>> Thanks, Chris
>>>
>>>
>>> On 15/05/2020 13:34, Ondřej Surý wrote:
>>>> Hi Chris,
>>>> when your vpn comes up, you need to issue:
>>>> rndc flushtree
>>>> command to the BIND 9 instance.
>>>> Ondrej
>>>> --
>>>> Ondřej Surý
>>>> ond...@isc.org
>>>>> On 15 May 2020, at 14:16, Chris Palmer via bind-users
>>>>> wrote:
>>>>>
>>>>> There is much discussion about recursion but I can't find anything that
>>>>> matches this use case...
>>>>>
>>>>> - In-house Bind-9.11.14 server, master for some local zones, recursion
>>>>> enabled; not accessible from external networks
>>>>> - Two views for in-house networks
>>>>> - Intermittent VPN access from in-house network to another private
>>>>> network that is master for DNS zone x.y.zzz; this network is not publicly
>>>>> reachable
>>>>> - Need queries from one of our views for x.y.zzz to be sent to the static
>>>>> address for the x.y.zzz server that is only reachable via the VPN
>>>>> - When the VPN is not connected, need the lookup on to fail/timeout
>>>>> rather than go through the recursion path
>>>>> - When the VPN is again connected need lookups to succeed without undue
>>>>> delay.
>>>>>
>>>>> Within the required view I have tried a zone with type forward
>>>>> (specifying forwarders and forward only)
Re: nlabels == name->labels
Unfortunately, we still need usable coredump with debugging symbols (the symbols could be external) Just a staring into the code hasn’t brought anything fruitful, unfortunately, and believe me, we tried. Ondrej -- Ondřej Surý — ISC > On 18 May 2020, at 21:27, Kevan Benson wrote: > > > We've recently experienced this same problem on two separate servers after > updating them to 9.16.2 > > May 15 20:10:21 a named[31391]: general: name.c:1738: INSIST(nlabels == > name->labels) failed > May 15 20:10:21 a named[31391]: general: exiting (due to assertion failure) > May 15 20:11:39 a systemd[1]: named-chroot.service: main process exited, > code=killed, status=6/ABRT > May 15 20:11:39 a systemd[1]: Unit named-chroot.service entered failed state. > > This is on CentOS 7.8.2003 in our cases. We updated to that version on April > 28th across our cluster, so it wasn't immediate. The first server had a > problem May 15th at 8:11 PM Pacific time, the second server May 18th at 1:39 > AM Pacific time. > >> Hi, >> >> We recently upgraded to 9.16.2 on FreeBSD 11.3 STABLE and after ~ >> week of use, it died this morning with the following assertion. Any >> ideas what this might be about ? >> May 3 05:36:27 ns named[845]: name.c:1738: INSIST(nlabels == >> name->labels) failed, back trace >> May 3 05:36:27 ns named[845]: #0 0x43c470 in ?? >> May 3 05:36:27 ns named[845]: #1 0x61a3ca in ?? >> May 3 05:36:27 ns named[845]: #2 0x4f96f1 in ?? >> May 3 05:36:27 ns named[845]: #3 0x4fc277 in ?? >> May 3 05:36:27 ns named[845]: #4 0x50e26b in ?? >> May 3 05:36:27 ns named[845]: #5 0x518846 in ?? >> May 3 05:36:27 ns named[845]: #6 0x516359 in ?? >> May 3 05:36:27 ns named[845]: #7 0x56fea1 in ?? >> May 3 05:36:27 ns named[845]: #8 0x63f39c in ?? >> May 3 05:36:27 ns named[845]: #9 0x801e810b6 in ?? >> May 3 05:36:27 ns named[845]: exiting (due to assertion failure) > > ___ > 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 ___ 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: BIND 9.16.1 on CentOS 6
Hi Anand, yes, it is. The broken code was introduced in the glibc 2.26, and generally RedHat/CentOS/Fedora/Debian libc6 already has the required patches. Ubuntu 18.04 (and derivatives) is the only major Linux distribution that doesn’t have the patch yet. Ondrej -- Ondřej Surý ond...@isc.org > On 18 Mar 2020, at 15:33, Anand Buddhdev wrote: > > Hi BIND developers, > > The 9.16.1 release notes say: > > "The system-provided POSIX Threads read-write lock implementation is now > used by default instead of the native BIND 9 implementation. Please be > aware that glibc versions 2.26 through 2.29 had a bug that could cause > BIND 9 to deadlock. A fix was released in glibc 2.30, and most current > Linux distributions have patched or updated glibc, with the notable > exception of Ubuntu 18.04 (Bionic) which is a work in progress. If you > are running on an affected operating system, compile BIND 9 with > --disable-pthread-rwlock until a fixed version of glibc is available." > > CentOS 6 has an older glibc version, 2.12. Is it safe to compile BIND on > CentOS 6 with the system read-write lock implementation? > > Regards, > Anand > ___ > 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 signature.asc Description: Message signed with OpenPGP ___ 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: New releases of BIND are available: 9.11.17, 9.16.1, and 9.17.0
Oh, right. I was hoping Bionic would have a fix by the time we release new BIND 9. The fixed package should be building right now. Ondrej -- Ondřej Surý ond...@isc.org > On 23 Mar 2020, at 11:47, FUSTE Emmanuel > wrote: > > Hello, > > 9.16.1 had been pushed into ISC stable PPA for Bionic, but without the > native Bind read-write lock compilation option. > As expected, my resolvers locked a few minute later. > Thank you for your fixed packages in your PPA. > I hope that the native glibc distribution package update will be > expedited faster. > > > Emmanuel. > ___ > 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 signature.asc Description: Message signed with OpenPGP ___ 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: New releases of BIND are available: 9.11.17, 9.16.1, and 9.17.0
Hi Emmanuel, I made a mistake in the package, so bind9 (1:9.16.1-2+ubuntu18.04.1+isc+3) would be the correct version to use on Ubuntu bionic. If you experience any reproducible locks and crashes, we would be interested in having tcpdump that causes the lockup. Thanks, Ondrej -- Ondřej Surý ond...@isc.org > On 23 Mar 2020, at 13:26, FUSTE Emmanuel > wrote: > > Hi, > > Even with the glibc package from Andrea I experienced locks within minutes. > And with bind9 (1:9.16.1-2+ubuntu18.04.1+isc+2) too. > It seems that there is some other problems. > > I'm back to 9.14.11 for now. > I'll waiting the official fixed glibc package and will do 9.16 > experiments under control. > > Emmanuel. > > Le 23/03/2020 à 11:54, Ondřej Surý a écrit : >> Oh, right. I was hoping Bionic would have a fix by the time we release new >> BIND 9. >> >> The fixed package should be building right now. >> >> Ondrej >> -- >> Ondřej Surý >> ond...@isc.org >> >>> On 23 Mar 2020, at 11:47, FUSTE Emmanuel >>> wrote: >>> >>> Hello, >>> >>> 9.16.1 had been pushed into ISC stable PPA for Bionic, but without the >>> native Bind read-write lock compilation option. >>> As expected, my resolvers locked a few minute later. >>> Thank you for your fixed packages in your PPA. >>> I hope that the native glibc distribution package update will be >>> expedited faster. >>> >>> >>> Emmanuel. >>> ___ >>> signature.asc Description: Message signed with OpenPGP ___ 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-users Digest, Vol 3393, Issue 1
Hi Shubham, I am afraid that bind-users isn’t the right place to teach you the basics of system administration. I would recommend trying reading documentation for your operating system/distribution, using communities like https://serverfault.com/ or self-study - ArchLinux has a very good documentation that generally applies to most Linux distros. Ondřej -- Ondřej Surý — ISC > On 17 Mar 2020, at 06:15, ShubhamGoyal wrote: > > > Dear sir, >I tried whatever you said > but it is not working. > please give me more solutions > > > > On March 16, 2020 at 8:55 PM bind-users-requ...@lists.isc.org wrote: > > Send bind-users mailing list submissions to > > bind-users@lists.isc.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.isc.org/mailman/listinfo/bind-users > > or, via email, send a message with subject or body 'help' to > > bind-users-requ...@lists.isc.org > > > > You can reach the person managing the list at > > bind-users-ow...@lists.isc.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of bind-users digest..." > > > > > > Today's Topics: > > > > 1. how can we restart bind-9.14.11 (ShubhamGoyal) > > 2. Re: how can we restart bind-9.14.11 (Reindl Harald) > > 3. Re: how can we restart bind-9.14.11 (Reindl Harald) > > 4. Re: how can we restart bind-9.14.11 (Matus UHLAR - fantomas) > > > > > > -- > > > > Message: 1 > > Date: Mon, 16 Mar 2020 19:18:39 +0530 (IST) > > From: ShubhamGoyal > > To: bind-users@lists.isc.org > > Subject: how can we restart bind-9.14.11 > > Message-ID: > > <1350384105.17912.1584366519539.javamail.open-xcha...@webmail.cdac.in> > > Content-Type: text/plain; charset="utf-8" > > > > Dear sir, > > I installed bind version 9.14.11 by tar file . it is > > working okk. > > i tried > > 1. systemctl restart named > > 2. /etc/rc.d/init.d/bind restart > > 3. service named restart > > > > But I do not able to restart service. > > please tell me how can i restart bind 9.14.11 > > Best Regards, > > Shubham Goyal > > Cyber Security Group > > Centre for Development of Advanced Computing > > Bangalore > > > > > > [ C-DAC is on Social-Media too. Kindly follow us at: > > Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] > > > > This e-mail is for the sole use of the intended recipient(s) and may > > contain confidential and privileged information. If you are not the > > intended recipient, please contact the sender by reply e-mail and destroy > > all copies and the original message. Any unauthorized review, use, > > disclosure, dissemination, forwarding, printing or copying of this email > > is strictly prohibited and appropriate legal action will be taken. > > > > > > > > -- next part -- > > An HTML attachment was scrubbed... > > URL: > > <https://lists.isc.org/pipermail/bind-users/attachments/20200316/14c4a50d/attachment-0001.htm> > > > > -- next part -- > > A non-text attachment was scrubbed... > > Name: signature.jpg > > Type: image/jpeg > > Size: 7789 bytes > > Desc: not available > > URL: > > <https://lists.isc.org/pipermail/bind-users/attachments/20200316/14c4a50d/attachment-0001.jpg> > > > > > > -- > > > > Message: 2 > > Date: Mon, 16 Mar 2020 14:58:47 +0100 > > From: Reindl Harald > > To: bind-users@lists.isc.org > > Subject: Re: how can we restart bind-9.14.11 > > Message-ID: > > Content-Type: text/plain; charset=utf-8 > > > > > > > > Am 16.03.20 um 14:48 schrieb ShubhamGoyal: > > > ?Dear sir, > > > ?? I installed bind version 9.14.11 by tar file > > > . it is working okk. > > > ??? i tried > > > ??? 1. systemctl restart named > > > 2.? /etc/rc.d/init.d/bind restart > > > 3.? service named restart >
Re: Compile error Bind 9.16.1 on MacOS 10.14.6
Hi Larry,
it seems like your macOS SDK is incomplete or something like this.
Both clock_gettime() and CLOCK_REALTIME are available since Mac OSX 10.12.
Please make sure you have up-to-date Xcode and matching Command Line Utils for
Xcode.
Ondrej
--
Ondřej Surý
ond...@isc.org
> On 24 Mar 2020, at 21:23, Larry Stone wrote:
>
> I’ve been building Bind from source for a number of years on Macintoshes.
> Made my first attempt at Bind 9.16.1 today. After navigating the new
> dependency for libuv and getting a good configure, I tried make and errored
> at:
>
> gcc -include /Users/larry/ServerAppsNoBackup/bind-9.16.1/config.h
> -I/Users/larry/ServerAppsNoBackup/bind-9.16.1 -I../../.. -I./include
> -I./../pthreads/include -I../include -I./../include -I./..
> -I/usr/local/ssl/include -g -O2 -Qunused-arguments -pthread
> -I/usr/local/include -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual
> -Wwrite-strings -Wformat -Wpointer-arith -Wno-missing-field-initializers
> -fno-strict-aliasing -c time.c
> time.c:117:6: warning: implicit declaration of function 'clock_gettime' is
> invalid in C99 [-Wimplicit-function-declaration]
> if (clock_gettime(CLOCKSOURCE, ) == -1) {
> ^
> time.c:117:20: error: use of undeclared identifier 'CLOCK_REALTIME'
> if (clock_gettime(CLOCKSOURCE, ) == -1) {
> ^
> time.c:42:21: note: expanded from macro 'CLOCKSOURCE'
> #define CLOCKSOURCE CLOCK_REALTIME
> ^
> time.c:151:20: error: use of undeclared identifier 'CLOCK_REALTIME'
> if (clock_gettime(CLOCKSOURCE, ) == -1) {
> ^
> time.c:42:21: note: expanded from macro 'CLOCKSOURCE'
> #define CLOCKSOURCE CLOCK_REALTIME
> ^
> 1 warning and 2 errors generated.
> make[3]: *** [time.o] Error 1
> make[2]: *** [subdirs] Error 1
> make[1]: *** [subdirs] Error 1
> make: *** [subdirs] Error 1
>
> Searching has turned up nothing for me.
>
> --
> Larry Stone
> la...@stonejongleux.com
>
>
>
>
>
>
>
>
>
> --
> Larry Stone
> lston...@stonejongleux.com
>
>
>
>
>
> ___
> 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
signature.asc
Description: Message signed with OpenPGP
___
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
Official BIND 9 Docker images (Technology Preview)
Hello everyone, ISC is proud to announce an official Docker images for BIND 9 versions 9.11 (Extended Support Version), 9.16 (Stable Version) and 9.17 (Development Version). Here’s the link to the official docker repository: https://hub.docker.com/repository/docker/internetsystemsconsortium/bind9/general The images are built on top of Ubuntu 20.04 LTS and BIND 9 packages from official ISC PPA (https://launchpad.net/~isc) and will be updated every time there’s a new BIND 9 releases. This is in the phase of technology preview, so I would invite people to test the docker images and provide feedback (both constructive praise and constructive critique are welcome). The feedback could be sent here (the mailing list), or if you think you found an issue to the official repository Please be aware that while this is fairly simple, we would not recommend running this in the production unless you are actually accept that if you run into any problems you are on your own and you will have to do any debugging on your own. Here’s the quickstart: # Recursive DNS Server ## BIND 9.11 docker run \ --name=bind9 \ --restart=always \ --publish 53:53/udp \ --publish 53:53/tcp \ --publish 127.0.0.1:953:953/tcp \ internetsystemsconsortium/bind9:9.11 # BIND 9.16 docker run \ --name=bind9 \ --restart=always \ --publish 53:53/udp \ --publish 53:53/tcp \ --publish 127.0.0.1:953:953/tcp \ internetsystemsconsortium/bind9:9.16 ## Authoritative DNS Server Here you will actually want to provide the desired configuration in /etc/bind/named.conf and primary zones, etc… (e.g. it’s not magic, you will have to configure it). # BIND 9.11 docker run \ --name=bind9 \ --restart=always \ --publish 53:53/udp \ --publish 53:53/tcp \ --publish 127.0.0.1:953:953/tcp \ --volume /etc/bind \ --volume /var/cache/bind \ --volume /var/lib/bind \ --volume /var/log \ internetsystemsconsortium/bind9:9.11 # BIND 9.16 docker run \ --name=bind9 \ --restart=always \ --publish 53:53/udp \ --publish 53:53/tcp \ --publish 127.0.0.1:953:953/tcp \ --volume /etc/bind \ --volume /var/cache/bind \ --volume /var/lib/bind \ --volume /var/log \ internetsystemsconsortium/bind9:9.16 Thanks for any feedback you might have, Ondrej -- Ondřej Surý (He/Him) ond...@isc.org ___ 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: No response from localhost with "allow-query { any; };"
Hi Axel,
the `nc` commands you used for testing neither proves that
it’s that specific `named` listening on that port nor DNS
daemon at all. FWIW it could be a dummy UDP/TCP server
and you would not know.
First you need to use a tool from your operating system
to check what is listening on those ports, and then use
`dig` (or other DNS debugging tool) to send actual DNS
queries.
Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org
> On 1. 9. 2020, at 16:11, Axel Rau wrote:
>
> Hi!
>
> this is a new server, which answers external queries, sends notifies and
> pushes axfrs.
> It does not answer any query from localhost nor shows any notifies from
> master in the logs.
>
> From local:
> root@ns5:/ # nc -v localhost 53
> Connection to localhost 53 port [tcp/domain] succeeded!
> ^C
> root@ns5:/ # nc -vu localhost 53
> Connection to localhost 53 port [udp/domain] succeeded!
>
> From master server:
> [hermes:local/etc/namedb] root# nc -v ns5.lrau.net 53
> Connection to ns5.lrau.net 53 port [tcp/domain] succeeded!
> ^C
> [hermes:local/etc/namedb] root# nc -vu ns5.lrau.net 53
> Connection to ns5.lrau.net 53 port [udp/domain] succeeded!
>
>
> Any help greatly appreciated,
> Axel
>
> PS:
>
> part of named.conf:
> allow-notify {
> hermes-ns5;
> };
> allow-transfer {
> full-trusted;
> ns5-ping;
> ns4-he;
> management-hosts;
> };
> allow-query { any; };
> allow-query-cache { recursive-users; };
> allow-recursion { recursive-users; };
>
>
> root@ns5:/usr/local/etc/namedb/working/slave # named -V
> BIND 9.16.5 (Stable Release)
> running on FreeBSD amd64 12.1-RELEASE-p8 FreeBSD 12.1-RELEASE-p8 GENERIC
> built by make with '--disable-linux-caps' '--localstatedir=/var'
> '--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--with-libxml2'
> '--with-openssl=/usr' '--with-readline=-L/usr/local/lib -ledit'
> '--with-dlz-filesystem=yes' '--disable-dnstap' '--disable-fixed-rrset'
> '--disable-geoip' '--without-maxminddb' '--without-gssapi'
> '--with-libidn2=/usr/local' '--with-json-c' '--disable-largefile'
> '--with-lmdb=/usr/local' '--disable-native-pkcs11' '--without-python'
> '--disable-querytrace' 'STD_CDEFINES=-DDIG_SIGCHASE=1'
> '--enable-tcp-fastopen' '--with-tuning=default' '--disable-symtable'
> '--prefix=/usr/local' '--mandir=/usr/local/man'
> '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd12.1'
> 'build_alias=amd64-portbld-freebsd12.1' 'CC=cc' 'CFLAGS=-O2 -pipe
> -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include
> -fno-strict-aliasing ' 'LDFLAGS= -L/usr/local/lib -ljson-c
> -fstack-protector-strong ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PLUG
> -isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf'
> compiled by CLANG 4.2.1 Compatible FreeBSD Clang 8.0.1
> (tags/RELEASE_801/final 366581)
> compiled with OpenSSL version: OpenSSL 1.1.1d-freebsd 10 Sep 2019
> linked to OpenSSL version: OpenSSL 1.1.1d-freebsd 10 Sep 2019
> compiled with libxml2 version: 2.9.10
> linked to libxml2 version: 20910
> compiled with json-c version: 0.14
> linked to json-c version: 0.15
> compiled with zlib version: 1.2.11
> linked to zlib version: 1.2.11
> threads support is enabled
>
> default paths:
> named configuration: /usr/local/etc/namedb/named.conf
> rndc configuration: /usr/local/etc/namedb/rndc.conf
> DNSSEC root key: /usr/local/etc/namedb/bind.keys
> nsupdate session key: /var/run/named/session.key
> named PID file: /var/run/named/pid
> named lock file: /var/run/named/named.lock
>
> ---
> PGP-Key: CDE74120 ☀ computing @ chaos claudius
>
> ___
> 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
___
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: AppArmor, DHCP, Bind9 issue [SOLVED]
> On 1. 10. 2020, at 17:27, Olivier wrote: > > 1. I'm hesitant to file a bug on Debian about this. As this both involves > Bind9 and AppArmor, would you say it deserves to be implemented and > documented in default Bind9 installation or that it is too specific for this ? Speaking with my Debian Developer hat - I don’t think there’s a bug in Debian. The default AppArmor rules works fine for most installations, and there’s a mechanism to extend the rules (from bottom of /etc/apparmor.d/usr.sbin.named): # Site-specific additions and overrides. See local/README for details. #include Ondrej -- Ondřej Surý (He/Him) ond...@isc.org ___ 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: Upgrading from BIND 9.14.9 to 9.16.3
Jim, I did reply to you on the issue you created, I’ll copy it here for clarity: > You should evaluate the contents of config.log file for proper diagnostics. > > That said, you are most probably missing pkg-config configuration, try > setting PKG_CONFIG_PATH environment variable to a directory where libuv.pc > resides. > > pkg-config --list-all should list libuv. e.g. try $ export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig $ pkg-config --list-all | grep libuv It should say something like this: libuv libuv - multi-platform support library with a focus on asynchronous I/O. If that doesn’t work, you really need to look into config.log, it has all or most of the information needed to properly debug the issue. Ondrej -- Ondřej Surý ond...@isc.org > On 27 May 2020, at 17:57, DeCaro, James John (Jim) CIV DISA FE (USA) via > bind-users wrote: > > Solaris Unix x86 64 bit VM on VMware > > I discovered a new dependency: libuv. libuv also has dependencies: automake > m4 libtool autoconf. I installed the dependencies, then tried installing > various versions of libuv using sh autogen.sh -- then ./configure - make - > make check - make install to install libuv. Back to installing BIND 9.16.3: > ./configure > received an error: 'configure: error: libuv not found'. I > had tried installing libuv 1.0.0. 1.38.0. and 1.9.1 --same result. > libuv files are present in: > > $ find / -name libuv* -print > /usr/local/lib/libuv.so > /usr/local/lib/libuv.la > /usr/local/lib/libuv.so.1 > /usr/local/lib/libuv.a > /usr/local/lib/libuv.so.1.0.0 > /usr/local/lib/pkgconfig/libuv.pc > /usr/include/sys/libuvfs_ki.h > /usr/include/libuvfs.h > /usr/lib/amd64/libuvfs.so > /usr/lib/amd64/libuvfs.so.1 > > I am not clear how to fix this--seems like the ./configure command needs an > option to discover libuv but I am not sure. > Any help would be appreciated. > > > Jim > > > ___ > 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 signature.asc Description: Message signed with OpenPGP ___ 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: [Non-DoD Source] Re: Upgrading from BIND 9.14.9 to 9.16.3
Jim, you need to read up on how to setup the system dynamic linker to add extra
directories with libraries.
Searching for “library path Solaris” shows this as one of the first links:
https://docs.oracle.com/cd/E19205-01/819-5262/aeude/index.html
Ondrej
--
Ondřej Surý — ISC
> On 27 May 2020, at 20:24, DeCaro, James John (Jim) CIV DISA FE (USA)
> wrote:
>
> I ran $ export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig and pkg-config
> --list-all | grep libuv and got the desired results
>
> Since I had tried so many casual fixes in the working directory, I decided to
> try over again so I deleted it and 'un-tared' the original bind-9.16.3
> directory. I ran configure with these options:
> ./configure --enable-full-report --enable-largefile --with-tuning=large
> --with-openssl=/usr/local --sysconfdir=/etc --localstatedir=/var
> --with-gssapi=krb5-config --with-libtool --enable-fixed-rrset
>
> The configure ran with no errors (thank you)
>
> Tried running make and it mostly compiled until the end when I got these
> errors:
>
> ld.so.1: gen: fatal: libuv.so.1: open failed: No such file or directory
> sh: 9085: Killed
> *** Error code 1
> make: Fatal error: Command failed for target `include/dns/enumtype.h'
> Current working directory /tools/DNS_BIND/bind-9.16.3/lib/dns
> *** Error code 1
> make: Fatal error: Command failed for target `include'
> Current working directory /tools/DNS_BIND/bind-9.16.3/lib/dns
> *** Error code 1
> The following command caused the error:
> for i in isc isccc dns ns isccfg bind9 irs samples nulldir; do \
>if [ "$i" != "nulldir" -a -d $i ]; then \
>echo "making all in `pwd`/$i"; \
>(cd $i; make DESTDIR="" all) || exit 1; \
>fi; \
> done
> make: Fatal error: Command failed for target `subdirs'
> Current working directory /tools/DNS_BIND/bind-9.16.3/lib
> *** Error code 1
> The following command caused the error:
> for i in make lib fuzz bin doc nulldir; do \
>if [ "$i" != "nulldir" -a -d $i ]; then \
>echo "making all in `pwd`/$i"; \
>(cd $i; make DESTDIR="" all) || exit 1; \
>fi; \
> done
> make: Fatal error: Command failed for target `subdirs'
>
> I am not sure why it will not create or find the directories from that code.
> sh: 9085: Killed> libuv.so.1 is located in /usr/local/lib/libuv.so.1 --not
> sure why it will not find this since I added the path using the export
> command.
>
> What am I missing please?
>
> Thanks
>
> V/R
> Jim DeCaro
> DISA
> Systems Administrator
> Windows and Unix Server Operations
> FE222/DoDNet Service Section
> Defense Enclave Services Directorate
> ☎ 301-225-8180
> ☎ 301-375-8180
> james.j.decaro3....@mail.mil
> james.j.decaro3@mail.smil.mil
>
> "If you always do what you always did you will always get what you always
> got."
>
>
> -Original Message-
> From: DeCaro, James John (Jim) CIV DISA FE (USA)
> Sent: Wednesday, May 27, 2020 1:28 PM
> To: 'Ondřej Surý'
> Subject: RE: [Non-DoD Source] Re: Upgrading from BIND 9.14.9 to 9.16.3
>
> The export command worked as you outlined. When I try the ./configure again,
> I get another error:
> ./configure: line 14516: syntax error at line 14743: `(' unexpected
>
> I am not sure where it is finding line 14516, and I do not see this error in
> the config.log. Internet searches are confusing. Any help is appreciated.
>
> Sorry this is so challenging
>
>
> V/R
> Jim DeCaro
>
>
> -Original Message-
> From: Ondřej Surý
> Sent: Wednesday, May 27, 2020 12:06 PM
> To: DeCaro, James John (Jim) CIV DISA FE (USA)
> Cc: bind-users@lists.isc.org; Dawson, Keith A CIV DISA FE (USA)
> ; Mcallister, Reginald CTR DISA FE (USA)
>
> Subject: [Non-DoD Source] Re: Upgrading from BIND 9.14.9 to 9.16.3
>
> All active links contained in this email were disabled. Please verify the
> identity of the sender, and confirm the authenticity of all links contained
> within the message prior to copying and pasting the address to a Web browser.
>
>
>
>
>
>
>
> Jim,
>
> I did reply to you on the issue you created, I’ll copy it here for clarity:
>
>> You should evaluate the contents of config.log file for proper diagnostics.
>>
>> That said, you are most probably missing pkg-config configuration, try
>> setting PKG_CONFIG_PATH environment variable to a directory where libuv.pc
>> resides.
>>
>> pkg-config --list-all should list libuv.
>
> e.g. try
>
> $ export PKG_CONFI
Re: automating DS Record submit to parent with 'new' kasp/dnssec-policy support in bind?
Please submit a feature request to our GitLab instance. I can’t guarantee that we will get to it in the timeframe you need, but the mails tend to get lost. Ondrej -- Ondřej Surý — ISC > On 27 May 2020, at 19:35, PGNet Dev wrote: > > On 5/26/20 4:50 PM, Mark Andrews wrote: >> This is where we need to get the registrars to follow standards. They are >> written >> so everyone doesn’t have to cobble together ad-hoc solutions. Hourly scans >> of all >> the DNSSEC delegations by the registrars would do. >> >> push solutions > > sounds reasonable. at very least, better than nothing. > > in the absence of a standards-based solution, any options for hooks in bind > to external scripts, even if ad-hoc? > > e.g., "if when change in DS Record in local bind, then fire this external > script which will manage the DS submit/withdraw via API to registrar" > > a completely de-coupled solution, independent of bind itself, is doable -- > but again, ad-hoc, and seems a step backwards given the nice progress with > dnssec-policy/kasp simplifications in recent versions. > > if that's all there is, know of any existing, proven ad-hoc solutions? > ___ > 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 ___ 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: Upgrade from 9.14 to 9.16 - transfer-source with low source port no longer works.
Hi Ingeborg, please see release notes: https://downloads.isc.org/isc/bind9/9.16.3/RELEASE-NOTES-bind-9.16.3.html This is listed in Known Issues for BIND 9.16.1: > • UDP network ports used for listening can no longer simultaneously be > used for sending traffic. An example configuration which triggers this issue > would be one which uses the same address:port pair for listen-on(-v6) > statements as for notify-source(-v6) or transfer-source(-v6). While this > issue affects all operating systems, it only triggers log messages (e.g. > "unable to create dispatch for reserved port") on some of them. There are > currently no plans to make such a combination of settings work again. Ondrej -- Ondřej Surý ond...@isc.org > On 26 May 2020, at 11:38, Ingeborg Hellemo wrote: > > FreeBSD 11.3-RELEASE-p3 > > This morning I upgraded from BIND 9.14.11 to 9.16.3 via FreeBSD ports. > > Then I realize that my slave server no longer transfer zones from the master. > The zone transfers worked as expected before the upgrade. > > There are no error messages. The slave receives notifies from the master: > > May 26 09:40:35 ludvigsen named[22721]: client @0x81d593f68 > 129.242.4.254#24673: received notify for zone 'av.uit.no' > May 26 09:40:35 ludvigsen named[22721]: zone av.uit.no/IN: notify from > 129.242.4.254#24673: serial 2020052600 > > I can do a 'rndc reload ' without errors: > > May 26 09:57:29 ludvigsen named[22721]: received control channel command > 'reload av.uit.no' > > If I do a full 'rndc reload' I finally get an error: > > May 26 11:08:14 ludvigsen named[25953]: unable to create dispatch for reserved > port 129.242.5.254#53: permission denied > > Since this is a host with serveral virtual interfaces this address/port is set > in named.conf: > >transfer-source 129.242.5.254 port 53; > > The solution was to remove the 'port 53' part of the config, > > > > Finally, the question: > > Has there been some change in when named changes user id and drops privilege > from root? Or some other changes that can explain the error? > > > > > --Ingeborg > -- > Ingeborg Østrem Hellemo -- ingeborg.hell...@uit.no > Dep. of Information Technology --- Univ. of Tromsø > > > > ___ > 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 signature.asc Description: Message signed with OpenPGP ___ 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: [Non-DoD Source] Re: Upgrading from BIND 9.14.9 to 9.16.3
Jim, I would like to point out that ISC does provide a commercial support on BIND 9 as a way to provide funding to develop BIND 9 as open source software. Please let me know if you are interested in hearing more and I can connect you to the sales team. Cheers, Ondrej -- Ondřej Surý — ISC > On 28 May 2020, at 17:56, DeCaro, James John (Jim) CIV DISA FE (USA) via > bind-users wrote: > > Thank you. amd64 does not exist in the /usr/local/lib/ directory. This is > a Solaris 11.4 x86 64 bit system so that may be why. I will keep looking. > > Thanks again > > > V/R > Jim DeCaro > DISA > Systems Administrator > Windows and Unix Server Operations > FE222/DoDNet Service Section > Defense Enclave Services Directorate > ☎ 301-225-8180 > ☎ 301-375-8180 > james.j.decaro3@mail.mil > james.j.decaro3@mail.smil.mil > > "If you always do what you always did you will always get what you always > got." > > > -Original Message- > From: bind-users On Behalf Of Michal Nowak > Sent: Thursday, May 28, 2020 5:13 AM > To: bind-users@lists.isc.org > Subject: Re: [Non-DoD Source] Re: Upgrading from BIND 9.14.9 to 9.16.3 > > All active links contained in this email were disabled. Please verify the > identity of the sender, and confirm the authenticity of all links contained > within the message prior to copying and pasting the address to a Web browser. > > > > > > > >> On 27/05/2020 20:22, DeCaro, James John (Jim) CIV DISA FE (USA) via >> bind-users wrote: >> ld.so.1: gen: fatal: libuv.so.1: open failed: No such file or directory > > ... > >>> >>> $ find / -name libuv* -print >>> /usr/local/lib/libuv.so >>> /usr/local/lib/libuv.la >>> /usr/local/lib/libuv.so.1 >>> /usr/local/lib/libuv.a >>> /usr/local/lib/libuv.so.1.0.0 > > Jim, I believe you installed 64-bit libuv to a 32-bit directory (i.e. > /usr/local/lib/) and that's why linker can't find it. You should have > installed libuv to the 64-bit directory (i.e. /usr/local/lib/amd64/), > e.g. via > > ./configure ... --libdir=/usr/local/lib/amd64 > > PKG_CONFIG_PATH should have been set to 64-bit path too, i.e. > /usr/local/lib/amd64/pkgconfig. > > Michal > ___ > Please visit Caution-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 Caution-https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > Caution-https://lists.isc.org/mailman/listinfo/bind-users > ___ > 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 ___ 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: nsupdate - adding large/split TXT record (2048 bit DKIM key)
I think it’s reasonable for nsupdate to do the chunking on itself. Patches are always welcome, but if you can start by creating issue for us, it would be very much welcome. I can’t offer you any timeframe, but at least it won’t get lost. Ondrej -- Ondřej Surý ond...@isc.org > On 1 Jun 2020, at 12:50, Andreas S. Kerber wrote: > > On Mon, Jun 01, 2020 at 04:11:43AM -0400, vom513 wrote: >> Can anyone point me to an example of how to do this ? I have a script that >> rotates my DKIM keys, and uses nsupdate to publish. With 1024 bit - I must >> be getting by by the skin of my teeth… >> >> When I try 2048 bit, the record is obviously longer. All of my attempts of >> running it through the Rube Goldberg sed machine have failed - nsupdate >> chokes on format. > > Yeah, I had troubles with those 2048 bit DKIM records too. nsupdate will need > it like this: > > server X.X.X.X > zone ag-trek.de > update add test.ag-trek.de. 86400 IN TXT"v=DKIM1; > k=rsa;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3LmxUW2tnM07YbofiOGR3T6KS/BfHmyPYe0GOEEch/abeTjaL3OtuhmVmr4QMe2HV/6n5SBiVh4PE2wZxUcS2LMNbo5Hn7KO3UsTbIxCKuM6jvUpWtJPgC0uBGNkEARQVBSjW9pqYUQYkXzXLEULbu1AThgaUvCbVzWmvTQeEFXbBWP24O/" > > "LkiprI+iKRskRv0qgIOV0CRm32tk4MP/IcZBdjZ3sHrg3myjVJPfSUBOUyISXKRtiwfIgPeCj4V97Q+psmHvnDz9EID0eZaKih8neroRBETYDLFYjd6Pv9JTqrY7jXOHhM4kmOZOUyNXEIz22JVuaNSJbtXzNWTKpyQIDAQAB" > > > Break up the record in chunks of less than 255 byte, enclose each of these > parts with "" and feed nsupdate all of these chunks seperated with a space on > one line. > ___ > 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 signature.asc Description: Message signed with OpenPGP ___ 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: install issue with bionic packaging -- bind9/bionic 1:9.16.3-1+ubuntu18.04.1+isc+2
Hi Marcel, this is unfortunately side-effect of how the PPA is provided. The bind9 package needs debhelper 10 to build, but for Ubuntu Xenial, the debhelper >= 10 is provided only in xenial-backports. Unfortunately, the PPA has only one „knob“ that either enables backports for all Ubuntu releases or none, which in turn leads to bionic-backports to be enabled which pulls newer build toolchain which in turn adds dependency on init-system-helpers >= 1.54. Let me try if I can tweak the dependencies, so I can build with a default set of dependencies. Meanwhile you can add bionic-backports to your apt sources.list to solve the missing dependency. Ondrej -- Ondřej Surý ond...@isc.org > On 20 May 2020, at 12:32, Marcel de Riedmatten wrote: > > Hi all > > Can't seems to find a better place to voice an issue with the > installation of the latest packaging for ubuntu bionic which has home > at https://launchpad.net/~isc/+archive/ubuntu/bind. > > > I meet a dependency issue concerning init-system-helpers which is > currently 1.51 and is asked to be 1.54. Can somebody confirms that ? > > > > screen copy > === > > root@slavedns:~# apt install bind9 > Reading package lists... Done > Building dependency tree > Reading state information... Done > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > bind9 : PreDepends: init-system-helpers (>= 1.54~) but 1.51 is to be > installed > E: Unable to correct problems, you have held broken packages. > > > -- > Marcel de Riedmatten > > ___ > 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 signature.asc Description: Message signed with OpenPGP ___ 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: install issue with bionic packaging -- bind9/bionic 1:9.16.3-1+ubuntu18.04.1+isc+2
Hi Marcel, I think I figured it out how to build without any additional extra dependencies, so the next update of the bind9 package for Ubuntu will not require to have -backports enabled. Thanks for the valuable feedback. Ondrej -- Ondřej Surý ond...@isc.org > On 20 May 2020, at 13:29, Marcel de Riedmatten wrote: > > Le mercredi 20 mai 2020 à 12:42 +0200, Ondřej Surý a écrit : >> Hi Marcel, > >> Let me try if I can tweak the dependencies, so I can build with a >> default set >> of dependencies. Meanwhile you can add bionic-backports to your apt >> sources.list >> to solve the missing dependency. >> > > yes it works now: > > 1) add bionic-backports > 2) apt update > 3) apt install -t bionic-backports init-system-helpers > # 1.56 is installed > 4) business as usual > > As a user i am very happy with that. Thanks for all your involvement. I > wouldn't be hurt if you had better things to do than to fight a > packaging infrastructure. > > > -- > Marcel de Riedmatten > signature.asc Description: Message signed with OpenPGP ___ 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: Dumb Question is an A or AAAA record required?
Missing MX, there’s actually syntax accepted by major SMTP servers to disable SMTP for domain: example.com. MX 0 . Ondrej -- Ondřej Surý — ISC > On 9 Jul 2020, at 16:06, Matthew Richardson wrote: > > On a related issues there were (perhaps long ago) issues if the A record > for a domain had an SMTP server on it, where email could sometimes be > delivered to that A record rather than the MX. I had (again long ago: > 10-15 years) actually seen this occur. > > Do people think that this problem could still occur these days? What sort > of transient (presumably DNS) failure might cause an SMTP server to deliver > to A rather than MX? > > Best wishes, > Matthew > > -- >> From: Anand Buddhdev >> To: "@lbutlr" , bind-users >> Cc: >> Date: Thu, 9 Jul 2020 14:43:04 +0200 >> Subject: Re: Dumb Question is an A or record required? > >>> On 09/07/2020 14:21, @lbutlr wrote: >>> >>> Given a domain that is hosted and used for email and web, is an A >>> record for that domain actually required? >> >> It's not *required*. But see below. >> >>> That is, if bob.tld is hosted by example.com can you simply have >>> >>>NS ns1.example.com >>>NS ns2.example.com >>>MX mx.example.com >>> >>> wwwCNAME www.example.com >>> >>> Without specifying >>> >>>A 11.22.33.444 >> >> These days, many folk try to reach websites by typing just the bare >> domain name without the "www" prefix. >> >> If a user types "bob.tld" into a browser, the browser will issue an >> address lookup for "bob.tld", causing the resolver to ask for A and >> records for "bob.tld". If you don't have an A record at the zone apex, >> the browser will not get back any address and display an error message >> for the user. An alert user might try "www.bob.tld" but most users are >> likely to just give up. >> >> So while it's not *required* to have an address record at the apex, it's >> good practice to have one. >> >> Anand >> ___ >> 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 > > ___ > 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 ___ 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: Bind 9.16.x won't start from systemd
Adrian, your email didn’t contain any useful information we can go by. It’s hard to debug anything by just going „fails not being able to find something“. You will have to provide the list with the logs, etc. if you want people to actually provide helpful advices. And Ged, could we please keep the noise to minimum to the list? Your email was not helpful, so I would appreciate if you could cut the trolling on the list to the minimum. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org > On 8 Jul 2020, at 13:29, G.W. Haywood via bind-users > wrote: > > Hi there, > > On Wed, 8 Jul 2020, Adrian van Bloois wrote: > >> When I try to start bind 9.16.x from systemd it fails not being able to >> find something. When I start it straight from the CMD-line like: >> sudo /usr/local/sbin/named >> There is no problem and it works fine. >> What could be the problem??? > > systemd. > > -- > > 73, > Ged. > ___ > 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 signature.asc Description: Message signed with OpenPGP ___ 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: A And Cname-record
Jukka and others, I would prefer if we didn’t scold people for typos on the mailing list. The typo in the message had no impact on the question itself, and here, we are trying to build community that’s welcoming to newcomers to the wonderful world of DNS. Ondrej -- Ondřej Surý ond...@isc.org > On 18 Jun 2020, at 00:31, Jukka Pakkanen wrote: > > Yes but before going to RFC details one should check the basic spelling and > syntax first... > > -Alkuperäinen viesti- > Lähettäjä: bind-users Puolesta Mark Andrews > Lähetetty: 18. kesäkuuta 2020 0:27 > Vastaanottaja: Bogdan-Stefan Rotariu > Kopio: bind-users@lists.isc.org > Aihe: Re: A And Cname-record > > > >> On 18 Jun 2020, at 07:56, Bogdan-Stefan Rotariu wrote: >> >> Hi, >> >>> On 18 Jun 2020, at 00:44, Ejaz Ahmed wrote: >>> >>> when i am trying to add A and CNAME record together for the same >>> subdomain, getting an error as below, you all kind assistance would >>> be highly appreciated thanks in advance >>> >>> my records are as follows in zone >>> >>> auotdiscover IN A 1.1.1.1 >>> autodiscover IN CNAME autodiscover.acig.com.sa >>> >>> == >>> dns_master_load: acig.com.sa.hosts:102: autodiscover.acig.com.sa: >>> CNAME and other data >>> >>> zone acig.com.sa/IN: loading from master file acig.com.sa.hosts >>> failed: CNAME and other data >>> >>> zone acig.com.sa/IN: not loaded due to errors >> >> CNAME records cannot coexist with any other records last time I’ve >> checked. See section 2.4 from RFC1912[1] >> >> [1] https://tools.ietf.org/html/rfc1912 > > Well it actually goes back to RFC 1034. Unfortunately it wasn’t enforced in > nameservers at the beginning and is still not enforced by some servers. > > 3.6.2. Aliases and canonical names > > ... > > The domain system provides such a feature using the canonical name > (CNAME) RR. A CNAME RR identifies its owner name as an alias, and specifies > the corresponding canonical name in the RDATA section of the RR. If a CNAME > RR is present at a node, no other data should be present; this ensures that > the data for a canonical name and its aliases cannot be different. This rule > also insures that a cached CNAME can be used without checking with an > authoritative server for other RR types. > > Mark > >> — >> Bogdan-Stefan Rotariu >> >> ___ >> 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 > > -- > 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 > > 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 > ___ > 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 signature.asc Description: Message signed with OpenPGP ___ 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: BIND 9 recursive queries returning SERVFAIL for 'legit' domain
Hi Ian, the first thing you should do is to contact the zone owner to fix their nameservers/load-balancer. The zone/domain might be “legit”, but its nameservers are violating the DNS protocol. Maybe you won’t have to maintain a list of exceptions. If that doesn’t work, this is the configuration option you are looking for: https://bind9.readthedocs.io/en/latest/reference.html?highlight=Cookie#server-statement-grammar Ondrej -- Ondřej Surý — ISC > On 17 Jun 2020, at 17:22, Ian Springett wrote: > > > Hi > I have an issue with BIND 9.14.11 and recursive queries to one particular > domain. DIG result is SERVFAIL and ‘bad cookie’ is logged in > /var/log/messages & /var/log/named.run > > The domain has two DNS servers behind a load balancer which is causing the > bad cookie result. Would this in itself be enough to cause the SERVFAIL and > if so is there a way to have exceptions for known ‘good’ domains? > Rgds > Ian > > Ian Springett > Hosted Services Engineer > > Giacom World Networks Ltd > Tel: 0845 305 5577 > Fax: 01482 330194 > Email: ian.spring...@giacom.com > Website: www.giacom.com > > IMPORTANT: > Legally privileged/confidential information may be contained in this message. > If you are not the addressee(s) legally indicated in this message (or > responsible for delivery of the message to such person), you may not copy or > deliver this message to anyone. In such case, you should destroy this > message, and notify us immediately. If you or your employer does not consent > to Internet e-mail messages of this kind, please advise us immediately. > Opinions, conclusions and other information expressed in this message are not > given or endorsed by my firm or employer unless otherwise indicated by an > authorised representative independent of this message. > Please note that neither my employer nor I accept any responsibility for > viruses and it is your responsibility to scan attachments (if any). This > email and any files transmitted are confidential and intended solely for the > use of the individual or entity to which they are addressed. If you have > received this email in error, please notify me by returning the email. > > Giacom World Networks Limited, Company No 03813447 Registered in England & > Wales, Registered Office: Bridge Haven One, Saxon Way, Priory Park, Hessle, > East Yorkshire HU13 9PG. > > ___ > 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 ___ 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
