Re: Centos and RHEL 8 COPR packages

[Kal Feher]

Replying to my own question


I just noticed #1258 in Gitlab bind9/issues is on the same topic.

If the OS release was not listed on the isc copr site, it might be less 
confusing.
On 17 Oct 2019, 11:08 AM +1100, Kal Feher , wrote:
> The copr repositories for centos8 appear to be empty of any packages. Is this 
> deliberate and if so, where can I find the timeline for bind rpms to be added 
> to these repos?
>
> I’ve noted the recent posts regarding changes in package distribution 
> locations. But I don’t see any explicit statement that rhel/centos8 packages 
> are not being built.
>
> --
> 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

Centos and RHEL 8 COPR packages

[Kal Feher]

The copr repositories for centos8 appear to be empty of any packages. Is this 
deliberate and if so, where can I find the timeline for bind rpms to be added 
to these repos?

I’ve noted the recent posts regarding changes in package distribution 
locations. But I don’t see any explicit statement that rhel/centos8 packages 
are not being built.

--
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

Re: named 9.14.6 memory leak, cannot start

[Peter]

On Wed, Oct 16, 2019 at 12:27:39PM +0200, Ondřej Surý wrote:
! Hi Peter,
! 
! we had a similar report in the past,

Ah, that's a good message!

! so maybe you can chime in and add
! the information to the issue here 
https://gitlab.isc.org/isc-projects/bind9/issues/1179 ?

Okay, done.

Further investigation shows the basic memory usage increased by about
factor 10, and the per-zone memory usage increased by factor 100.

So it's not a leak, it just doesn't fit into the available ~1.2GB
user heap space anymore.

cheerio,
P.
___
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: Zone transfers can be lost forever

[Tony Finch]

jean-christophe manciot  wrote:

wow something has chewed up your message and vomited it out again but some
of the remnants are vaguely legible...

> - the debug log shows that the zone transfer has *successfully* taken place
> on the primary towards the secondary server:
>
> - actually, the zone transfer could not have succeeded because the port 53
> was closed on the secondary server for the master

I'm not sure this belief is entirely solid, given what the logs said.

> - indeed, the secondary server has no knowledge of the new data:
>
> # named-checkzone -D -f raw -o - sdxlive.com [snip]

You have to use the -j option to include any changes recorded in the
zone's journal, otherwise you are almost certainly looking at a stale
version of the zone.

If a zone is loaded and running, I usually find it is easier to use `dig
axfr` (or `host -lA` if I don't want DNSSEC clutter), instead of
named-compilezone, and `dig soa` instead of `named-checkzone`.

You can try `nsdiff -m primary -s secondary zone` to verify that the zone
files are consistent , e.g.

$ nsdiff -m pri0.dns.cam.ac.uk -s auth0.dns.cam.ac.uk cam.ac.uk
nsdiff: loading zone cam.ac.uk. via AXFR from auth0.dns.cam.ac.uk
zone cam.ac.uk/IN: loaded serial 1571232847 (DNSSEC signed)
OK
nsdiff: loading zone cam.ac.uk. via AXFR from pri0.dns.cam.ac.uk
zone cam.ac.uk/IN: loaded serial 1571232847 (DNSSEC signed)
OK
$

[ I'm obviously massively biased, but `nsdiff` is amazingly reassuring
when you are doing big DNS provisioning infrastructure changes. ]

> - whatever I try, it seems impossible to retransfer the zone data now that
> the port 53 is open on the primary:

You can:

* run `rndc retransfer` on the secondary

* run `rndc notify` on the master to maybe prompt a retransfer, depending
  on whether the secondaries are up to date

* bump the serial on the primary again to prompt a retransfer by
  persuading the secondaries they are out of date

A primary can't force a transfer to a secondary, it can only send the
secondary a NOTIFY to suggest that the secondary might want to transfer.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Northwest Fitzroy, Sole: Southwesterly 4 to 6, increasing 7 or gale 8. Rough
or very rough becoming very rough or high. Showers. Good, occasionally 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

Zone transfers can be lost forever

[jean-christophe manciot]

Hi there,

Here's the *context*:
*Ubuntu 19.10 / Debian bullseye 11*
*bind9 9.15.4*

*zone "sdxlive.com "
{
type master;
file "/etc/bind/db.sdxlive.com ";

// Publishing and activating dnssec keys
auto-dnssec maintain;

// Using inline signing
inline-signing yes;
*





*allow-transfer { w.x.y.z;};*

*...
*

*}*

I'm experiencing a peculiar situation in both aforementioned distributions:
- I have modified a zone file and incremented its serial number on the
master to 2019101515
- the debug log shows that the zone transfer has *successfully* taken place
on the primary towards the secondary server:




*15-Oct-2019 16:54:59.075 xfer-out: info: client @0x
w.x.y.z#54219 (sdxlive.com ): transfer of
'sdxlive.com/IN ': IXFR started (serial 2019092407
-> 2019101515)15-Oct-2019 16:54:59.075 xfer-out: info: client
@0x w.x.y.z#54219 (sdxlive.com ): transfer
of 'sdxlive.com/IN ': IXFR ended: 1 messages, 14
records, 1412 bytes, 0.001 secs (1412000 bytes/sec)15-Oct-2019 16:55:14.078
xfer-out: info: client @0x w.x.y.z#58529 (sdxlive.com
): transfer of 'sdxlive.com/IN
': AXFR started (serial 2019101515)15-Oct-2019
16:55:14.078 xfer-out: info: client @0x w.x.y.z#58529
(sdxlive.com ): transfer of 'sdxlive.com/IN
': AXFR ended: 1 messages, 36 records, 2906 bytes,
0.001 secs (2906000 bytes/sec)*
- actually, the zone transfer could not have succeeded because the port 53
was closed on the secondary server for the master
- indeed, the secondary server has no knowledge of the new data:


*# named-checkzone -D -f raw -o - sdxlive.com 
db.sdxlive.com.signedzone sdxlive.com/IN : loaded
serial 2019092407 (DNSSEC signed)*
- whatever I try, it seems impossible to retransfer the zone data now that
the port 53 is open:
on the primary:

*rndc freeze sdxlive.com *
*serial number --> 2019101614*

*rndc thaw sdxlive.com *


*A zone reload and thaw was started.Check the logs to see the result.*

*# grep -P "16-Oct-2019 .* xfer-out: .* -> 2019101614"
/var/log/named/debug.log*
*#*
on the secondary server:
# named-checkzone -D -f raw -o - sdxlive.com db.sdxlive.com.signed
zone sdxlive.com/IN: loaded serial 2019092407 (DNSSEC signed)

As a summary:
+ there should be some kind of zone transfer control to check whether the
transfer has really taken place or not
+ there should be a way to manually force a immediate zone transfer from
the master to the secondary server(s) even though only the serial number
has changed

So, are these
+ bugs
+ some missing features
+ or am I missing something?
-- 
Jean-Christophe
___
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

[Ondřej Surý]

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-profit 501(c)(3) public-benefit 
> corporation.  Support and training for BIND 9 are 
> available at https://www.isc.org/support
> 
> command channel listening on 127.0.0.1#953
> general: notice: all zones loaded
> general: notice: running
>