date:20160323

Re: Regarding compiling BIND 9.10.3-p4 on a SystemD Distro

2016-03-23 Thread Mark Andrews


In message , Tony 
Finch writes:
> Reindl Harald  wrote:
> >
> > > The problem that I alluded to above is that if you have services that
> > > depend on the DNS, there should be a mechanism for the DNS server to say
> > > when it is ready and that it's OK to start services that need DNS. I don't
> > > know the right way to specify that to systemd: maybe it needs a socket
> > > unit file as well?
> >
> > or just don't use "-f" and Type=forking
> >
> > https://www.freedesktop.org/software/systemd/man/systemd.service.html
> >
> > If set to forking, it is expected that the process configured with 
> > ExecStart=
> > will call fork() as part of its start-up. The parent process is expected to
> > exit when start-up is complete and all communication channels are set up.
> 
> BIND does not do that - it forks too early. It's a bit tiresome.

Bind forks early because it can't fork on Linux after it has created
any threads.  For every other OS it forks later after doing thread
creation.  On Linux the fork call only forks the thread not the
process.

That said named does wait for the loading to complete before the
parent process exits and its exit status reflects if the load
succeeded or not.  See ns_os_daemonize() and ns_os_started().

Mark

> log_daemon_msg "Starting name server" "BIND"
> start-stop-daemon --start --oknodo --pidfile $PIDFILE \
>   --name named --user named --group named \
>   --startas $TOP/bin/named \
>   -- -t $TOP -u named -c /etc/named.conf
> i=$(( $? ? 100 : 0 ))
> while   [ $i -lt 100 ] &&
> ! rndc status >/dev/null 2>&1
> do  sleep 0.1
> i=$((i+1))
> done
> chmod g+r $RUN/session.key
> rndc status >/dev/null 2>&1
> log_end_msg $?
> 
> Tony.
> -- 
> f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
> Fair Isle, Faeroes: South or southwest 5 or 6, occasionally 7 later. Moderate
> or rough, occasionally very rough. Rain or showers. Moderate or 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
-- 
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

Re: Reminder of the L-Root IPv6 address renumbering

2016-03-23 Thread John Bond



On 22/03/2016 16:44, Bob Harold wrote:

> I appreciate the announcement of the change ahead of time, but I don't feel
> like it is safe to update my root hints file based on an email, which could
> be spoofed.  It's not that I don't trust you, but someone could spoof your
> email.
> So I am waiting for the new IP to show up in the root zone or some other
> trusted place.  Has it already been published in some place that can be
> verified?  (I should have asked this when it was first announced.)
Caution is always welcome, the new IP is now in the root zone

https://www.internic.net/domain/named.root
___
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

retry limit exceeded / possible network problem?

2016-03-23 Thread Alex

Hi,

I have a fedora23 system with bind-9.10.3 that's been running fine for
a long time. For some reason this morning, queries started timing out.
This is a mail server, so queries to spamhaus, barracuda, etc, started
timing out with:

Mar 23 14:46:57 mail03 postfix/postscreen[12635]: warning: dnsblog
reply timeout 10s for mykey.zen.dq.spamhaus.net

where 'mykey' is the key assigned to me for the service. (this isn't a
"query volume reached" kind of error).

It's almost like there's a firewall blocking outbound access, but
that's not the case. Sometimes queries work, sometimes they timeout:

# host google.com
;; connection timed out; no servers could be reached

Trying the same command again, and it might work. Here's an example
with messagelabs:

# host messagelabs.com
;; connection timed out; no servers could be reached
# host messagelabs.com
messagelabs.com has address 216.12.145.20
messagelabs.com has address 155.64.49.54
;; connection timed out; no servers could be reached
# host messagelabs.com 8.8.4.4
Using domain server:
Name: 8.8.4.4
Address: 8.8.4.4#53
Aliases:

messagelabs.com has address 216.12.145.20
messagelabs.com has address 155.64.49.54
messagelabs.com mail is handled by 10 cluster6.eu.messagelabs.com.
messagelabs.com mail is handled by 20 cluster6a.eu.messagelabs.com.

It does appear to work reliably when using google's nameservers.

Just running "dig" returns all the forward entries for the top-level
servers, but not the reverse. My hints file does have both, however.

Then I noticed these in the bind logs:

23-Mar-2016 15:12:10.603 general: info: zone sbl.example.com/IN:
refresh: retry limit for master 64.11.16.5#53 exceeded (source
0.0.0.0#0)
23-Mar-2016 15:12:10.603 general: info: zone sbl.example.com/IN:
Transfer started.
23-Mar-2016 15:12:10.615 xfer-in: info: transfer of
'sbl.example.com/IN' from 64.11.16.5#53: connected using
68.193.193.45#39699
23-Mar-2016 15:12:10.627 xfer-in: info: transfer of
'sbl.example.com/IN' from 64.11.16.5#53: Transfer status: up to date
23-Mar-2016 15:12:10.627 xfer-in: info: transfer of
'sbl.example.com/IN' from 64.11.16.5#53: Transfer completed: 0
messages, 1 records, 0 bytes, 0.012 secs (0 bytes/sec)

where 'example.com' is my domain. A little googling shows this is the
result of the UDP transfer failing, then falling back to TCP.

This system is running on a Cablevision/Optonline business-class cable
connection. They've said the circuit is operating normally. Could this
still be some kind of network issue? There are no local errors on the
interface, and I've rebooted their modem and even replaced the network
cable.

Perhaps you know of a tcpdump option where I can look for network
retries or some type of packet retransmission/errors?

I'm really stuck, and the mail server isn't functioning while I figure
this out, so any help greatly appreciated.

I've included my named.conf but it was working fine yesterday:

acl "trusted" {
{ 127/8; };
{ 192.168.1.0/24; };
{ 23.224.183.206; };
{ 68.193.193.45; };
};
options {
listen-on port 53 { 127.0.0.1; 68.193.193.45; };
// listen-on-v6 port 53 { ::1; };
listen-on-v6 port 53 { none; };
directory   "/var/named";
dump-file   "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named.stats"; // _PATH_STATS
memstatistics-file "/var/named/data/named.memstats";   // _PATH_MEMSTATS
allow-query { trusted; };
notify master-only;
recursive-clients 5000;
/*
 - If you are building an AUTHORITATIVE DNS server, do NOT
enable recursion.
 - If you are building a RECURSIVE (caching) DNS server, you
need to enable
   recursion.
 - If your recursive DNS server has a public IP address, you
MUST enable access
   control to limit queries to your legitimate users. Failing
to do so will
   cause your server to become part of large scale DNS amplification
   attacks. Implementing BCP38 within your network would greatly
   reduce such attack surface
*/
// recursion yes;
allow-recursion { trusted; };
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
// Record all queries to the box for now
channel query_info {
   severity info;
   file "/var/log/named.query.log" versions 3 size 10m;
   print-time yes;
   print-category yes;
 };
// added for fail2ban support
channel security_file {
   severity dynamic;
   file

Re: Regarding compiling BIND 9.10.3-p4 on a SystemD Distro

2016-03-23 Thread Robert Edmonds

Anand Buddhdev wrote:
> Knot DNS, for example, has a compile-time option to link against systemd
> libraries. Then, when Knot starts, it loads all its zones in, does
> whatever else it needs to do, and then sends a notification via dbus.
> 
> If anyone cares about this, they could open a feature request to add
> Systemd dbus notification support to BIND. Good luck with it :)

Knot actually supports Type=notify (not Type=dbus), which is a lot
simpler.

https://www.freedesktop.org/software/systemd/man/sd_notify.html

Basically, if libsystemd is available, call 'sd_notify(0, "READY=1");'
once the daemon is ready to accept requests.

-- 
Robert Edmonds
___
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: Regarding compiling BIND 9.10.3-p4 on a SystemD Distro

2016-03-23 Thread Anand Buddhdev

On 23/03/16 14:51, Tony Finch wrote:

>> With systemd the methodology isn't that BIND notifies other things that
>> it is up.  It is that other things, if dependent upon BIND, have in
>> their systemd files a requirement that BIND be up before they start.
> 
> Yes, but how does systemd know when BIND is up?
> 
> (The Red Hat and five-ten-sg RPMs don't seem to have an answer.)

Systemd doesn't have any facility to run a script or check after
starting a daemon. If it did (like upstart's post-start stanza), then
you could just run "dig @localhost" in a loop and exit when it succeeds.
Upstart will not emit a "started named" event until the post-start has
completed. This allows other upstart jobs to wait on a "started named"
event before doing their thing.

However, Systemd has support for notifications via dbus. If named is
compiled with support for systemd, then named can send a notification
via dbus after it has started up. Other systemd units that need named to
be up can wait for this notification before starting.

The BIND systemd unit file could contain:

Type=dbus
BusName=named
ExecStart=/usr/sbin/named -f

Now, the named process is expected to acquire the name "named" on the
bus. Any unit that has "Requires=named" or "After=named" will wait until
the name on the bus is acquired.

Knot DNS, for example, has a compile-time option to link against systemd
libraries. Then, when Knot starts, it loads all its zones in, does
whatever else it needs to do, and then sends a notification via dbus.

If anyone cares about this, they could open a feature request to add
Systemd dbus notification support to BIND. Good luck with it :)

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

RE: Regarding compiling BIND 9.10.3-p4 on a SystemD Distro

2016-03-23 Thread Lightner, Jeff

It doesn't.   The systemd script either succeeds or fails.   Any script that is 
dependent on it succeeding won't start.   

Again it is a change.  

In init you'd see a start had failed (or was hung).  

In systemd it simply sends the instruction to start everything that is supposed 
to start.   The upside of this approach is that the rest of your startup 
succeeds as it run asynchronously unless you've included a dependency for the 
thing that failed.It also means a hung script doesn't stop your boot in its 
tracks like it did in init.   You can login and troubleshoot things.

The downside is you don't get the pretty display showing OK or FAILED for each 
script during boot because boot completing is NOT dependent on ALL scripts 
succeeding.

If it is important to you that certain things be up you need to set up 
monitoring.  We do that with Nagios here.

-Original Message-
From: Tony Finch [mailto:fa...@hermes.cam.ac.uk] On Behalf Of Tony Finch
Sent: Wednesday, March 23, 2016 9:52 AM
To: Lightner, Jeff
Cc: bind-users@lists.isc.org
Subject: RE: Regarding compiling BIND 9.10.3-p4 on a SystemD Distro

Lightner, Jeff  wrote:
>
> With systemd the methodology isn't that BIND notifies other things 
> that it is up.  It is that other things, if dependent upon BIND, have 
> in their systemd files a requirement that BIND be up before they start.

Yes, but how does systemd know when BIND is up?

(The Red Hat and five-ten-sg RPMs don't seem to have an answer.)

Tony.
--
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode 
Dogger, Fisher, German Bight, Humber: Northwest backing southwest 3 or 4, 
increasing 5 at times. Slight, occasionally moderate. Fog patches, rain at 
times. Moderate or good, 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

RE: Regarding compiling BIND 9.10.3-p4 on a SystemD Distro

2016-03-23 Thread Tony Finch

Lightner, Jeff  wrote:
>
> With systemd the methodology isn't that BIND notifies other things that
> it is up.  It is that other things, if dependent upon BIND, have in
> their systemd files a requirement that BIND be up before they start.

Yes, but how does systemd know when BIND is up?

(The Red Hat and five-ten-sg RPMs don't seem to have an answer.)

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Dogger, Fisher, German Bight, Humber: Northwest backing southwest 3 or 4,
increasing 5 at times. Slight, occasionally moderate. Fog patches, rain at
times. Moderate or good, 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

Re: Regarding compiling BIND 9.10.3-p4 on a SystemD Distro

2016-03-23 Thread Tony Finch

Reindl Harald  wrote:
> Am 23.03.2016 um 13:36 schrieb Tony Finch:
> >
> > BIND does not do that - it forks too early. It's a bit tiresome
>
> than this is a bug in BIND which should be fixed instead worked around -

Yes.

> the whol epurpose of double-forking is to signal to the caller that
> initialization has finished and the process is fully read to operate

No, the original purpose of double forking was to detach the process from
its parent. Using daemonizing as a signal that the server is ready is a
much newer idea. It is a very good idea, but not the whole idea.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Dogger, Fisher, German Bight, Humber: Northwest backing southwest 3 or 4,
increasing 5 at times. Slight, occasionally moderate. Fog patches, rain at
times. Moderate or good, 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

RE: Regarding compiling BIND 9.10.3-p4 on a SystemD Distro

2016-03-23 Thread Lightner, Jeff

Since there are BIND packages (9.9.4) for RHEL7/CentOS7 available from default 
repositories you could download those packages and extract the systemd files 
from them and examine what they've done.

With systemd the methodology isn't that BIND notifies other things that it is 
up.  It is that other things, if dependent upon BIND, have in their systemd 
files a requirement that BIND be up before they start. 

That is different than Sys V init in which things started one after the other.  
 The idea is a systemd boot is much faster as it doesn't make things wait 
because of order but rather only where there are dependencies.

Also as an FYI Carl Byington regularly post new builds he has done of BIND 
updates for RHEL/CentOS.  
The most recent email he sent was for BIND 9.10 and has a link to:
http://www.five-ten-sg.com/mapper/bind

I haven't used that myself but it probably also contains systemd examples you 
could extract.

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Tony Finch
Sent: Wednesday, March 23, 2016 8:36 AM
To: Reindl Harald
Cc: bind-users@lists.isc.org
Subject: Re: Regarding compiling BIND 9.10.3-p4 on a SystemD Distro

Reindl Harald  wrote:
>
> > The problem that I alluded to above is that if you have services 
> > that depend on the DNS, there should be a mechanism for the DNS 
> > server to say when it is ready and that it's OK to start services 
> > that need DNS. I don't know the right way to specify that to 
> > systemd: maybe it needs a socket unit file as well?
>
> or just don't use "-f" and Type=forking
>
> https://www.freedesktop.org/software/systemd/man/systemd.service.html
>
> If set to forking, it is expected that the process configured with 
> ExecStart= will call fork() as part of its start-up. The parent 
> process is expected to exit when start-up is complete and all communication 
> channels are set up.

BIND does not do that - it forks too early. It's a bit tiresome.

log_daemon_msg "Starting name server" "BIND"
start-stop-daemon --start --oknodo --pidfile $PIDFILE \
--name named --user named --group named \
--startas $TOP/bin/named \
-- -t $TOP -u named -c /etc/named.conf
i=$(( $? ? 100 : 0 ))
while   [ $i -lt 100 ] &&
! rndc status >/dev/null 2>&1
do  sleep 0.1
i=$((i+1))
done
chmod g+r $RUN/session.key
rndc status >/dev/null 2>&1
log_end_msg $?

Tony.
--
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode 
Fair Isle, Faeroes: South or southwest 5 or 6, occasionally 7 later. Moderate 
or rough, occasionally very rough. Rain or showers. Moderate or 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
___
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: Regarding compiling BIND 9.10.3-p4 on a SystemD Distro

2016-03-23 Thread Tony Finch

Reindl Harald  wrote:
>
> > The problem that I alluded to above is that if you have services that
> > depend on the DNS, there should be a mechanism for the DNS server to say
> > when it is ready and that it's OK to start services that need DNS. I don't
> > know the right way to specify that to systemd: maybe it needs a socket
> > unit file as well?
>
> or just don't use "-f" and Type=forking
>
> https://www.freedesktop.org/software/systemd/man/systemd.service.html
>
> If set to forking, it is expected that the process configured with ExecStart=
> will call fork() as part of its start-up. The parent process is expected to
> exit when start-up is complete and all communication channels are set up.

BIND does not do that - it forks too early. It's a bit tiresome.

log_daemon_msg "Starting name server" "BIND"
start-stop-daemon --start --oknodo --pidfile $PIDFILE \
--name named --user named --group named \
--startas $TOP/bin/named \
-- -t $TOP -u named -c /etc/named.conf
i=$(( $? ? 100 : 0 ))
while   [ $i -lt 100 ] &&
! rndc status >/dev/null 2>&1
do  sleep 0.1
i=$((i+1))
done
chmod g+r $RUN/session.key
rndc status >/dev/null 2>&1
log_end_msg $?

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Fair Isle, Faeroes: South or southwest 5 or 6, occasionally 7 later. Moderate
or rough, occasionally very rough. Rain or showers. Moderate or 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

Re: Regarding compiling BIND 9.10.3-p4 on a SystemD Distro

2016-03-23 Thread Tony Finch

Reindl Harald  wrote:
> Am 23.03.2016 um 11:54 schrieb Tony Finch:
> >
> > There's a sample unit file in the chroot setup instructions at
> > https://wiki.debian.org/Bind9
> >
> > (It looks a bit half-baked to me since it doesn't seem to have any way to
> > signal systemd that named has finished starting, but it's probably OK for
> > practice purposes.)
>
> there is nothing half-baked - sysvinit had no concept of knowing anything
> about a process at all and even did not recoginze if it crashed 2 seconds
> after start
>
> a Type=simple unit (which is the default) has no need to signal anything,
> there is only one process without forking, hence "-f Run the server in the
> foreground (i.e. do not daemonize)"

Yes, I understand all that.

For instance (wrt -f), my rc scripts use `rndc stop -p` so they can wait
for named to completely stop; this is necessary so that it can restart
reliably. (If you restart named too fast it can fail to bind to its TCP
listening socket because the previous named still owns it.) As I
understand it, systemd has enough process monitoring intelligence to do
that by default.

The problem that I alluded to above is that if you have services that
depend on the DNS, there should be a mechanism for the DNS server to say
when it is ready and that it's OK to start services that need DNS. I don't
know the right way to specify that to systemd: maybe it needs a socket
unit file as well?

> the only half-baken is that (as sadly most services) it don't make use of
> restart and security capabilities of systemd

These are useful tips, thanks.

> Restart=always
> RestartSec=1
> CapabilityBoundingSet=CAP_CHOWN CAP_SETGID CAP_SETUID CAP_SYS_ADMIN 
> CAP_DAC_OVERRIDE CAP_KILL CAP_NET_ADMIN CAP_NET_BIND_SERVICE 
> CAP_NET_BROADCAST CAP_NET_RAW CAP_IPC_LOCK CAP_SYS_CHROOT
> ReadOnlyDirectories=/etc
> ReadOnlyDirectories=/usr

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Dogger: West or northwest backing southwest later, 3 or 4, occasionally 5
later. Slight. Occasional rain or drizzle. 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

Re: Regarding compiling BIND 9.10.3-p4 on a SystemD Distro

2016-03-23 Thread Tony Finch

Sean Son  wrote:
>
> I recently compiled and installed BIND 9.10.3-p4 from source on a system
> running CentOS 7. This is for practice purposes. Ive been searching all of
> the net and I cannot find the answer to this one question of mine: How do I
> create the systemd service unit configuration file for the named.service?

There's a sample unit file in the chroot setup instructions at
https://wiki.debian.org/Bind9

(It looks a bit half-baked to me since it doesn't seem to have any way to
signal systemd that named has finished starting, but it's probably OK for
practice purposes.)

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Cromarty, Forth, Tyne: Variable 3 or less, becoming southwest 4 or 5. Slight,
occasionally moderate later. Occasional rain or drizzle. 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

Re: Regarding compiling BIND 9.10.3-p4 on a SystemD Distro

Re: Reminder of the L-Root IPv6 address renumbering

retry limit exceeded / possible network problem?

Re: Regarding compiling BIND 9.10.3-p4 on a SystemD Distro

Re: Regarding compiling BIND 9.10.3-p4 on a SystemD Distro

RE: Regarding compiling BIND 9.10.3-p4 on a SystemD Distro

RE: Regarding compiling BIND 9.10.3-p4 on a SystemD Distro

Re: Regarding compiling BIND 9.10.3-p4 on a SystemD Distro

RE: Regarding compiling BIND 9.10.3-p4 on a SystemD Distro

Re: Regarding compiling BIND 9.10.3-p4 on a SystemD Distro

Re: Regarding compiling BIND 9.10.3-p4 on a SystemD Distro

Re: Regarding compiling BIND 9.10.3-p4 on a SystemD Distro

12 matches

Site Navigation

Mail list logo

Footer information