Re: Question about dnstap
> On 13 Sep 2022, at 14:34, Peter wrote: > > Apparently, the first connect() happens (after chroot but) before > droppings priviledges. > (The FreeBSD integration script does set -u to UID "bind", by default.) > > So, apparently, fstrm_capture should also run as UID "bind" (and would > then need a proper filespace where it is allowed to create that > socket). Or something else along that line. > > The OP should check if their problem suddenly resolves when doing a > "chmod 777" on that socket (and then devise a suitable design > according to their security policy). My fault indeed, sorry! *blush*. Actually my confusion was slightly more stupid but still a permissions issue. My apologies! Borja. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Question about dnstap
On Tue, Sep 13, 2022 at 12:24:15PM +0200, Petr Špaček wrote:
! On 12. 09. 22 15:49, Peter wrote:
! > On Mon, Sep 12, 2022 at 03:01:38PM +0200, Petr Špaček wrote:
! > ! My testing did not uncover anything problematic.
! > !
! > ! Versions:
! > ! fstrm 0.6.1-1
! > ! protobuf 21.5-1
! > ! protobuf-c 1.4.1-1
! > !
! > !
! > ! A procedure which works:
! > ! - start BIND configured with
! > ! options {
! > ! dnstap { all; };
! > ! dnstap-output unix "/tmp/unix";
! > ! };
! > !
! > ! - after BIND starts run fstrm_capture -t protobuf:dnstap.Dnstap -u
/tmp/unix
! > ! -w /tmp/capture
! > !
! > ! - fire couple queries: sleep 6 && dig bla example
! > !
! > ! - check content of /tmp/capture with dnstap-read: dnstap-read -y
/tmp/cature
! >
! > Negative. Does not work here:
! >
! > /tmp # ls -la capture
! > -rw-r--r-- 1 root wheel 42 Sep 12 15:42 capture
! > /tmp # dnstap-read -y /tmp/capture
! > /tmp # named -V
! > BIND 9.16.30 (Extended Support Version)
! > running on FreeBSD amd64 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2
n250182-0c5ca3f87266[0c5ca3f87266=752f813d6ccc+24] C6R13V1
!
! Unfortunately neither me on Linux or my colleague who testing on FreeBSD are
! able to reproduce the problem you describe.
Okay, thank You for checking. I didn't look into the matter since I
got my things working nevertheless.
It looks a bit different now as not only me is experiencing the
behaviour.
! There is a caveat, though: Without the --split interval option one has to
! terminate fstrm_capture to get data for dnstap-read to consume. That's
! probably by design and outside of our control (in libfstrm).
This would then happen no matter if fstrm_capture is started before or
after named.
Let's have a short look.
truss tells me that named is trying to open the socket, and receives
ECONNREFUSED.
Then, after every 5 seconds (just as the docs say) it tries again, but
now it receives EPERM !
Apparently, the first connect() happens (after chroot but) before
droppings priviledges.
(The FreeBSD integration script does set -u to UID "bind", by default.)
So, apparently, fstrm_capture should also run as UID "bind" (and would
then need a proper filespace where it is allowed to create that
socket). Or something else along that line.
The OP should check if their problem suddenly resolves when doing a
"chmod 777" on that socket (and then devise a suitable design
according to their security policy).
It's a joy to work with you folks, as always. :)
-- PMc
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Question about dnstap
On 12. 09. 22 15:49, Peter wrote:
On Mon, Sep 12, 2022 at 03:01:38PM +0200, Petr Špaček wrote:
! My testing did not uncover anything problematic.
!
! Versions:
! fstrm 0.6.1-1
! protobuf 21.5-1
! protobuf-c 1.4.1-1
!
!
! A procedure which works:
! - start BIND configured with
! options {
! dnstap { all; };
! dnstap-output unix "/tmp/unix";
! };
!
! - after BIND starts run fstrm_capture -t protobuf:dnstap.Dnstap -u /tmp/unix
! -w /tmp/capture
!
! - fire couple queries: sleep 6 && dig bla example
!
! - check content of /tmp/capture with dnstap-read: dnstap-read -y /tmp/cature
Negative. Does not work here:
/tmp # ls -la capture
-rw-r--r-- 1 root wheel 42 Sep 12 15:42 capture
/tmp # dnstap-read -y /tmp/capture
/tmp # named -V
BIND 9.16.30 (Extended Support Version)
running on FreeBSD amd64 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2
n250182-0c5ca3f87266[0c5ca3f87266=752f813d6ccc+24] C6R13V1
Unfortunately neither me on Linux or my colleague who testing on FreeBSD
are able to reproduce the problem you describe.
There is a caveat, though: Without the --split interval option one has
to terminate fstrm_capture to get data for dnstap-read to consume.
That's probably by design and outside of our control (in libfstrm).
Have you terminated fstrm_capture before reading the file?
--
Petr Špaček
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Question about dnstap
On Mon, Sep 12, 2022 at 03:01:38PM +0200, Petr Špaček wrote:
! My testing did not uncover anything problematic.
!
! Versions:
! fstrm 0.6.1-1
! protobuf 21.5-1
! protobuf-c 1.4.1-1
!
!
! A procedure which works:
! - start BIND configured with
! options {
! dnstap { all; };
! dnstap-output unix "/tmp/unix";
! };
!
! - after BIND starts run fstrm_capture -t protobuf:dnstap.Dnstap -u /tmp/unix
! -w /tmp/capture
!
! - fire couple queries: sleep 6 && dig bla example
!
! - check content of /tmp/capture with dnstap-read: dnstap-read -y /tmp/cature
Negative. Does not work here:
/tmp # ls -la capture
-rw-r--r-- 1 root wheel 42 Sep 12 15:42 capture
/tmp # dnstap-read -y /tmp/capture
/tmp # named -V
BIND 9.16.30 (Extended Support Version)
running on FreeBSD amd64 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2
n250182-0c5ca3f87266[0c5ca3f87266=752f813d6ccc+24] C6R13V1
built by make with '--disable-linux-caps' '--localstatedir=/var'
'--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--without-python'
'--with-libxml2' '--with-openssl=/usr' '--with-readline=-L/usr/local/lib
-ledit' '--with-dlz-filesystem=yes' '--enable-dnstap' '--disable-fixed-rrset'
'--disable-geoip' '--without-maxminddb' '--with-gssapi=/usr'
'CFLAGS=-I/usr/include -O2 -pipe -march=haswell -DLIBICONV_PLUG
-fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing '
'LDFLAGS= -fstack-protector-strong ' 'LIBS=-lkrb5 -lgssapi -lgssapi_krb5
-L/usr/local/lib' 'KRB5CONFIG=/usr/bin/krb5-config' '--with-libidn2=/usr/local'
'--without-json-c' '--disable-largefile' '--without-lmdb'
'--disable-native-pkcs11' '--enable-querytrace' '--enable-tcp-fastopen'
'--disable-symtable' '--prefix=/usr/local' '--mandir=/usr/local/man'
'--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd13.1'
'build_alias=amd64-portbld-freebsd13.1' 'CC=cc' 'CPPFLAGS=-DLIBICONV_PLUG
-isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf'
'PKG_CONFIG_LIBDIR=/var/local/ports/usr/ports/dns/bind916/work/.pkgconfig:/usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig'
'PYTHON=/usr/local/bin/python3.8'
compiled by CLANG FreeBSD Clang 13.0.0 (g...@github.com:llvm/llvm-project.git
llvmorg-13.0.0-0-gd7b669b3a303)
compiled with OpenSSL version: OpenSSL 1.1.1o-freebsd 3 May 2022
linked to OpenSSL version: OpenSSL 1.1.1o-freebsd 3 May 2022
compiled with libuv version: 1.42.0
linked to libuv version: 1.42.0
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
compiled with zlib version: 1.2.12
linked to zlib version: 1.2.12
compiled with protobuf-c version: 1.4.0
linked to protobuf-c version: 1.4.0
threads support is enabled
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Question about dnstap
On Mon, Sep 12, 2022 at 12:27:25PM +0200, Borja Marcos wrote:
! I am not sure this is intended behavior, or maybe I should file a bug.
!
! I am doing some tests with dnstap and bind (9.18.6 now but I see the same
behavior with older 9.18 versions). I am using
! dnstap-go.
!
! I have configured bind to use dnstap with no other options and using a Unix
domain socket. (On named.conf, dnstap {all;};).
!
! If I start named but the dnstap collector is not running it will never try to
connect. I need to start the dnstap program
! _before_ starting named.
!
! From the named.conf documentation I assumed that bind would retry the dnstap
connection periodically. (fstrm-reopen-interval).
I don't know if intended or not, but when configuring dnstap I
noticed the same behaviour.
I tried at first to write to a file, but not by any means could I get
the file rotation to work. Then I considered writing to a file that is
a named pipe - but that would require the reading program to reopen
whenever named might be restarted. Finally I resorted to the socket,
and noticed that the reader program now must not be restarted while
named is running.
I can live with that.
bind916-9.16.30
fstrm-0.6.1
protobuf-3.20.1,1
protobuf-c-1.4.0_3
(Probably slightly lower versions at the time of testing.)
FreeBSD 13.1-RELEASE-p2, w/ some patches, all ports locally built,
build logs available on request.
(Maybe FreeBSD 12.3 at the time of testing.)
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Question about dnstap
On 12. 09. 22 12:27, Borja Marcos wrote:
Hi,
I am not sure this is intended behavior, or maybe I should file a bug.
I am doing some tests with dnstap and bind (9.18.6 now but I see the same
behavior with older 9.18 versions). I am using
dnstap-go.
I have configured bind to use dnstap with no other options and using a Unix
domain socket. (On named.conf, dnstap {all;};).
If I start named but the dnstap collector is not running it will never try to
connect. I need to start the dnstap program
_before_ starting named.
From the named.conf documentation I assumed that bind would retry the dnstap
connection periodically. (fstrm-reopen-interval).
Is that correct or I am making a wrong assumption? I think at least it would be
desirable to have bind reconnect in case the dnstap
collector was restarted for whatever reason.
Versions:
bind 9.18.6
fstrm-0.6.1
protobuf-3.20.1,1
protobuf-c-1.4.0_3
My testing did not uncover anything problematic.
Versions:
fstrm 0.6.1-1
protobuf 21.5-1
protobuf-c 1.4.1-1
A procedure which works:
- start BIND configured with
options {
dnstap { all; };
dnstap-output unix "/tmp/unix";
};
- after BIND starts run fstrm_capture -t protobuf:dnstap.Dnstap -u
/tmp/unix -w /tmp/capture
- fire couple queries: sleep 6 && dig bla example
- check content of /tmp/capture with dnstap-read: dnstap-read -y /tmp/cature
Seems all good to me. I suggest checking it using the fstrm tools to the
dnstap-go can be eliminated from the equation.
--
Petr Špaček
--
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
Question about dnstap
Hi,
I am not sure this is intended behavior, or maybe I should file a bug.
I am doing some tests with dnstap and bind (9.18.6 now but I see the same
behavior with older 9.18 versions). I am using
dnstap-go.
I have configured bind to use dnstap with no other options and using a Unix
domain socket. (On named.conf, dnstap {all;};).
If I start named but the dnstap collector is not running it will never try to
connect. I need to start the dnstap program
_before_ starting named.
>From the named.conf documentation I assumed that bind would retry the dnstap
>connection periodically. (fstrm-reopen-interval).
Is that correct or I am making a wrong assumption? I think at least it would be
desirable to have bind reconnect in case the dnstap
collector was restarted for whatever reason.
Versions:
bind 9.18.6
fstrm-0.6.1
protobuf-3.20.1,1
protobuf-c-1.4.0_3
Thanks!
Borja.
--
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
