Re: Bind9 stops responding for some clients

2019-05-30 Thread Warren Kumari 
On Thu, May 30, 2019 at 8:10 PM Gregory Sloop  wrote:
>
> So, this is a very odd situation and I'm kind of grasping at straws here.
> So, I've come to see if any of you have any good straws!
>
> The setup.
> ---
> Ubuntu 18.04 LTS is the distro we're running on.
> All software is packaged [from the distro] - not compiled from sources.
> Bind9 acting as a recursive resolver for a smallish network. 150 seats.
> They're also handling DHCP and Chrony/NTP requests.
> [I actually have a pair of these handling DNS/DHCP/NTP this is the master.]
>
> They are running on a Xen/XCP VM.
>
> The one I'm having problems is the master for several internal zones - the 
> one that's working fine is the slave for those same zones. None of the zones 
> are large.
>
> Intermittently, Bind9 simply stops handling queries from *some* hosts.
> Meaning, it simply times out for responses for those hosts.
> Yet BIND *is* working fine for lots of other machines on the same networks. 
> It's working fine doing dig queries locally on the server, and handles dns 
> queries fine for lots of other machines. Yet, again, some machines simply get 
> time-outs. I can't find any pattern to which machines get timeouts and which 
> don't.

This is probably a really long shot, but is it possible that the
machines which don't work are trying to use TCP to query the server
(e.g because of weird MTU issues, or similar)?
I recently ran into sporadic issues where BIND would simply stop
listening on TCP -- there would be nothing in the logs, but netstat
would confirm the there was suddenly nothing listening on TCP 53.

I created a prometheus rule to monitor for this:
  - name: DNS TCP
rules:
  - alert: DNS Port 53 down on ron.
expr: probe_success{instance="{{server}}",job="dns_tcp_port"}
== 0 or up{job="dns_tcp_port"} ==0
for: 5m
labels:
  severity: page
annotations:
  identifier: '{{ $labels.instance }}'
  summary: "DNS Port 53 down on Ron {{ $labels.instance }}"
  description: "{{ $labels.instance }} probe_success returned
{{ $value }}"

and it fired twice -- and then I upgraded to BIND 9.12.4-P1 and the
problem hasn't happened since...
The obvious questions:
1: what was I running on this machine before? I think 9.12.
-- will have to check git for more detail
2: why didn't I file a bug report / take a dump / something? I kept
meaning to, but it always broke at inopportune times, so I'd just
restart and plan to do a better job next time...

W

>
> I've checked - no firewalls, fail2ban or the like that might be causing this.
> No selinux/apparmour.
> Hosts that can't do dns queries can ping the dns server fine.
> [So, there's at least some network pathway to the DNS machine.]
>
> Review of the logs for bind don't show anything that looks like a problem to 
> me.
> [But I'm not sure what keywords I ought to be looking for, in an effort to 
> find symptoms/problems.]
>
> Finally, the two bind/dhcp/ntp servers are currently running on the same Xen 
> host, so if it's somehow host related, I'd expect both to have problems, but 
> they don't.
>
> Top doesn't show any CPU distress.
> Processes look fine
> Memory in use is far below what allocated to the machine. [1G allocated, like 
> <400M used.]
> Restart of BIND doesn't do anything, at least in the cases I've seen - which 
> aren't all that many yet.
> A restart of the whole VM does appear to fix the issue immediately.
> These appear to occur every 3-5 days.
> Oh, and if you simply wait, it eventually starts handling queries for all 
> hosts again - but it might be a couple+ hours.
>
> Any suggestions on things I might hunt for in the logs in an attempt to 
> figure out what's happening?
> Other suggestions for things to look for/consider?
>
> TIA
> -Greg
> ___
> 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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
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 stops responding for some clients

2019-05-30 Thread Gregory Sloop 
Ugh. Not wanting to packet capture. :)
[Yeah, not that hard, but it always seems to suck up so much time - it's like 
the black hole for time, I think.]
But, yeah, absent some other smoking gun, that's probably where we're headed. 

As for rate limiting - "rndc recursing" didn't show anything being rate 
limited. [No output. I assume that means there's nothing there. And ISC claims 
that rate limiting isn't turned on by default - I certainly haven't enabled 
anything related to rate limits.]

There's no firewalling/filtering between any of the affected clients and the 
DNS servers.
Without going into too much detail, the network's pretty flat. 
There are (4) /24 subnets, but they're all passing through a L3 switch for 
"routing." 
Essentially all filtering occurs at the border only, so, SPI or other stuff 
shouldn't be in the mix here.

Sigh. 
As my colleague said...
"Heh. How, um, fun?"

-Greg



Whilst you mentioned 150 seats and you mentioned 'no firewalls', you didn't 
mention the network topology at all, in particular is traffic passing through a 
commercial firewall/router (hardware or virtualized) to get to the DNS server? 
If there is, it may be worth checking what packet inspection is turned on for 
DNS traffic (Cisco, Juniper and Checkpoint have been known to have buggy 
inspection routines in the past).
 
I might also be worthwhile to see what your open filehandles are like and 
whether there's any rate limiting configured in the distributed BIND 
configuration.
 
Stuart
 
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of John W. 
Blue
Sent: Friday, 31 May 2019 11:47 AM
To: bind-users@lists.isc.org
Subject: Re: Bind9 stops responding for some clients
 
Good job on the amount of troubleshooting work done so far.

Next steps should be to run tcpdump on the interface for port 53 to see what is 
happening when an outage is in progress.  What you will be looking for 
specifically is the query packet in and the response packet out.

Use the following command:

tcpdump -n -i eth0 port domain and host 172.24.67.32

Swap out eth0 for whatever you have configured and the host IP address for a 
host that is having problems.

John
 
Sent from Nine

From: Gregory Sloop 
Sent: Thursday, May 30, 2019 7:11 PM
To: bind-users@lists.isc.org
Subject: Bind9 stops responding for some clients
 
So, this is a very odd situation and I'm kind of grasping at straws here.
So, I've come to see if any of you have any good straws!

The setup.
---
Ubuntu 18.04 LTS is the distro we're running on. 
All software is packaged [from the distro] - not compiled from sources.
Bind9 acting as a recursive resolver for a smallish network. 150 seats.
They're also handling DHCP and Chrony/NTP requests.
[I actually have a pair of these handling DNS/DHCP/NTP this is the master.]

They are running on a Xen/XCP VM.

The one I'm having problems is the master for several internal zones - the one 
that's working fine is the slave for those same zones. None of the zones are 
large.

Intermittently, Bind9 simply stops handling queries from *some* hosts. 
Meaning, it simply times out for responses for those hosts.
Yet BIND *is* working fine for lots of other machines on the same networks. 
It's working fine doing dig queries locally on the server, and handles dns 
queries fine for lots of other machines. Yet, again, some machines simply get 
time-outs. I can't find any pattern to which machines get timeouts and which 
don't.

I've checked - no firewalls, fail2ban or the like that might be causing this. 
No selinux/apparmour.
Hosts that can't do dns queries can ping the dns server fine. 
[So, there's at least some network pathway to the DNS machine.]

Review of the logs for bind don't show anything that looks like a problem to me.
[But I'm not sure what keywords I ought to be looking for, in an effort to find 
symptoms/problems.]

Finally, the two bind/dhcp/ntp servers are currently running on the same Xen 
host, so if it's somehow host related, I'd expect both to have problems, but 
they don't.

Top doesn't show any CPU distress.
Processes look fine
Memory in use is far below what allocated to the machine. [1G allocated, like 
<400M used.]
Restart of BIND doesn't do anything, at least in the cases I've seen - which 
aren't all that many yet.
A restart of the whole VM does appear to fix the issue immediately.
These appear to occur every 3-5 days.
Oh, and if you simply wait, it eventually starts handling queries for all hosts 
again - but it might be a couple+ hours.

Any suggestions on things I might hunt for in the logs in an attempt to figure 
out what's happening?
Other suggestions for things to look for/consider?

TIA
-Greg

-- 
Gregory Sloop, Principal: Sloop Network & Computer Consulting
Voice: 503.251.0452 x82
EMail: gr...@sloop.net
http://www.sloop.net
---___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list

RE: Bind9 stops responding for some clients

2019-05-30 Thread Browne, Stuart via bind-users 
Whilst you mentioned 150 seats and you mentioned 'no firewalls', you didn't 
mention the network topology at all, in particular is traffic passing through a 
commercial firewall/router (hardware or virtualized) to get to the DNS server? 
If there is, it may be worth checking what packet inspection is turned on for 
DNS traffic (Cisco, Juniper and Checkpoint have been known to have buggy 
inspection routines in the past).

I might also be worthwhile to see what your open filehandles are like and 
whether there's any rate limiting configured in the distributed BIND 
configuration.

Stuart

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of John W. 
Blue
Sent: Friday, 31 May 2019 11:47 AM
To: bind-users@lists.isc.org
Subject: Re: Bind9 stops responding for some clients

Good job on the amount of troubleshooting work done so far.

Next steps should be to run tcpdump on the interface for port 53 to see what is 
happening when an outage is in progress.  What you will be looking for 
specifically is the query packet in and the response packet out.

Use the following command:

tcpdump -n -i eth0 port domain and host 172.24.67.32

Swap out eth0 for whatever you have configured and the host IP address for a 
host that is having problems.

John

Sent from 
Nine

From: Gregory Sloop mailto:gr...@sloop.net>>
Sent: Thursday, May 30, 2019 7:11 PM
To: bind-users@lists.isc.org
Subject: Bind9 stops responding for some clients

So, this is a very odd situation and I'm kind of grasping at straws here.
So, I've come to see if any of you have any good straws!

The setup.
---
Ubuntu 18.04 LTS is the distro we're running on.
All software is packaged [from the distro] - not compiled from sources.
Bind9 acting as a recursive resolver for a smallish network. 150 seats.
They're also handling DHCP and Chrony/NTP requests.
[I actually have a pair of these handling DNS/DHCP/NTP this is the master.]

They are running on a Xen/XCP VM.

The one I'm having problems is the master for several internal zones - the one 
that's working fine is the slave for those same zones. None of the zones are 
large.

Intermittently, Bind9 simply stops handling queries from *some* hosts.
Meaning, it simply times out for responses for those hosts.
Yet BIND *is* working fine for lots of other machines on the same networks. 
It's working fine doing dig queries locally on the server, and handles dns 
queries fine for lots of other machines. Yet, again, some machines simply get 
time-outs. I can't find any pattern to which machines get timeouts and which 
don't.

I've checked - no firewalls, fail2ban or the like that might be causing this.
No selinux/apparmour.
Hosts that can't do dns queries can ping the dns server fine.
[So, there's at least some network pathway to the DNS machine.]

Review of the logs for bind don't show anything that looks like a problem to me.
[But I'm not sure what keywords I ought to be looking for, in an effort to find 
symptoms/problems.]

Finally, the two bind/dhcp/ntp servers are currently running on the same Xen 
host, so if it's somehow host related, I'd expect both to have problems, but 
they don't.

Top doesn't show any CPU distress.
Processes look fine
Memory in use is far below what allocated to the machine. [1G allocated, like 
<400M used.]
Restart of BIND doesn't do anything, at least in the cases I've seen - which 
aren't all that many yet.
A restart of the whole VM does appear to fix the issue immediately.
These appear to occur every 3-5 days.
Oh, and if you simply wait, it eventually starts handling queries for all hosts 
again - but it might be a couple+ hours.

Any suggestions on things I might hunt for in the logs in an attempt to figure 
out what's happening?
Other suggestions for things to look for/consider?

TIA
-Greg
___
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 stops responding for some clients

2019-05-30 Thread John W. Blue 
Good job on the amount of troubleshooting work done so far.

Next steps should be to run tcpdump on the interface for port 53 to see what is 
happening when an outage is in progress.  What you will be looking for 
specifically is the query packet in and the response packet out.

Use the following command:

tcpdump -n -i eth0 port domain and host 172.24.67.32

Swap out eth0 for whatever you have configured and the host IP address for a 
host that is having problems.

John

Sent from Nine

From: Gregory Sloop 
Sent: Thursday, May 30, 2019 7:11 PM
To: bind-users@lists.isc.org
Subject: Bind9 stops responding for some clients

So, this is a very odd situation and I'm kind of grasping at straws here.
So, I've come to see if any of you have any good straws!

The setup.
---
Ubuntu 18.04 LTS is the distro we're running on.
All software is packaged [from the distro] - not compiled from sources.
Bind9 acting as a recursive resolver for a smallish network. 150 seats.
They're also handling DHCP and Chrony/NTP requests.
[I actually have a pair of these handling DNS/DHCP/NTP this is the master.]

They are running on a Xen/XCP VM.

The one I'm having problems is the master for several internal zones - the one 
that's working fine is the slave for those same zones. None of the zones are 
large.

Intermittently, Bind9 simply stops handling queries from *some* hosts.
Meaning, it simply times out for responses for those hosts.
Yet BIND *is* working fine for lots of other machines on the same networks. 
It's working fine doing dig queries locally on the server, and handles dns 
queries fine for lots of other machines. Yet, again, some machines simply get 
time-outs. I can't find any pattern to which machines get timeouts and which 
don't.

I've checked - no firewalls, fail2ban or the like that might be causing this.
No selinux/apparmour.
Hosts that can't do dns queries can ping the dns server fine.
[So, there's at least some network pathway to the DNS machine.]

Review of the logs for bind don't show anything that looks like a problem to me.
[But I'm not sure what keywords I ought to be looking for, in an effort to find 
symptoms/problems.]

Finally, the two bind/dhcp/ntp servers are currently running on the same Xen 
host, so if it's somehow host related, I'd expect both to have problems, but 
they don't.

Top doesn't show any CPU distress.
Processes look fine
Memory in use is far below what allocated to the machine. [1G allocated, like 
<400M used.]
Restart of BIND doesn't do anything, at least in the cases I've seen - which 
aren't all that many yet.
A restart of the whole VM does appear to fix the issue immediately.
These appear to occur every 3-5 days.
Oh, and if you simply wait, it eventually starts handling queries for all hosts 
again - but it might be a couple+ hours.

Any suggestions on things I might hunt for in the logs in an attempt to figure 
out what's happening?
Other suggestions for things to look for/consider?

TIA
-Greg
___
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

Bind9 stops responding for some clients

2019-05-30 Thread Gregory Sloop 
So, this is a very odd situation and I'm kind of grasping at straws here.
So, I've come to see if any of you have any good straws!

The setup.
---
Ubuntu 18.04 LTS is the distro we're running on. 
All software is packaged [from the distro] - not compiled from sources.
Bind9 acting as a recursive resolver for a smallish network. 150 seats.
They're also handling DHCP and Chrony/NTP requests.
[I actually have a pair of these handling DNS/DHCP/NTP this is the master.]

They are running on a Xen/XCP VM.

The one I'm having problems is the master for several internal zones - the one 
that's working fine is the slave for those same zones. None of the zones are 
large.

Intermittently, Bind9 simply stops handling queries from *some* hosts. 
Meaning, it simply times out for responses for those hosts.
Yet BIND *is* working fine for lots of other machines on the same networks. 
It's working fine doing dig queries locally on the server, and handles dns 
queries fine for lots of other machines. Yet, again, some machines simply get 
time-outs. I can't find any pattern to which machines get timeouts and which 
don't.

I've checked - no firewalls, fail2ban or the like that might be causing this. 
No selinux/apparmour.
Hosts that can't do dns queries can ping the dns server fine. 
[So, there's at least some network pathway to the DNS machine.]

Review of the logs for bind don't show anything that looks like a problem to me.
[But I'm not sure what keywords I ought to be looking for, in an effort to find 
symptoms/problems.]

Finally, the two bind/dhcp/ntp servers are currently running on the same Xen 
host, so if it's somehow host related, I'd expect both to have problems, but 
they don't.

Top doesn't show any CPU distress.
Processes look fine
Memory in use is far below what allocated to the machine. [1G allocated, like 
<400M used.]
Restart of BIND doesn't do anything, at least in the cases I've seen - which 
aren't all that many yet.
A restart of the whole VM does appear to fix the issue immediately.
These appear to occur every 3-5 days.
Oh, and if you simply wait, it eventually starts handling queries for all hosts 
again - but it might be a couple+ hours.

Any suggestions on things I might hunt for in the logs in an attempt to figure 
out what's happening?
Other suggestions for things to look for/consider?

TIA
-Greg___
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 this python stuff in 9.11.7 ??

2019-05-30 Thread Browne, Stuart via bind-users 
Maybe to state a little clearer; the dnssec-keymgr is for the automation of 
creation and date management of keys.

All of the actual signing does not require the new python bit. If you're happy 
managing your keys with dnssec-keygen and dnssec-settime, you can continue 
using those (non-python) tools.

If you want to have a completely hands-off experience with automated key 
generation and rollover (without having to write your own wrappers), you might 
want to look into the new keymgr.

Stuart

> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
> Anand Buddhdev
> Sent: Friday, 31 May 2019 8:45 AM
> To: Dennis Clarke; bind-users@lists.isc.org
> Subject: Re: what is this python stuff in 9.11.7 ??
> 
> On 31/05/2019 00:21, Dennis Clarke wrote:
> 
> > Someone somewhere figured it made sense to drag in a dependency the
> size
> > of python?
> 
> The dnssec-keymgr and a couple of other utilities were introduced in
> 9.11.0. This is mentioned in the release notes. They are not new to
> 9.11.7.
> 
> > It must be a "soft" dependency as named itself seems to need :
> 
> Correct. The BIND daemon doesn't need python. It's only needed by some
> of the DNSSEC key management utilities. If you are not going to sign
> zones with BIND, you can safely build without python.
> 
> > But a massive brontosaurus lumbering in the size of Python?
> >
> > Did anyone discuss this in the open or was it a management decision to
> > be followed next by mono and C# and perhaps libbloatware.so.1 ??
> 
> There's no need to be so dramatic about this. Python isn't that big, and
> as I said above, you can safely build and run BIND without it if you
> don't want to sign zones 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: what is this python stuff in 9.11.7 ??

2019-05-30 Thread Anand Buddhdev 
On 31/05/2019 00:21, Dennis Clarke wrote:

> Someone somewhere figured it made sense to drag in a dependency the size
> of python?

The dnssec-keymgr and a couple of other utilities were introduced in
9.11.0. This is mentioned in the release notes. They are not new to 9.11.7.

> It must be a "soft" dependency as named itself seems to need :

Correct. The BIND daemon doesn't need python. It's only needed by some
of the DNSSEC key management utilities. If you are not going to sign
zones with BIND, you can safely build without python.

> But a massive brontosaurus lumbering in the size of Python?
> 
> Did anyone discuss this in the open or was it a management decision to
> be followed next by mono and C# and perhaps libbloatware.so.1 ??

There's no need to be so dramatic about this. Python isn't that big, and
as I said above, you can safely build and run BIND without it if you
don't want to sign zones 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: what is this python stuff in 9.11.7 ??

2019-05-30 Thread Dennis Clarke 

On 5/30/19 6:05 PM, Anand Buddhdev wrote:

On 30/05/2019 23:45, Dennis Clarke wrote:

Hi Dennis,

Some of the utilities in newer version of BIND, such as dnssec-keymgr,
are written in python. This utility is very useful if you're going to
sign zones using BIND.

If you don't want or need this and a couple of other utilities for
DNSSEC key management, you can rebuild BIND by passing the
--without-python flag to configure.



Someone somewhere figured it made sense to drag in a dependency the size
of python?

It must be a "soft" dependency as named itself seems to need :

beta$ ldd /usr/local/sbin/named | grep 'local'
libcrypto.so.1.1 =>  /usr/local/lib/libcrypto.so.1.1
libxml2.so.2 =>  /usr/local/lib/libxml2.so.2
libz.so.1 => /usr/local/lib/libz.so.1
libiconv.so.2 => /usr/local/lib/libiconv.so.2
liblzma.so.5 =>  /usr/local/lib/sparcv9/liblzma.so.5
beta$

Plus the usual system bits :

libgss.so.1 =>   /usr/lib/64/libgss.so.1
libkrb5.so.1 =>  /usr/lib/64/libkrb5.so.1
libnsl.so.1 =>   /lib/64/libnsl.so.1
libsocket.so.1 =>/lib/64/libsocket.so.1
libscf.so.1 =>   /lib/64/libscf.so.1
librt.so.1 =>/lib/64/librt.so.1
libpthread.so.1 =>   /lib/64/libpthread.so.1
libm.so.2 => /lib/64/libm.so.2
libc.so.1 => /lib/64/libc.so.1
libcmd.so.1 =>   /lib/64/libcmd.so.1
libdl.so.1 =>/lib/64/libdl.so.1
libmp.so.2 =>/lib/64/libmp.so.2
libmd.so.1 =>/lib/64/libmd.so.1
libdoor.so.1 =>  /lib/64/libdoor.so.1
libuutil.so.1 => /lib/64/libuutil.so.1
libgen.so.1 =>   /lib/64/libgen.so.1
libaio.so.1 =>   /lib/64/libaio.so.1
mech_krb5.so.1 =>/usr/lib/64/gss/mech_krb5.so.1
libresolv.so.2 =>/lib/64/libresolv.so.2
libpkcs11.so.1 =>/usr/lib/64/libpkcs11.so.1
libcryptoutil.so.1 =>/usr/lib/64/libcryptoutil.so.1

But a massive brontosaurus lumbering in the size of Python?

Did anyone discuss this in the open or was it a management decision to
be followed next by mono and C# and perhaps libbloatware.so.1 ??

--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
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 this python stuff in 9.11.7 ??

2019-05-30 Thread Anand Buddhdev 
On 30/05/2019 23:45, Dennis Clarke wrote:

Hi Dennis,

Some of the utilities in newer version of BIND, such as dnssec-keymgr,
are written in python. This utility is very useful if you're going to
sign zones using BIND.

If you don't want or need this and a couple of other utilities for
DNSSEC key management, you can rebuild BIND by passing the
--without-python flag to configure.

Regards,
Anand

> I didn't think 9.11.7 had any need for python however after a fresh
> build I see this :
> 
> ./lib/python3.7
> ./lib/python3.7/site-packages
> ./lib/python3.7/site-packages/isc-2.0-py3.7.egg-info
> ./lib/python3.7/site-packages/isc
> ./lib/python3.7/site-packages/isc/parsetab.py
> ./lib/python3.7/site-packages/isc/__pycache__
> ./lib/python3.7/site-packages/isc/__pycache__/checkds.cpython-37.pyc
> ./lib/python3.7/site-packages/isc/__pycache__/utils.cpython-37.pyc
> ./lib/python3.7/site-packages/isc/__pycache__/parsetab.cpython-37.pyc
> ./lib/python3.7/site-packages/isc/__pycache__/keyevent.cpython-37.pyc
> ./lib/python3.7/site-packages/isc/__pycache__/rndc.cpython-37.pyc
> ./lib/python3.7/site-packages/isc/__pycache__/policy.cpython-37.pyc
> ./lib/python3.7/site-packages/isc/__pycache__/dnskey.cpython-37.pyc
> ./lib/python3.7/site-packages/isc/__pycache__/eventlist.cpython-37.pyc
> ./lib/python3.7/site-packages/isc/__pycache__/keydict.cpython-37.pyc
> ./lib/python3.7/site-packages/isc/__pycache__/coverage.cpython-37.pyc
> ./lib/python3.7/site-packages/isc/__pycache__/keyzone.cpython-37.pyc
> ./lib/python3.7/site-packages/isc/__pycache__/keyseries.cpython-37.pyc
> ./lib/python3.7/site-packages/isc/__pycache__/__init__.cpython-37.pyc
> ./lib/python3.7/site-packages/isc/__pycache__/keymgr.cpython-37.pyc
> 
> Is any of this stuff needed? Is this somehow operational stuff for a
> production named daemon ?   Is this documented anywhere?
> 
> 
___
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

what is this python stuff in 9.11.7 ??

2019-05-30 Thread Dennis Clarke 




I didn't think 9.11.7 had any need for python however after a fresh 
build I see this :


./lib/python3.7
./lib/python3.7/site-packages
./lib/python3.7/site-packages/isc-2.0-py3.7.egg-info
./lib/python3.7/site-packages/isc
./lib/python3.7/site-packages/isc/parsetab.py
./lib/python3.7/site-packages/isc/__pycache__
./lib/python3.7/site-packages/isc/__pycache__/checkds.cpython-37.pyc
./lib/python3.7/site-packages/isc/__pycache__/utils.cpython-37.pyc
./lib/python3.7/site-packages/isc/__pycache__/parsetab.cpython-37.pyc
./lib/python3.7/site-packages/isc/__pycache__/keyevent.cpython-37.pyc
./lib/python3.7/site-packages/isc/__pycache__/rndc.cpython-37.pyc
./lib/python3.7/site-packages/isc/__pycache__/policy.cpython-37.pyc
./lib/python3.7/site-packages/isc/__pycache__/dnskey.cpython-37.pyc
./lib/python3.7/site-packages/isc/__pycache__/eventlist.cpython-37.pyc
./lib/python3.7/site-packages/isc/__pycache__/keydict.cpython-37.pyc
./lib/python3.7/site-packages/isc/__pycache__/coverage.cpython-37.pyc
./lib/python3.7/site-packages/isc/__pycache__/keyzone.cpython-37.pyc
./lib/python3.7/site-packages/isc/__pycache__/keyseries.cpython-37.pyc
./lib/python3.7/site-packages/isc/__pycache__/__init__.cpython-37.pyc
./lib/python3.7/site-packages/isc/__pycache__/keymgr.cpython-37.pyc

Is any of this stuff needed? Is this somehow operational stuff for a
production named daemon ?   Is this documented anywhere?


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
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