9.10.4 build fails in dlz/modules/filesystem; 9.10.3-P4 ok.

Taking a stab at the new release ... Building 9.10.3-P4' dlz modules on linux/64 ... cd contrib/dlz/modules/ cd ./bdbhpt make ldd dlz_bdbhpt_dynamic.so linux-vdso.so.1 (0x7fffa312c000) libdb-4.8.so => /usr/lib64/libdb-4

Re: 9.10.4 build fails in dlz/modules/filesystem; 9.10.3-P4 ok.

On 04/28/2016 04:54 PM, Mark Andrews wrote: This should fix this. diff --git a/contrib/dlz/modules/filesystem/dlz_filesystem_dynamic.c b/contrib/dlz/modules/filesystem/dlz_filesystem_dynamic.c index 35bed58..cbd5049 100644 --- a/contrib/dlz/modules/filesystem/dlz_filesystem_dynamic.c +++ b/cont

bind v9.16.0 dlz_filesystem_dynamic module build FAILs ?

building 9.16.0, as usual, on linux/64, config + make of core are OK of my two usual module builds, 'dlz_bdbhpt_dynamic' is OK cd contrib/dlz/modules/ cd ./bdbhpt make V=1 ldd dlz_bdbhpt_dynamic.so linux-vdso.so.1 (0x7fffa312c000)

Re: bind v9.16.0 dlz_filesystem_dynamic module build FAILs ?

On 2/19/20 7:41 PM, Mark Andrews wrote: > clang-format reordered the includes alphabetically and “dir.h” depends > on “dlz_minimal.h” for the typedef. > > The following should address this. > > diff --git a/contrib/dlz/modules/filesystem/dir.h > b/contrib/dlz/modules/filesystem/dir.h > index e93

bind v9.16.2 build, inconsistent GeoIP2 configuration options usage ?

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 t

Re: bind v9.16.2 build, inconsistent GeoIP2 configuration options usage ?

On 4/15/20 1:50 PM, Ondřej Surý wrote: > 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) thx i'd also suggest - --with-maxmiddb + --with-libmaxmi

Re: bind v9.16.2 build, inconsistent GeoIP2 configuration options usage ?

On 4/15/20 2:46 PM, PGNet Dev wrote: > On 4/15/20 1:50 PM, Ondřej Surý wrote: >> 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) >

Re: Cannot build on macOS 10.15 (Catalina)

On 4/28/20 12:21 PM, Ondřej Surý wrote: > 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. runtime dynamic linked paths, subject to ENV var changes, are, imo&e, simply a bad idea/recommendation.

automating DS Record submit to parent with 'new' kasp/dnssec-policy support in bind?

i'm migrating/implementing the new `dnssec-policy` usage & KASP workflow in my bind 9.16.3. the new policy does a nice job of streamlining the signing/key mgmt. after key generation/rotation, the 'last step' is submitting new/changed DS Records to the relevant registrar i'd like to automate th

Re: automating DS Record submit to parent with 'new' kasp/dnssec-policy support in bind?

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 re

Re: automating DS Record submit to parent with 'new' kasp/dnssec-policy support in bind?

On 5/27/20 11:56 AM, Ondřej Surý wrote: > Please submit a feature request to our GitLab instance. https://gitlab.isc.org/isc-projects/bind9/-/issues/1890 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

Re: New BIND releases ... 9.16.4: build, 'fatal error: lmdb.h: No such file or directory'

On 6/17/20 12:11 PM, Michael McNally wrote: >9.16.4 - > https://downloads.isc.org/isc/bind9/9.16.4/RELEASE-NOTES-bind-9.16.4.html on lsb_release -rd Description:openSUSE Leap 15.1 Release:15.1 with gcc --version g

Re: New BIND releases ... 9.16.4: build, 'fatal error: lmdb.h: No such file or directory'

On 6/17/20 7:20 PM, PGNet Dev wrote: > to 9.16.4, with my usual build config, including > > --with-lmdb=/usr/local/lmdb \ > > where, > > tree /usr/local/lmdb > /usr/local/lmdb > ├── bin > │   ├── mdb_copy &g

Re: New BIND releases ... 9.16.4: build, 'fatal error: lmdb.h: No such file or directory'

On 6/17/20 9:48 PM, Ondřej Surý wrote: > Virtually everybody except upstream has modified LMDB to follow a normal > directory layout and BIND expect that. > You should just move the header files and library to /usr/local/include and > /usr/local/lib respectively. That's just a silly statement.

Re: New BIND releases ... 9.16.4: build, 'fatal error: lmdb.h: No such file or directory'

On 6/18/20 6:34 AM, Matt Pallissard wrote: > I'd imagine you want CPPFLAGS here. or you can export C_INCLUDE_PATH ... > Edit: `s/CPPFLAGS/CFLAGS` specifically adding '-I/usr/local/lmdb/include' to $CFLAGS makes the build unhappy, here. but, yep! ... there _is_ hoop-jumping that appears to wor

Re: New BIND releases ... 9.16.4: build, 'fatal error: lmdb.h: No such file or directory'

this configure.ac AC_MSG_CHECKING(for lmdb library) AC_ARG_WITH(lmdb, AS_HELP_STRING([--with-lmdb[=PATH]], [build with LMDB library [yes|no|path]]), use_lmdb="$withval", use_lmdb="aut

Re: New BIND releases ... 9.16.4: build, 'fatal error: lmdb.h: No such file or directory'

> but whether lmdb inclusion/usage now _functions_ correctly with that^ > cleanup, i have yet to verify. > checking now ... iiuc @ https://bind9.readthedocs.io/en/latest/manpages.html "The configuration is saved in a file called viewname.nzf (or, if named(8) is compiled with lib

Re: RHEL, Centos, Fedora rpm 9.16.6

On 8/20/20 11:45 AM, Carl Byington via bind-users wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > https://www.five-ten-sg.com/mapper/bind contains links to the source > rpms, and build instructions. How/why are these^ generally different than the isc-maintained pkgs at htt

hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?

DNSSEC signing using Bind 9.16.x's internal/automated key mgmt correctly generates PublishCDS, DSChange, DSState data for the KSK .state. Subsequent published data correctly contains CDS/CDNSKEY data. Most registrars are still incapable of polling for updates, and require, at best, API push of

Re: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?

On 6/10/21 8:38 AM, Tony Finch wrote: I have not, and I also want to be able to do this, and I also want scripting hooks for whenever any keys change so that I can stash them somewhere safer. fyi, perhaps keep an eye on this: https://gitlab.isc.org/isc-projects/bind9/-/wikis/BIND-9-PKCS11 s

Re: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?

On 6/10/21 1:55 PM, Tony Finch wrote: PGNet Dev wrote: fyi, perhaps keep an eye on this: https://gitlab.isc.org/isc-projects/bind9/-/wikis/BIND-9-PKCS11 hmm, maybe, but it's my Spock eye with a single arched eyebrow hehe. well, I _did_ just suggest "keep an eye on it"

Re: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?

On 6/10/21 8:38 AM, Tony Finch wrote: PGNet Dev wrote: Has anyone here on-list figured out how to hook bind's internal signing process to *trigger* and external script to exec those API pushes? I have not, and I also want to be able to do this, and I also want scripting hooks for whe

Re: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?

On 6/15/21 4:40 PM, Tony Finch wrote: How should named say that a key has changed? It's a multithreaded program so it can't fork (not without a single-threaded helper process) so maybe it should fire off a message to a socket that the script machinery can listen to. (Maybe abuse NOTIFY for the pu

Re: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?

On 6/16/21 7:04 AM, Tony Finch wrote: Maaybe. Bare NOTIFY can say which zone's keys have changed, but not what the state transition is, so it isn't what I would consider to be a complete solution. Pulling the thread a bit more, Jan-Piet Mens @ "Alert, backup, whatever on DNS NOTIFY with n

Re: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?

@jpmens was kind enough to share the original basis for the simple perl script referenced above, which to recollection was 'mainly an example taken from the Net::DNS documentation.' Logging of CDS/CDNSKEY generation for workflow https://gitlab.isc.org/isc-projects/bind9/-/issues/1748 -

Intermittent v9.18 build fails on Fedora COPR buildsys, always in `netmgr_test` ?

I'm building bind9 (v9.18.5, atm) on Fedora's COPR infrastructure. Building for Fedora 36, 37 & Rawhide, the builds FAIL randomly/intermittently here For example, with no changes to any source/spec, simply triggering rebuilds, over a period of just a few hours, Time F36

Re: Intermittent v9.18 build fails on Fedora COPR buildsys, always in `netmgr_test` ?

The netmgr unit tests are not meant to run fully in the CI as some of it are time sensitive. You might want to set the CI=true environment variable to reduce the set of the netmgr unit tests to just the more reliable subset. thx, trying that now @ COPR in the case that it does the trick, sho

Re: Intermittent v9.18 build fails on Fedora COPR buildsys, always in `netmgr_test` ?

You might want to set the CI=true environment variable to reduce the set of the netmgr unit tests to just the more reliable subset. thx, trying that now @ COPR with export CI=true in .spec @ https://src.fedoraproject.org/fork/pgfed/rpms/bind/blob/rawhide/f/bind.spec#_357

Re: Intermittent v9.18 build fails on Fedora COPR buildsys, always in `netmgr_test` ?

The netmgr unit tests are not meant to run fully in the CI as some of it are time sensitive. a COPR dev managed to provide the FAIL'd test log from a manual COPR build, cat ./var/lib/mock/fedora-36-x86_64-1661812240.003689/root/builddir/build/BUILD/bind-9.18.5/build/tests/isc/netmgr_t

new dnssec zone OK, error "zone_rekey:dns_zone_getdnsseckeys failed: not found" only in local bind logs ?

i run, named -v BIND 9.18.7 (Stable Release) i've setup dnssec-policy operation for a number of domain. keys are all generated, KSK-derived DS Records are pushed to registrar->root, and all DNSSEC-analyzer tools online report all's good. i can see no functional probl

Re: new dnssec zone OK, error "zone_rekey:dns_zone_getdnsseckeys failed: not found" only in local bind logs ?

hi Think ownership, permission and things like SELinux, AppArmore depending on your OS. on this box, no SELinux or AppArmor in my named.conf directory "/namedb/production"; and for my domain's dnssec key-directory "/keys/dnssec/example.com"; pathnames are relative to chro

Re: new dnssec zone OK, error "zone_rekey:dns_zone_getdnsseckeys failed: not found" only in local bind logs ?

This is a log level bug. This log happens when BIND want to check the parental-agents if the DS has been published. But if you don't have parental-agents set up, the list of keys to check will be empty. Hence the "not found" result. Thanks for reporting, this will be fixed in the next release,

Re: new dnssec zone OK, error "zone_rekey:dns_zone_getdnsseckeys failed: not found" only in local bind logs ?

Which parental-agent to use is up to you. Something you trust. for the moment, let's say 1.1.1.1 But if you don't have parental-agents set up, the list of keys to check will be empty. Hence the "not found" result. i added zone "example.com" IN { type master; file "/

secure/tls access for statistics-channels ?

on named -v BIND 9.18.7 (Stable Release) i've setup statistics, statistics-channels { inet 10.53.53.53 port 5353 allow { sec_trusted; }; inet 127.0.0.1 port 5353 allow {

Re: new dnssec zone OK, error "zone_rekey:dns_zone_getdnsseckeys failed: not found" only in local bind logs ?

In addition to what Matthijs said, please make sure that all path components in /data/chroot/named/keys/dnssec/example.com/  need to have correct permissions, this is easy to get wrong. I've burnt on this too many times. Easiest way how to test is switching to the user that

Re: new dnssec zone OK, error "zone_rekey:dns_zone_getdnsseckeys failed: not found" only in local bind logs ?

is there a way to determine what data is being attempted to write to which file/location on disk? or, generally, any more detail about what "error occurred" ? It will be attempting to write into the key-directory for the zone as defined by named.conf. It will be creating a new file and then re

Re: secure/tls access for statistics-channels ?

can stats channel be config'd for (only) secure access? does it use the 'tls' config, or other? Not at the moment. ok Please note the statistics channel must not be exposed to any unauthorized access, so the most safe way is to expose it only on localhost anyway - and then TLS is just over

procedure for re-signing zones on nsec3param change, when using dnssec-policy full automation?

running bind 9.18.7 i've enabled dnssec-policy signing current KSK & ZSK keys had been generated with dnssec-policy "prod01" { ... nsec3param iterations 5 optout no salt-length 8; ... } noting Change default for

Re: procedure for re-signing zones on nsec3param change, when using dnssec-policy full automation?

On 19. 10. 22 19:48, Mark Andrews wrote: Just reload the server. +1 with the does the DS record need to be touched? i.e., will the changed to nsec3param change the zone's KSK? Let me add that no, DS record is not affected at all by NSEC or NSEC3. dnssec-policy management is doing a nice

after DS RECORD publish/verify, DSStatus stuck @ "rumoured" after manual `rndc dnssec -checkds` update ?

with bind 9.18, config'd for dnssec-policy automated signing, I've a dnssec signed zone, rndc dnssec -status example.com IN external dnssec-policy: test current time: Fri Oct 21 16:14:06 2022 key: 47219 (ECDSAP256SHA256), ZSK

Re: after DS RECORD publish/verify, DSStatus stuck @ "rumoured" after manual `rndc dnssec -checkds` update ?

I exec rndc dnssec -checkds -key 63917 published example.com IN external with dnssec loglevel -> debug, on exec, in logs 2022-10-21T16:55:22.690603-04:00 ns named[36683]: 21-Oct-2022 16:55:22.689 dnssec: debug 1: keymgr: examine KSK example.com/ECDSAP256SHA256/63917 type DS in state R

Re: after DS RECORD publish/verify, DSStatus stuck @ "rumoured" after manual `rndc dnssec -checkds` update ?

The good news it is not stuck. What indicator flags that it IS 'stuck'? Is it explicitly logged? BIND is waiting to make sure the new DS is also known to the validators. The time being evaluated here is the DS TTL, plus parent-propagation-delay, plus retire-safety. All these three values ar

'inline-signing' might go away and be replaced by dnssec-policy ?

i've read this comment 'inline-signing' might go away and be replaced by dnssec-policy now a few times, in posts and in docs currently, WITH 'dnssec-policy' signing enabled & in-use, i've zone "example.com" IN { type master; file "namedb/primary/example.com.zone";

queries for just a few domains fail (NXDOMAIN) for a bind 9.18 non-forwarding config ; forwarding does fix it. problem with 'my' config, or 'their' DNS ?

i run bind 9.18.8 i use root hints; forwarding is, by default, disabled in config with this config, i notice that although lookups for (e.g.) *.dock.io are available in public NS caches, e.g. dig A elb-default.us-east-1.aws.dckr.io @1.1.1.1 ; <<>> DiG 9.18.8 <<>> A elb

Re: queries for just a few domains fail (NXDOMAIN) for a bind 9.18 non-forwarding config ; forwarding does fix it. problem with 'my' config, or 'their' DNS ?

hi, AWS are returning NXDOMAIN instead of NOERROR for empty non terminals. Do you have strict qname minimisation turned on? yup, i do ... qname-minimization strict; ... only because my i understood my reads of BIND to Add QNAME Minimization https://

Re: queries for just a few domains fail (NXDOMAIN) for a bind 9.18 non-forwarding config ; forwarding does fix it. problem with 'my' config, or 'their' DNS ?

QNAME minimisation is a good idea. It comes in two flavours, relaxed and strict. Relaxed tries to cope with some breakages like NXDOMAIN being returned from ENTs. Strict doesn’t. switch to 'relaxed' does, in fact, 'solve' the issue. insofar as, it appears, i no longer require the forward-zom

Re: A beginner's guide to DNSSEC with BIND 9

so I'm interested to hear if this will still be supported or what the roadmap is for deprecating the ability to hand-edit these files for DNSSEC-enabled zones. +1. what "he" (Richard) said! here, or in my 'other thread' ... will be helpful to know. -- Visit https://lists.isc.org/mailman/li

Re: queries for just a few domains fail (NXDOMAIN) for a bind 9.18 non-forwarding config ; forwarding does fix it. problem with 'my' config, or 'their' DNS ?

AWS are aware of the issue and are just taking a long time to address it. noted. pretty sure there's not a %*^$* thing i can do about THAT! NXDOMAIN for ENTs can also be result of not adding delegating NS records to the parent zone when both parent and child zones are served by the same serve

Re: 'inline-signing' might go away and be replaced by dnssec-policy ?

There are two ways of DNSSEC maintenance in BIND. One is the inline-signing approach, that preserves the original zone file. The other is to apply the changes directly to the zone (and zone file) and requires the zone to allow dynamic updates. Since the latest release dnssec-policy requires eit

Re: 'inline-signing' might go away and be replaced by dnssec-policy ?

ls -1 keys/dnssec/example.com/ (empty) ls -1 namedb/primary/example.com* namedb/primary/example.com.zone<== ORIGINAL, unsigned zone file cat etc/named.conf ... zone "example.com" IN { type master; file "namedb/primary/example.com.zone";

Re: 'inline-signing' might go away and be replaced by dnssec-policy ?

the 'inline-signing yes;' is needed IN ADDITION to 'dnssec-policy' in order to _not_ overwrite original zone files/data on signing. I cannot confirm that (9.17.22): sry, fat thumbed copying my reply into email :-/ should have been wrapped in niceties, including "hmm, I can here with 9.18.8 .

Re: new dnssec zone OK, error "zone_rekey:dns_zone_getdnsseckeys failed: not found" only in local bind logs ?

hi, If there are currently no keys that we have to check the DS for, then you may still see this log line. all my zones have now toggled rumoured -> omnipresent. i took no explicit manual action other than letting an arbitrarily long-ish time pass. it just happened ... eventually. re: your

Re: 'inline-signing' might go away and be replaced by dnssec-policy ?

there are separate cases to consider. the docs https://bind9.readthedocs.io/en/latest/reference.html#dnssec-policy-block-definition-and-usage state The dnssec-policy statement requires dynamic DNS to be set up, or inline-signing to be enabled. If inline-signing is enabled,

status openssl v1.1 support?

In Bind 9.11.0-P3's "CHANGES" grep -i openssl CHANGES | grep "1\.1" 4129. [port] Address API changes in OpenSSL 1.1.0. [RT #39532] seems the bug DB is private/closed, so can't see the status of that^. Trying to build against openssl v11x fails @ configure ...

bind 9.11.1, linking with 'supported' OpenSSL fails at use of deprecated/undef'd v10x api symbol, ERR_load_crypto_strings

Upgrading from bind 9.10.3-P5 -> 9.11.1 release on linux64, cat CHANGES ../dns/.libs/libdns.so: undefined reference to `ERR_load_crypto_strings' collect2: error: ld returned 1 exit status --- 9.11.0 released --- ...

Re: [ot] botched KSK rollover

You might want to look at gkg.net fyi @ Gandi rich DNS(SEC) API with XML-RPC call support & docs for python, php, nodejs, perl, ruby & c http://doc.rpc.gandi.net/domain/reference.html ___ Please visit https://lists.isc.org/mailman/listinfo/bin

unable to resolve *.irs.gov at local bind 9.12.0 server ?

I've a local bind 9.12.0 server. Works for virtually all domains. For "irs.gov", it fails, dig A irs.gov ; <<>> DiG 9.12.0 <<>> A irs.gov ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAI

Re: unable to resolve *.irs.gov at local bind 9.12.0 server ?

> Works for me, try figuring out if you have a routing problem getting to > ns[1234].irs.gov. Hm. I've traceroute'd from my local network, & from 2 separate VPNs. I.e., disparate, unrelated nets. All 3 fail at the same points. E.g. at qwest.net, traceroute to ns1.irs.gov (152.216

Re: unable to resolve *.irs.gov at local bind 9.12.0 server ?

On 1/27/18 11:33 AM, Lee wrote: On 1/27/18, PGNet Dev wrote: I've a local bind 9.12.0 server. Works for virtually all domains. For "irs.gov", it fails, works for me on a local bind 9.11.2 server: $ dig a irs.gov. Do you any of // forward first; // forward only; // forwa

Re: unable to resolve *.irs.gov at local bind 9.12.0 server ?

On 1/27/18 1:36 PM, Rob Sargent wrote: Just for grins, try adding these lines to your named.conf file [within the appropriate view] to see if that fixes it. I had to add something like it to get usitc.gov working for my customers: server 152.216.7.164 { send-cookie no; }; # ns1.irs.go

Re: unable to resolve *.irs.gov at local bind 9.12.0 server ?

On 1/27/18 2:47 PM, Rob Sargent wrote: > you should probably also add these so usitc.gov and sss.gov won’t fail if > they fail for you: > > server 63.150.72.5 { send-cookie no; }; # sauthns1.qwest.net > server 208.44.130.121 { send-cookie no; }; # sauthns2.qwest.net. Done, thx.

Re: nested CNAMEs resolution failures?

On 1/29/18 6:03 AM, Tony Finch wrote: > Use the script I posted the other day: > https://lists.isc.org/pipermail/bind-users/2018-January/099481.html > except amended like this In a recent post, I bumped into a similar problem with ns[1234].irs.gov The "no-cookie" solution fixes the problem. Fou

Re: nested CNAMEs resolution failures?

On 1/29/18 7:08 AM, Tony Finch wrote: > PGNet Dev wrote: >> >> Can these response timeouts be accommodated directly in the script? Or >> only by, perhaps, increasing the global query timeouts from default 10 >> sec? > > Yes, there's a bootstrapping proble

frequent client query errors: "rpz_rewrite_name: mismatched summary data" ?

I recently updated to named -v BIND 9.12.0 compiled locally with ... --enable-rpz-nsip --enable-rpz-nsdname --enable-querytrace ... Now, in logs I'm seeing many of these errors, for numerous domain queries, ... F

Re: frequent client query errors: "rpz_rewrite_name: mismatched summary data" ?

ping, anyone? On 2/1/18 10:22 AM, PGNet Dev wrote: I recently updated to named -v BIND 9.12.0 compiled locally with ... --enable-rpz-nsip --enable-rpz-nsdname --enable-querytrace ... Now, in logs I'm seeing many of