Re: Dnstap Re: Deprecation notice for BIND 9.20+: Unix Domain Sockets for control channel (rndc)

[Ondřej Surý]

Hi Fred,

the Dnstap UDS support is only tangential to this - the support for AF_UNIX is 
implemented in the fstrm library
and is outside of the scope for this change.

Ondřej
--
Ondřej Surý (He/Him)
ond...@isc.org

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.

> On 12. 9. 2023, at 18:18, Fred Morris  wrote:
> 
> No objections, however I hope somebody lets me know if the same thing is 
> contemplated for Dnstap and what the timeline is. I won't be unduly lathered 
> by such an occurrence but I'd rather not have fire drills (and it's not just 
> me it's people / projects downstream of me).
> 
> FTR, I've always used an IP address with RNDC.
> 
> On Tue, 12 Sep 2023, Ondřej Surý wrote:
>> 
>> [...] The support for Unix
>> Domain Sockets is already non-operational since BIND 9.18.0 and it is a fatal
>> error in named. This is properly documented in BIND 9.18.0 release notes and
>> known issues.
>> 
>> We are now proceeding to complete remove the rest of the code and 
>> documentation
>> from BIND 9.20+ (future release).
>> 
>> [...]
>> 
>> 1. Using 'unix' option in 'controls {}' block in named.conf is already a 
>> fatal error in named
>> 
>> The original issue is tracked under: 
>> https://gitlab.isc.org/isc-projects/bind9/-/issues/1759
> 
> This wasn't particularly reassuring considering the Dnstap case. It discusses 
> something called "netmgr" which is used for "incoming DNS queries and 
> responses" and that now is apparently being adapted to a control channel; it 
> talks about modifying it to support outbound TCP connections.
> 
> Dnstap has never been a server, it establishes an outbound connection to a 
> listener (server) on a unix socket. Seems like TCP has always been an option 
> for rndc, while it's never been an option for Dnstap; so that's a difference, 
> there's no explicit migration path at this moment.
> 
> Personally I'd be happy to see the last of framestreams (we don't need the 
> handshake, I've never used it and I've only ever seen it create confusion for 
> people trying to roll their own servers). I'd love to see UDP so that we 
> could get multicast (without a T/MG), but that doesn't allow for the Dnstap 
> overhead since DNS message sizes are already capped at the maximum possible 
> size of a UDP message.
> 
> Doing nothing is an option. ;-)
> 
> 
> Thanks for all the work you do...
> 
> --
> 
> Fred Morris
> -- 
> 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

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

Dnstap Re: Deprecation notice for BIND 9.20+: Unix Domain Sockets for control channel (rndc)

[Fred Morris]

No objections, however I hope somebody lets me know if the same thing is 
contemplated for Dnstap and what the timeline is. I won't be unduly 
lathered by such an occurrence but I'd rather not have fire drills (and 
it's not just me it's people / projects downstream of me).


FTR, I've always used an IP address with RNDC.

On Tue, 12 Sep 2023, Ondřej Surý wrote:


[...] The support for Unix
Domain Sockets is already non-operational since BIND 9.18.0 and it is a fatal
error in named. This is properly documented in BIND 9.18.0 release notes and
known issues.

We are now proceeding to complete remove the rest of the code and documentation
from BIND 9.20+ (future release).

[...]

1. Using 'unix' option in 'controls {}' block in named.conf is already a fatal 
error in named

The original issue is tracked under: 
https://gitlab.isc.org/isc-projects/bind9/-/issues/1759


This wasn't particularly reassuring considering the Dnstap case. It 
discusses something called "netmgr" which is used for "incoming DNS 
queries and responses" and that now is apparently being adapted to a 
control channel; it talks about modifying it to support outbound TCP 
connections.


Dnstap has never been a server, it establishes an outbound connection to a 
listener (server) on a unix socket. Seems like TCP has always been an 
option for rndc, while it's never been an option for Dnstap; so that's a 
difference, there's no explicit migration path at this moment.


Personally I'd be happy to see the last of framestreams (we don't need the 
handshake, I've never used it and I've only ever seen it create confusion 
for people trying to roll their own servers). I'd love to see UDP so that 
we could get multicast (without a T/MG), but that doesn't allow for the 
Dnstap overhead since DNS message sizes are already capped at the maximum 
possible size of a UDP message.


Doing nothing is an option. ;-)


Thanks for all the work you do...

--

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

Deprecation notice for BIND 9.20+: Unix Domain Sockets for control channel (rndc)

[Ondřej Surý]

Hello,

in line with out deprecation policy, I am notifying the mailing list about 
deprecation
of the 'unix' clause in the controls {} configuration block.  The support for 
Unix
Domain Sockets is already non-operational since BIND 9.18.0 and it is a fatal
error in named. This is properly documented in BIND 9.18.0 release notes and
known issues.

We are now proceeding to complete remove the rest of the code and documentation
from BIND 9.20+ (future release).

The 'unix' description from the ARM:

>A :any:`unix` control channel is a Unix domain socket listening at the
>specified path in the file system. Access to the socket is specified by
>the ``perm``, ``owner``, and ``group`` clauses. Note that on some platforms
>(SunOS and Solaris), the permissions (``perm``) are applied to the parent
>directory as the permissions on the socket itself are ignored.

In BIND 9.20:

1. Using 'unix' option in 'controls {}' block in named.conf will be a fatal 
error in named and named-checkconf

In BIND 9.18 :

1. Using 'unix' option in 'controls {}' block in named.conf is already a fatal 
error in named

The original issue is tracked under: 
https://gitlab.isc.org/isc-projects/bind9/-/issues/1759

This is tracked under https://gitlab.isc.org/isc-projects/bind9/-/issues/4311

Cheers,
--
Ondřej Surý (He/Him)
ond...@isc.org

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.

-- 
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: after DS RECORD publish/verify, DSStatus stuck @ "rumoured" after manual `rndc dnssec -checkds` update ?

[Matthijs Mekking]

On 24-10-2022 15:14, PGNet Dev wrote:

The good news it is not stuck.


What indicator flags that it IS 'stuck'?  Is it explicitly logged?


Because the keymgr logs says it is just waiting time?

2022-10-21T16:55:22.690622-04:00 ns named[36683]: 21-Oct-2022 
16:55:22.689 dnssec: debug 1: keymgr: time says no to KSK 
example.com/ECDSAP256SHA256/63917 type DS state RUMOURED to state 
OMNIPRESENT (wait 93600 seconds)



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 
are configurable within dnssec-policy.


my current config has

 parent-ds-ttl  PT1H;
 parent-propagation-delay   PT1H;
 retire-safety  PT1H;

@ parental-agents, the DS is cached; ttl appears spec'd other than my 
set ttl. e.g., @ cloudflare, it's 1 day ...


in any case, all of my domains still returned "DSState: rumoured" at < 4 
days.
since then, about 1/4 of the domains have flipped from "rumoured" -> 
"omnipresent", with no manual intervention; the rest are still unchanged.


again, i've noticed no actual operational problems -- e.g., queries 
failing, etc -- other than these delays.


seems, tho, i've still got a likely misconfig somewhere in here.


I am happy to look into it, if you are willing to share the key 
**state** file in question (off-list), and dnssec-policy configuration.


A full excerpt of the debug logs around 2022-10-21T16:55:22 can also be 
useful.


Best regards,

Matthijs
--
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: after DS RECORD publish/verify, DSStatus stuck @ "rumoured" after manual `rndc dnssec -checkds` update ?

[PGNet Dev]

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 are configurable within dnssec-policy.


my current config has

parent-ds-ttl  PT1H;
parent-propagation-delay   PT1H;
retire-safety  PT1H;

@ parental-agents, the DS is cached; ttl appears spec'd other than my set ttl. 
e.g., @ cloudflare, it's 1 day ...

in any case, all of my domains still returned "DSState: rumoured" at < 4 days.
since then, about 1/4 of the domains have flipped from "rumoured" -> 
"omnipresent", with no manual intervention; the rest are still unchanged.

again, i've noticed no actual operational problems -- e.g., queries failing, 
etc -- other than these delays.

seems, tho, i've still got a likely misconfig somewhere in here.



--
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: after DS RECORD publish/verify, DSStatus stuck @ "rumoured" after manual `rndc dnssec -checkds` update ?

[Matthijs Mekking]

Hi,

On 21-10-2022 23:05, PGNet Dev wrote:

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 RUMOURED
   2022-10-21T16:55:22.690608-04:00 ns named[36683]: 21-Oct-2022 
16:55:22.689 dnssec: debug 1: keymgr: can we transition KSK 
example.com/ECDSAP256SHA256/63917 type DS state RUMOURED to state 
OMNIPRESENT?
   2022-10-21T16:55:22.690615-04:00 ns named[36683]: 21-Oct-2022 
16:55:22.689 dnssec: debug 1: keymgr: dnssec evaluation of KSK 
example.com/ECDSAP256SHA256/63917 record DS: rule1=(~true or true) 
rule2=(~true or true) rule3=(~false or false)
   2022-10-21T16:55:22.690622-04:00 ns named[36683]: 21-Oct-2022 
16:55:22.689 dnssec: debug 1: keymgr: time says no to KSK 
example.com/ECDSAP256SHA256/63917 type DS state RUMOURED to state 
OMNIPRESENT (wait 93600 seconds)


which certainly looks like a 'no'

reason is "time says no", after "dnssec evaluation".

which time is being evaluated here?


The good news it is not stuck. 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 are configurable within dnssec-policy.


Best regards,

Matthijs
--
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: after DS RECORD publish/verify, DSStatus stuck @ "rumoured" after manual `rndc dnssec -checkds` update ?

[PGNet Dev]

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 RUMOURED
  2022-10-21T16:55:22.690608-04:00 ns named[36683]: 21-Oct-2022 16:55:22.689 
dnssec: debug 1: keymgr: can we transition KSK 
example.com/ECDSAP256SHA256/63917 type DS state RUMOURED to state OMNIPRESENT?
  2022-10-21T16:55:22.690615-04:00 ns named[36683]: 21-Oct-2022 16:55:22.689 
dnssec: debug 1: keymgr: dnssec evaluation of KSK 
example.com/ECDSAP256SHA256/63917 record DS: rule1=(~true or true) rule2=(~true 
or true) rule3=(~false or false)
  2022-10-21T16:55:22.690622-04:00 ns named[36683]: 21-Oct-2022 16:55:22.689 
dnssec: debug 1: keymgr: time says no to KSK example.com/ECDSAP256SHA256/63917 
type DS state RUMOURED to state OMNIPRESENT (wait 93600 seconds)

which certainly looks like a 'no'

reason is "time says no", after "dnssec evaluation".

which time is being evaluated here?
--
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

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

[PGNet Dev]

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
  published:  yes - since Fri Oct 21 15:22:27 2022
  zone signing:   yes - since Fri Oct 21 17:27:27 2022

  Next rollover scheduled on Thu Jan 19 14:22:27 2023
  - goal:   omnipresent
  - dnskey: rumoured
  - zone rrsig: rumoured

key: 63917 (ECDSAP256SHA256), KSK
  published:  yes - since Sat Oct 15 15:52:05 2022
  key signing:yes - since Sat Oct 15 15:52:05 2022

  No rollover scheduled
  - goal:   omnipresent
  - dnskey: omnipresent
  - ds: rumoured
  - key rrsig:  omnipresent

key: 43175 (ECDSAP256SHA256), ZSK
  published:  no
  zone signing:   no

  Key has been removed from the zone
  - goal:   hidden
  - dnskey: unretentive
  - zone rrsig: unretentive


note for the KSK, it's ds state,

  - ds: rumoured

I've verified externally that thhe zone's DS RECORD has been pushed to 
registrar->parent, it's fully propagated, and is passing all the 
external/online checks.

reading @ https://kb.isc.org/docs/dnssec-key-and-signing-policy

"Note: If you see the DSState stuck in rumoured after the migration, you 
need to run rndc dnssec -checkds published example.com to tell BIND that the DS is 
already published in the parent zone"

I exec

rndc dnssec -checkds -key 63917 published example.com IN external
KSK 63917: Marked DS as published since 21-Oct-2022 16:19:36.000

rndc reload
server reload successful

and check again,

rndc dnssec -status example.com IN external
...
key: 63917 (ECDSAP256SHA256), KSK
  published:  yes - since Sat Oct 15 15:52:05 2022
  key signing:yes - since Sat Oct 15 15:52:05 2022

  No rollover scheduled
  - goal:   omnipresent
  - dnskey: omnipresent
!!- ds: rumoured
  - key rrsig:  omnipresent
...

grep DSState  Kexample.com.+013+63917.state
!!  DSState: rumoured

ds state is still just "rumoured".

What additional steps are needed to update that DSState correctly?
--
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: Is there an rndc command to get the list of configured zones?

[Tony Finch]

Klaus Darilion via bind-users  wrote:

> I checked all options of rndc to get the list of zones configured/served by 
> bind - but I can't find any.
> Is it really not possible to get this list from a running Bind process?

The statistics channel is your friend when rndc lets you down. Below I
have pasted a wee script I have lying around, or you might like JP Mens'
bzl program https://github.com/jpmens/bzl
https://jpmens.net/2010/10/21/using-binds-statistics-server-to-list-zones-and-axfr-the-list/

#!/bin/sh

case $# in
(1) ;;
(*) echo 1>&2 'usage: lszones [:port]'
exit 1
esac

curl -Ssf http://$1/json |
jq '.views |
to_entries |
.[] |
.key as $view |
.value.zones[] |
"\($view) \(.type) \(.serial) \(.name)"
'

-- 
Tony Finch(he/they)  Cambridge, England
Fair Isle, Faeroes: South or southwest 5 to 7. Moderate, occasionally
slight, becoming moderate or rough. Occasional rain and fog patches,
showers later in Faeroes. Moderate or good, occasionally very poor.
-- 
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

Is there an rndc command to get the list of configured zones?

[Klaus Darilion via bind-users]

I checked all options of rndc to get the list of zones configured/served by 
bind - but I can't find any.
Is it really not possible to get this list from a running Bind process?

Thanks
Klaus

--
Klaus Darilion, Head of Operations
nic.at GmbH, Jakob-Haringer-Straße 8/V
5020 Salzburg, Austria
-- 
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: Missing n in man page for rndc(8)?

[Mark Andrews]

It’s already been addressed

-- 
Mark Andrews

> On 4 May 2022, at 06:16, Larry Rosenman  wrote:
> 
> I did find a manpage bug for the rndc man page for 9.18.2:
> dnssec (-status | -rollover -key id [-alg algorithm] [-when time] |
>   -checkds [-key id [-alg algorithm]] [-when time] published | withdraw))
>   zone [class [view]]
> 
> s/withdraw/withdrawn/
> 
> withdraw garners a syntax error :(
> 
> Where should I report this?  Or is here sufficient?
> 
> -- 
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
> -- 
> 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
-- 
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

Missing n in man page for rndc(8)?

[Larry Rosenman]

I did find a manpage bug for the rndc man page for 9.18.2:
 dnssec (-status | -rollover -key id [-alg algorithm] [-when time] |
   -checkds [-key id [-alg algorithm]] [-when time] published | 
withdraw))

   zone [class [view]]

s/withdraw/withdrawn/

withdraw garners a syntax error :(

Where should I report this?  Or is here sufficient?

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--
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: V 9.18.1 not listen on port 853 after rndc reload

[MAYER Hans]

Dear All, 

many thanks pointing me into the right direction. 


// Hans 

— 



> On 21.03.2022, at 17:58, Ondřej Surý  wrote:
> 
> This is already being tracked as 
> https://gitlab.isc.org/isc-projects/bind9/-/issues/3122
> 
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org
> 
> My working hours and your working hours may be different. Please do not feel 
> obligated to reply outside your normal working hours.
> 
>> On 21. 3. 2022, at 17:12, MAYER Hans  wrote:
>> 
>> 
>> Hi Borja, 
>> 
>> Many thanks for this hint. I tried to allow with 
>> setcap 'CAP_NET_BIND_SERVICE=+eip'  /usr/local/sbin/named
>> but it didn’t help. 
>> 
>> On other hand there is no issue on port 53 and 953. Why should it be just on 
>> port 853 ? 
>> 
>> Kind regards 
>> Hans 
>> 
>> 
>> 
>>> On 21.03.2022, at 15:26, Borja Marcos  wrote:
>>> 
>>> 
>>> 
>>>> On 21 Mar 2022, at 14:51, MAYER Hans  wrote:
>>>> 
>>>> 
>>>> Looking at the log I see: 
>>>> network: error: creating TLS socket: permission denied
>>>> 
>>>> Why doesn’t named have the permissions after a „rndc reload“ but it has 
>>>> the permissions after a start ? And why on one server but not on another ? 
>>>> In both cases the daemon is running as user „bind“ with UID below 128 but 
>>>> not as root. 
>>> 
>>> Because it usually starts as root and it demotes itself to “bind” whenever 
>>> possible.
>>> 
>>> Maybe there is a mechanism in Linux to grant permission to a certain UID to 
>>> bind() a socket to certain privileged 
>>> port number, as it is used for NTP on FreeBSD?
>>> 
>>> 
>>> 
>>> 
>>> Borja.
>>> 
>> 
>> 
>> 
>> 
>> 
>>> On 21.03.2022, at 14:51, MAYER Hans  wrote:
>>> 
>>> 
>>> 
>>> Dear All, 
>>> 
>>> now BIND 9.18 is supporting DoT directly I tried to go away from a solution 
>>> with stunnel4 and therefore I compiled 9.18.1 and modified named.conf
>>> So far everything is working fine. All the tests with dig , openssl and 
>>> lsof is showing it’s working. 
>>> The problem: when I run a „rndc reload“ the named process is not listen on 
>>> 853/tcp anymore. All tests with TLS fail. And this on IPv4 as well on IPv6.
>>> The rest of BIND is working well. Still listening on port 53 on UDP and TCP 
>>> When I restart the service so that named stops and a new process is started 
>>> and running then DoT is working again. 
>>> I run this on Debian 10 buster. 
>>> The interesting story is I run the same version 9.18.1 on a different 
>>> Debian 10 buster server. On this server the process „named" survives a 
>>> „rndc reload“  on port 853 
>>> 
>>> Looking at the log I see: 
>>> network: error: creating TLS socket: permission denied
>>> 
>>> Why doesn’t named have the permissions after a „rndc reload“ but it has the 
>>> permissions after a start ? And why on one server but not on another ? 
>>> In both cases the daemon is running as user „bind“ with UID below 128 but 
>>> not as root. 
>>> 
>>> Any ideas where to look ? 
>>> 
>>> Kind regards 
>>> Hans 
>>> 
>>> — 
>>> 
>>> 
>>> maybe the important part of the config
>>> 
>>>   listen-on {
>>>  my.ipv4.hiding.here  ;
>>>  127.0.0.1 ;
>>>   };
>>>   listen-on port 853 tls iiasaatls { any; }; 
>>>   listen-on-v6 { any ; } ;
>>>   listen-on-v6 port 853 tls iiasaatls { any; }; 
>>> 
>>> 
>> 
>> 
>> -- 
>> 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
> 

-- 
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: V 9.18.1 not listen on port 853 after rndc reload

[Ondřej Surý]

This is already being tracked as 
https://gitlab.isc.org/isc-projects/bind9/-/issues/3122

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.

> On 21. 3. 2022, at 17:12, MAYER Hans  wrote:
> 
> 
> Hi Borja, 
> 
> Many thanks for this hint. I tried to allow with 
> setcap 'CAP_NET_BIND_SERVICE=+eip'  /usr/local/sbin/named
> but it didn’t help. 
> 
> On other hand there is no issue on port 53 and 953. Why should it be just on 
> port 853 ? 
> 
> Kind regards 
> Hans 
> 
> 
> 
>> On 21.03.2022, at 15:26, Borja Marcos  wrote:
>> 
>> 
>> 
>>> On 21 Mar 2022, at 14:51, MAYER Hans  wrote:
>>> 
>>> 
>>> Looking at the log I see: 
>>> network: error: creating TLS socket: permission denied
>>> 
>>> Why doesn’t named have the permissions after a „rndc reload“ but it has the 
>>> permissions after a start ? And why on one server but not on another ? 
>>> In both cases the daemon is running as user „bind“ with UID below 128 but 
>>> not as root. 
>> 
>> Because it usually starts as root and it demotes itself to “bind” whenever 
>> possible.
>> 
>> Maybe there is a mechanism in Linux to grant permission to a certain UID to 
>> bind() a socket to certain privileged 
>> port number, as it is used for NTP on FreeBSD?
>> 
>> 
>> 
>> 
>> Borja.
>> 
> 
> 
> 
> 
> 
>> On 21.03.2022, at 14:51, MAYER Hans  wrote:
>> 
>> 
>> 
>> Dear All, 
>> 
>> now BIND 9.18 is supporting DoT directly I tried to go away from a solution 
>> with stunnel4 and therefore I compiled 9.18.1 and modified named.conf
>> So far everything is working fine. All the tests with dig , openssl and lsof 
>> is showing it’s working. 
>> The problem: when I run a „rndc reload“ the named process is not listen on 
>> 853/tcp anymore. All tests with TLS fail. And this on IPv4 as well on IPv6.
>> The rest of BIND is working well. Still listening on port 53 on UDP and TCP 
>> When I restart the service so that named stops and a new process is started 
>> and running then DoT is working again. 
>> I run this on Debian 10 buster. 
>> The interesting story is I run the same version 9.18.1 on a different Debian 
>> 10 buster server. On this server the process „named" survives a „rndc 
>> reload“  on port 853 
>> 
>> Looking at the log I see: 
>> network: error: creating TLS socket: permission denied
>> 
>> Why doesn’t named have the permissions after a „rndc reload“ but it has the 
>> permissions after a start ? And why on one server but not on another ? 
>> In both cases the daemon is running as user „bind“ with UID below 128 but 
>> not as root. 
>> 
>> Any ideas where to look ? 
>> 
>> Kind regards 
>> Hans 
>> 
>> — 
>> 
>> 
>> maybe the important part of the config
>> 
>>listen-on {
>>   my.ipv4.hiding.here  ;
>>   127.0.0.1 ;
>>};
>>listen-on port 853 tls iiasaatls { any; }; 
>>listen-on-v6 { any ; } ;
>>listen-on-v6 port 853 tls iiasaatls { any; }; 
>> 
>> 
> 
> 
> -- 
> 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

-- 
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: V 9.18.1 not listen on port 853 after rndc reload

[MAYER Hans]

Hi Borja,

Many thanks for this hint. I tried to allow with
setcap 'CAP_NET_BIND_SERVICE=+eip'  /usr/local/sbin/named
but it didn’t help.

On other hand there is no issue on port 53 and 953. Why should it be just on 
port 853 ?

Kind regards
Hans



On 21.03.2022, at 15:26, Borja Marcos 
mailto:bor...@sarenet.es>> wrote:



On 21 Mar 2022, at 14:51, MAYER Hans 
mailto:hans.ma...@iiasa.ac.at>> wrote:


Looking at the log I see:
network: error: creating TLS socket: permission denied

Why doesn’t named have the permissions after a „rndc reload“ but it has the 
permissions after a start ? And why on one server but not on another ?
In both cases the daemon is running as user „bind“ with UID below 128 but not 
as root.

Because it usually starts as root and it demotes itself to “bind” whenever 
possible.

Maybe there is a mechanism in Linux to grant permission to a certain UID to 
bind() a socket to certain privileged
port number, as it is used for NTP on FreeBSD?




Borja.






On 21.03.2022, at 14:51, MAYER Hans 
mailto:hans.ma...@iiasa.ac.at>> wrote:



Dear All,

now BIND 9.18 is supporting DoT directly I tried to go away from a solution 
with stunnel4 and therefore I compiled 9.18.1 and modified named.conf
So far everything is working fine. All the tests with dig , openssl and lsof is 
showing it’s working.
The problem: when I run a „rndc reload“ the named process is not listen on 
853/tcp anymore. All tests with TLS fail. And this on IPv4 as well on IPv6.
The rest of BIND is working well. Still listening on port 53 on UDP and TCP
When I restart the service so that named stops and a new process is started and 
running then DoT is working again.
I run this on Debian 10 buster.
The interesting story is I run the same version 9.18.1 on a different Debian 10 
buster server. On this server the process „named" survives a „rndc reload“  on 
port 853

Looking at the log I see:
network: error: creating TLS socket: permission denied

Why doesn’t named have the permissions after a „rndc reload“ but it has the 
permissions after a start ? And why on one server but not on another ?
In both cases the daemon is running as user „bind“ with UID below 128 but not 
as root.

Any ideas where to look ?

Kind regards
Hans

—


maybe the important part of the config

   listen-on {
  my.ipv4.hiding.here  ;
  127.0.0.1 ;
   };
   listen-on port 853 tls iiasaatls { any; };
   listen-on-v6 { any ; } ;
   listen-on-v6 port 853 tls iiasaatls { any; };




-- 
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: V 9.18.1 not listen on port 853 after rndc reload

[sthaug]

> now BIND 9.18 is supporting DoT directly I tried to go away from a solution 
> with stunnel4 and therefore I compiled 9.18.1 and modified named.conf
> So far everything is working fine. All the tests with dig , openssl and lsof 
> is showing it’s working. 
> The problem: when I run a „rndc reload“ the named process is not listen on 
> 853/tcp anymore. All tests with TLS fail. And this on IPv4 as well on IPv6.
> The rest of BIND is working well. Still listening on port 53 on UDP and TCP 
> When I restart the service so that named stops and a new process is started 
> and running then DoT is working again. 
> I run this on Debian 10 buster. 
> The interesting story is I run the same version 9.18.1 on a different Debian 
> 10 buster server. On this server the process „named" survives a „rndc reload“ 
>  on port 853 
> 
> Looking at the log I see: 
> network: error: creating TLS socket: permission denied

Known bug, see

https://gitlab.isc.org/isc-projects/bind9/-/issues/3122

and the thread starting at

https://lists.isc.org/pipermail/bind-users/2022-January/105596.html

Steinar Haug, Nethelp consulting, sth...@nethelp.no
-- 
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: V 9.18.1 not listen on port 853 after rndc reload

[Borja Marcos]

> On 21 Mar 2022, at 14:51, MAYER Hans  wrote:
> 
> 
> Looking at the log I see: 
> network: error: creating TLS socket: permission denied
> 
> Why doesn’t named have the permissions after a „rndc reload“ but it has the 
> permissions after a start ? And why on one server but not on another ? 
> In both cases the daemon is running as user „bind“ with UID below 128 but not 
> as root. 

Because it usually starts as root and it demotes itself to “bind” whenever 
possible.

Maybe there is a mechanism in Linux to grant permission to a certain UID to 
bind() a socket to certain privileged 
port number, as it is used for NTP on FreeBSD?




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

V 9.18.1 not listen on port 853 after rndc reload

[MAYER Hans]

Dear All, 

now BIND 9.18 is supporting DoT directly I tried to go away from a solution 
with stunnel4 and therefore I compiled 9.18.1 and modified named.conf
So far everything is working fine. All the tests with dig , openssl and lsof is 
showing it’s working. 
The problem: when I run a „rndc reload“ the named process is not listen on 
853/tcp anymore. All tests with TLS fail. And this on IPv4 as well on IPv6.
The rest of BIND is working well. Still listening on port 53 on UDP and TCP 
When I restart the service so that named stops and a new process is started and 
running then DoT is working again. 
I run this on Debian 10 buster. 
The interesting story is I run the same version 9.18.1 on a different Debian 10 
buster server. On this server the process „named" survives a „rndc reload“  on 
port 853 

Looking at the log I see: 
network: error: creating TLS socket: permission denied

Why doesn’t named have the permissions after a „rndc reload“ but it has the 
permissions after a start ? And why on one server but not on another ? 
In both cases the daemon is running as user „bind“ with UID below 128 but not 
as root. 

Any ideas where to look ? 

Kind regards 
Hans 

— 


maybe the important part of the config

listen-on {
   my.ipv4.hiding.here  ;
   127.0.0.1 ;
};
listen-on port 853 tls iiasaatls { any; }; 
listen-on-v6 { any ; } ;
listen-on-v6 port 853 tls iiasaatls { any; }; 





-- 
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: 9.16.22 - rndc reload not sending to secondaries.

[Mark Andrews]

Read up on NOTIFY. Secondaries poll the primary for changes based on SOA 
timers. NOTIFY informs the secondaries to poll earlier. Named uses the NS 
records to find the default set on machines to send NOTIFY messages to.

> On 4 Nov 2021, at 08:08, Speagle, Andy via bind-users 
>  wrote:
> 
> Hi Team,
> 
> I'm not a bind expert... we're upgrading from 9.11 to 9.16 as we
> migrate to new servers... and for some reason we can't get zone
> transfers working from the primary to secondary.
> 
> We have this directive in our options for named.conf 
> 
> allow-transfer { secondaries; };
> 
> and of course... an acl later in the named.conf
> 
> acl secondaries { x.x.x.x; };
> 
> I watch the logs on the secondary... and make a change to a zone on the
> primary... update the serial... run an rndc reload...
> 
> Yet... I see nothing on the secondary.
> 
> Anyone have any clues or hints?
> -- 
> Andy Speagle
> 
> ___
> Please 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

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

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

9.16.22 - rndc reload not sending to secondaries.

[Speagle, Andy via bind-users]

Hi Team,

I'm not a bind expert... we're upgrading from 9.11 to 9.16 as we
migrate to new servers... and for some reason we can't get zone
transfers working from the primary to secondary.

We have this directive in our options for named.conf 

allow-transfer { secondaries; };

and of course... an acl later in the named.conf

acl secondaries { x.x.x.x; };

I watch the logs on the secondary... and make a change to a zone on the
primary... update the serial... run an rndc reload...

Yet... I see nothing on the secondary.

Anyone have any clues or hints?
-- 
Andy Speagle

___
Please 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: Using RNDC to control remote access to my BIND server

[Anand Buddhdev]

Hi Greg,

Read the "ddns-confgen" man page. And then read all the material here:

https://bind9.readthedocs.io/en/v9_16_13/advanced.html

Regards,
Anand

On 27/04/2021 11:27, Greg Donohoe wrote:

> Thank you for the excellent advise, it is a lot clearer to me now.
> I am checking the nsupdate & TSIG man pages for additional knowledge.
> Outside of these man pages , are there any other references
> (tutorials/videos) that you would recommend?
> Particularly around the area of TSIG key generation & management best
> practices?
___
Please 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: Using RNDC to control remote access to my BIND server

[Greg Donohoe]

Thank you for the excellent advise, it is a lot clearer to me now.
I am checking the nsupdate & TSIG man pages for additional knowledge.
Outside of these man pages , are there any other references
(tutorials/videos) that you would recommend?
Particularly around the area of TSIG key generation & management best
practices?

Rgds,
Greg.

On Mon, Apr 26, 2021 at 4:16 PM Tony Finch  wrote:

> Anand Buddhdev  wrote:
> >
>
> Anand's advice is good, as usual :-)
>
> But a small pedantic point:
>
> > The DNS protocol itself has recently been updated to allow for
> > encryption, using DTLS (DNS-over-TLS).
>
> DTLS usually means "datagram TLS", i.e. TLS-over-UDP (RFC 6347). There's a
> spec for DNS-over-DTLS (RFC 8094) but I have not seen much enthusiasm for
> deploying it: DTLS combines all the disadvantages of UDP with all the
> disadvantages of TLS. (Or worse: DTLS has a more complicated state machine
> than normal TLS so there have been a bunch of DTLS-specific
> vulnerabilities which makes me very reluctant to deploy it.)
>
> There is a lot more enthusiasm for DNS-over-TLS (aka DoT) and
> DNS-over-HTTPS (aka DoH), and maybe in the future DNS-over-QUIC.
>
> But right now, none of these are particularly easy to get working as
> transports for UPDATE, and as Anand said, it usually isn't necessary.
>
> I'm looking forward to zone transfers over TLS, because public key
> authentication (with client certificates) is a bit easier to deploy
> between different organizations than TSIG secret key authentication.
> There's not such a clear benefit for UPDATE-over-TLS where I'm sitting,
> apart from the neatness of having all authenticated traffic over TLS.
>
> Tony.
> --
> f.anthony.n.finchhttps://dotat.at/
> Bailey: Northeast 5 to 7. Moderate or rough. Showers at first. Good.
>
>
___
Please 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: Using RNDC to control remote access to my BIND server

[Tony Finch]

Anand Buddhdev  wrote:
>

Anand's advice is good, as usual :-)

But a small pedantic point:

> The DNS protocol itself has recently been updated to allow for
> encryption, using DTLS (DNS-over-TLS).

DTLS usually means "datagram TLS", i.e. TLS-over-UDP (RFC 6347). There's a
spec for DNS-over-DTLS (RFC 8094) but I have not seen much enthusiasm for
deploying it: DTLS combines all the disadvantages of UDP with all the
disadvantages of TLS. (Or worse: DTLS has a more complicated state machine
than normal TLS so there have been a bunch of DTLS-specific
vulnerabilities which makes me very reluctant to deploy it.)

There is a lot more enthusiasm for DNS-over-TLS (aka DoT) and
DNS-over-HTTPS (aka DoH), and maybe in the future DNS-over-QUIC.

But right now, none of these are particularly easy to get working as
transports for UPDATE, and as Anand said, it usually isn't necessary.

I'm looking forward to zone transfers over TLS, because public key
authentication (with client certificates) is a bit easier to deploy
between different organizations than TSIG secret key authentication.
There's not such a clear benefit for UPDATE-over-TLS where I'm sitting,
apart from the neatness of having all authenticated traffic over TLS.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Bailey: Northeast 5 to 7. Moderate or rough. Showers at first. Good.

___
Please 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: Using RNDC to control remote access to my BIND server

[Anand Buddhdev]

Hi Greg,

a TSIG key is *never* transmitted. A sender uses a TSIG key to generate
a secure hash over the DNS content being sent, and sends the hash along
with the DNS content. A receiver configured with the same key can then
verify that hash. If it can, then it can apply the DNS content.

If someone is sniffing the wire between the client and server, they can
see the DNS content. This usually doesn't matter, because the DNS is
usually public anyway. However, if a man-in-the-middle tries to modify
the packet in any way, then the receiver will detect the change, because
the hash will not verify, and the receiver can reject that packet as
invalid.

DNS was NOT designed to be encrypted, because as I wrote above, it's
usually public data anyway.

If you want to encrypt your dynamic DNS update anyway (even though
there's good reason to do this), then you need to send your update over
an encrypted session of some kind. The DNS protocol itself has recently
been updated to allow for encryption, using DTLS (DNS-over-TLS). But
while DNS resolvers can use this to send queries to suitably configured
servers, I don't think "nsupdate" can use DTLS just yet (someone please
correct me if I'm wrong). So your only alternative is to use another
secure protocol, such as SSH, with port forwarding, to send your dynamic
updates to the server.

BUT AGAIN, there is usually no need for this. Do NOT overcomplicate your
design for no reason.

Regards,
Anand

On 26/04/2021 16:04, Greg Donohoe wrote:
> Thanks Anand.
> When using this TSIG solution is the key visible (clear) within the DNS
> packet being sent to the remote server or is it encrypted?
> Is this communication secure? eg if someone is sitting on the wire sniffing
> the packets, would they be able to extract the key ?
> Or is the security of the communication done through the ACL and the key is
> TSIG only used to allow me to make changes to the zone file?
> The main reason why I was leaning towards SSH was to try to ensure that all
> communication between local & remote was encrypted.
> 
> Rgds,
> Greg.
> 
> On Fri, Apr 23, 2021 at 2:21 PM Anand Buddhdev  wrote:
> 
>> On 23/04/2021 14:24, Greg Donohoe wrote:
>>
>> Hi Greg,
>>
>>> In regards to the nsupdate, what is the best way to secure the
>> connection,
>>> so to ensure that only my local server can make the amendments to the
>>> remote server named & zone files?
>>> I dont want anyone/anything else other than my local machine to make any
>>> changes on my remote BIND server.
>>
>> You should create a TSIG key, and configure the zones on the remote
>> server to only accept dynamic DNS updates signed by this key. And then
>> use this key with nsupdate when sending your updates. Check the man page
>> of nsupdate and look at the '-k' and '-y' options for using tsig keys.
>>
>> You can additionally also configure your remote BIND to accept updates
>> only from certain IP addresses. For details on how to configure this,
>> please read the excellent documentation (especially section 4.2.29 and
>> the "allow-update" option):
>>
>> https://bind9.readthedocs.io/en/v9_16/
>>
>> Regards,
>> Anand Buddhdev
>>
> 
___
Please 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: Using RNDC to control remote access to my BIND server

[Greg Donohoe]

Thanks Anand.
When using this TSIG solution is the key visible (clear) within the DNS
packet being sent to the remote server or is it encrypted?
Is this communication secure? eg if someone is sitting on the wire sniffing
the packets, would they be able to extract the key ?
Or is the security of the communication done through the ACL and the key is
TSIG only used to allow me to make changes to the zone file?
The main reason why I was leaning towards SSH was to try to ensure that all
communication between local & remote was encrypted.

Rgds,
Greg.

On Fri, Apr 23, 2021 at 2:21 PM Anand Buddhdev  wrote:

> On 23/04/2021 14:24, Greg Donohoe wrote:
>
> Hi Greg,
>
> > In regards to the nsupdate, what is the best way to secure the
> connection,
> > so to ensure that only my local server can make the amendments to the
> > remote server named & zone files?
> > I dont want anyone/anything else other than my local machine to make any
> > changes on my remote BIND server.
>
> You should create a TSIG key, and configure the zones on the remote
> server to only accept dynamic DNS updates signed by this key. And then
> use this key with nsupdate when sending your updates. Check the man page
> of nsupdate and look at the '-k' and '-y' options for using tsig keys.
>
> You can additionally also configure your remote BIND to accept updates
> only from certain IP addresses. For details on how to configure this,
> please read the excellent documentation (especially section 4.2.29 and
> the "allow-update" option):
>
> https://bind9.readthedocs.io/en/v9_16/
>
> Regards,
> Anand Buddhdev
>
___
Please 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: nsupdate and zone files, was Re: Using RNDC to control remote access to my BIND server

[Tony Finch]

Paul Kosinski via bind-users  wrote:

> A couple of years ago, I tried using nsupdate to modify a dynamic (DHCP)
> IP address for my very simple domain. It worked, except that it totally
> messed up the organization of the zone file. Since the file only has 44
> active lines (which are organized logically), I maintain it by hand.
> After nsupdate made the one line change, the zone file became
> unmaintainable.
>
> Was this a bug in nsupdate, or does nobody try to understand their zone
> files.

When you have a zone that accepts dynamic updates, then its zone file is
owned by `named`, and `named` will rewrite the file to incorporate
updates, which (as you saw) also strips out comments and canonicalized the
formatting. This is often surprising and upsetting to people who are new
to dynamic updates - you are not alone!

Basically, if you are doing dynamic updates, then the source of truth for
your zone needs to be somewhere else, not the zone file used by `named`.
(For example, at my work our zones are stored in a database and edited
with a web front end.)

I have some scripts which allow you to maintain your zone file however you
want, and push any differences into `named` using `nsupdate`, so you never
need to touch the zone files that it owns. https://dotat.at/prog/nsdiff/

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Lyme Regis to Lands End including the Isles of Scilly: Easterly or
northeasterly 5 to 7, occasionally 4 in east. Moderate or rough. Fair.
Good.

___
Please 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: Using RNDC to control remote access to my BIND server

[Paul Kosinski via bind-users]

A couple of years ago, I tried using nsupdate to modify a dynamic (DHCP) IP 
address for my very simple domain. It worked, except that it totally messed up 
the organization of the zone file. Since the file only has 44 active lines 
(which are organized logically), I maintain it by hand. After nsupdate made the 
one line change, the zone file became unmaintainable.

Was this a bug in nsupdate, or does nobody try to understand their zone files.

P.S. Now I use $INCLUDE and just overwrite the included file with the new A 
record (using a simple bash script via an encrypted connection).



On Fri, 23 Apr 2021 12:21:22 +0200
Anand Buddhdev  wrote:

> Hi Greg,
> 
> You don't need to SSH into a remote server to do dynamic DNS updates!
> The "nsupdate" tool can send the dynamic DNS updates directly to your
> remote server over the DNS protocol.
> 
> You appear to be confused about what the various tools do, so here's a
> summary:
> 
> 1. ssh is used to log into a remote server, get a shell, and run
> operating system commands.
> 
> 2. rndc is for controlling a running BIND server. It can be used to
> check the status of BIND, reload it, etc.
> 
> 3. nsupdate is for modifying a zone directly (whether on the local
> machine, or some remote machine) using the dynamic DNS protocol.
> 
> Having read your message, it seems that you need to use "nsupdate". You
> don't need "ssh" or "rndc" for this.
> 
> Regards,
> Anand
> 
> On 23/04/2021 11:50, Greg Donohoe wrote:
> 
> > Thank you for the suggestions. I am looking into those now.
> > Yes we can run nsupdate again on the remote server but I would still need
> > to connect to the remote server to do this.
> > We were thinking of using SSH to the remote server but we want to explore
> > any other option rather than SSH for the secure connection.
> > I was thinking that it may be possible to use RNDC or some other tool to
> > update the remote BIND server zone files (either by modifying the zone file
> > that is already there or replacing the zone file with the new one I created
> > locally).
> > RNDC looks like it is a non starter for what I want but nsdiff may be a
> > good option.  
___
Please 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: Using RNDC to control remote access to my BIND server

[Anand Buddhdev]

On 23/04/2021 14:24, Greg Donohoe wrote:

Hi Greg,

> In regards to the nsupdate, what is the best way to secure the connection,
> so to ensure that only my local server can make the amendments to the
> remote server named & zone files?
> I dont want anyone/anything else other than my local machine to make any
> changes on my remote BIND server.

You should create a TSIG key, and configure the zones on the remote
server to only accept dynamic DNS updates signed by this key. And then
use this key with nsupdate when sending your updates. Check the man page
of nsupdate and look at the '-k' and '-y' options for using tsig keys.

You can additionally also configure your remote BIND to accept updates
only from certain IP addresses. For details on how to configure this,
please read the excellent documentation (especially section 4.2.29 and
the "allow-update" option):

https://bind9.readthedocs.io/en/v9_16/

Regards,
Anand Buddhdev
___
Please 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: Using RNDC to control remote access to my BIND server

[Greg Donohoe]

Thanks for the input Anand.
Yes there is still some confusion on my part as to which option to use to
best fir my current environment.
In regards to the nsupdate, what is the best way to secure the connection,
so to ensure that only my local server can make the amendments to the
remote server named & zone files?
I dont want anyone/anything else other than my local machine to make any
changes on my remote BIND server.

Rgds,
Greg.

On Fri, Apr 23, 2021 at 11:21 AM Anand Buddhdev  wrote:

> Hi Greg,
>
> You don't need to SSH into a remote server to do dynamic DNS updates!
> The "nsupdate" tool can send the dynamic DNS updates directly to your
> remote server over the DNS protocol.
>
> You appear to be confused about what the various tools do, so here's a
> summary:
>
> 1. ssh is used to log into a remote server, get a shell, and run
> operating system commands.
>
> 2. rndc is for controlling a running BIND server. It can be used to
> check the status of BIND, reload it, etc.
>
> 3. nsupdate is for modifying a zone directly (whether on the local
> machine, or some remote machine) using the dynamic DNS protocol.
>
> Having read your message, it seems that you need to use "nsupdate". You
> don't need "ssh" or "rndc" for this.
>
> Regards,
> Anand
>
> On 23/04/2021 11:50, Greg Donohoe wrote:
>
> > Thank you for the suggestions. I am looking into those now.
> > Yes we can run nsupdate again on the remote server but I would still need
> > to connect to the remote server to do this.
> > We were thinking of using SSH to the remote server but we want to explore
> > any other option rather than SSH for the secure connection.
> > I was thinking that it may be possible to use RNDC or some other tool to
> > update the remote BIND server zone files (either by modifying the zone
> file
> > that is already there or replacing the zone file with the new one I
> created
> > locally).
> > RNDC looks like it is a non starter for what I want but nsdiff may be a
> > good option.
>
___
Please 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: Using RNDC to control remote access to my BIND server

[Anand Buddhdev]

Hi Greg,

You don't need to SSH into a remote server to do dynamic DNS updates!
The "nsupdate" tool can send the dynamic DNS updates directly to your
remote server over the DNS protocol.

You appear to be confused about what the various tools do, so here's a
summary:

1. ssh is used to log into a remote server, get a shell, and run
operating system commands.

2. rndc is for controlling a running BIND server. It can be used to
check the status of BIND, reload it, etc.

3. nsupdate is for modifying a zone directly (whether on the local
machine, or some remote machine) using the dynamic DNS protocol.

Having read your message, it seems that you need to use "nsupdate". You
don't need "ssh" or "rndc" for this.

Regards,
Anand

On 23/04/2021 11:50, Greg Donohoe wrote:

> Thank you for the suggestions. I am looking into those now.
> Yes we can run nsupdate again on the remote server but I would still need
> to connect to the remote server to do this.
> We were thinking of using SSH to the remote server but we want to explore
> any other option rather than SSH for the secure connection.
> I was thinking that it may be possible to use RNDC or some other tool to
> update the remote BIND server zone files (either by modifying the zone file
> that is already there or replacing the zone file with the new one I created
> locally).
> RNDC looks like it is a non starter for what I want but nsdiff may be a
> good option.
___
Please 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: Using RNDC to control remote access to my BIND server

[Greg Donohoe]

Thank you for the suggestions. I am looking into those now.
Yes we can run nsupdate again on the remote server but I would still need
to connect to the remote server to do this.
We were thinking of using SSH to the remote server but we want to explore
any other option rather than SSH for the secure connection.
I was thinking that it may be possible to use RNDC or some other tool to
update the remote BIND server zone files (either by modifying the zone file
that is already there or replacing the zone file with the new one I created
locally).
RNDC looks like it is a non starter for what I want but nsdiff may be a
good option.

Rgds,
Greg.




On Thu, Apr 22, 2021 at 8:38 PM Tony Finch  wrote:

> Greg Donohoe  wrote:
>
> > I have created a CI/CD pipeline in order to amend zone files using
> nsupdate
> > based on a front end user request. This portion of the pipeline is
> working
> > as expected so now I want to be able to connect from my pipeline runner
> to
> > my remote BIND staging server and update the zone files on there with my
> > newly updated zone file.
>
> If you want to make the same change on the remote server that you made
> locally, can't you use nsupdate again but point it at the remote server?
> Or is there something more complicated going on?
>
> Use ddns-keygen to create a TSIG authentication key and add the key to the
> allow-update ACL on the remote server.
>
> (You can also add your own TSIG keys to allow remote control with `rndc
> -s`, but it sounds to me like rndc is a red herring.)
>
> There's also my `nsdiff` program https://dotat.at/prog/nsdiff/
> which can make a zone on a remote server look like a local zone
> file using nsupdate.
>
> Tony.
> --
> f.anthony.n.finchhttps://dotat.at/
> North Utsire, South Utsire: Northerly or northwesterly 4 to 6,
> occasionally 7 at first in eastern South Utsire. Rough at first in
> eastern South Utsire, otherwise moderate. Showers. Good.
>
>
___
Please 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: Using RNDC to control remote access to my BIND server

[Tony Finch]

Greg Donohoe  wrote:

> I have created a CI/CD pipeline in order to amend zone files using nsupdate
> based on a front end user request. This portion of the pipeline is working
> as expected so now I want to be able to connect from my pipeline runner to
> my remote BIND staging server and update the zone files on there with my
> newly updated zone file.

If you want to make the same change on the remote server that you made
locally, can't you use nsupdate again but point it at the remote server?
Or is there something more complicated going on?

Use ddns-keygen to create a TSIG authentication key and add the key to the
allow-update ACL on the remote server.

(You can also add your own TSIG keys to allow remote control with `rndc
-s`, but it sounds to me like rndc is a red herring.)

There's also my `nsdiff` program https://dotat.at/prog/nsdiff/
which can make a zone on a remote server look like a local zone
file using nsupdate.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
North Utsire, South Utsire: Northerly or northwesterly 4 to 6,
occasionally 7 at first in eastern South Utsire. Rough at first in
eastern South Utsire, otherwise moderate. Showers. Good.

___
Please 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: Using RNDC to control remote access to my BIND server

[Jim Popovitch via bind-users]

On Thu, 2021-04-22 at 10:59 +0100, Greg Donohoe wrote:
> Hello,
> I have created a CI/CD pipeline in order to amend zone files using
> nsupdate based on a front end user request. This portion of the
> pipeline is working as expected so now I want to be able to connect
> from my pipeline runner to my remote BIND staging server and update
> the zone files on there with my newly updated zone file.
> I initially thought about using ssh from the runner to the remote BIND
> server but this may not be the most secure way of connecting.
> So my question is: Is it possible to use RNDC to manage my connection
> from host to remote server and if so, how can I ensure complete
> security?


My suggestion is to install a runner on the staging server and register
that runner in your gitlab/github/git/bitbucket/etc. You'd still have to
setup the trust bits so that the runner docker/js/etc environment can
talk to the staging named.

There's 10,000 ways to do things in CI/CD, the 1 way that doesn't exist
is the only one you will recall in the middle of a weekend while you are
on vacation. :) 

-Jim P.

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

Using RNDC to control remote access to my BIND server

[Greg Donohoe]

Hello,
I have created a CI/CD pipeline in order to amend zone files using nsupdate
based on a front end user request. This portion of the pipeline is working
as expected so now I want to be able to connect from my pipeline runner to
my remote BIND staging server and update the zone files on there with my
newly updated zone file.
I initially thought about using ssh from the runner to the remote BIND
server but this may not be the most secure way of connecting.
So my question is: Is it possible to use RNDC to manage my connection from
host to remote server and if so, how can I ensure complete security?

All input greatly appreciated.
Thanks.
Greg.
___
Please 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: rndc stops listening

[Ondřej Surý]

John,

please report the issue to the ISC GitLab.

Thanks,
--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.

> On 7. 4. 2021, at 19:32, John Thurston  wrote:
> 
> I now see this same behavior running BIND 9.16.12 on Ubuntu
> 
> I have never seen it on my instances running 9.11.x on Centos
> 
> I'd sure like to figure out why (or even when) it stops listening on port 
> 953. Does anyone have any suggestions?
> 
> --
> Do things because you should, not just because you can.
> 
> John Thurston907-465-8591
> john.thurs...@alaska.gov
> Department of Administration
> State of Alaska
> 
>> On 12/11/2020 11:13 AM, John Thurston wrote:
>> Running BIND 9.16.9 on CentOS 8
>> I have the following in my .conf
>>> controls {
>>>   inet 127.0.0.1 port 953
>>> allow { 127.0.0.1; } keys { "mykey"; };
>>>   inet 10.2.0.1 port 953
>>> allow { 10.2.3.3; 10.2.4.3; }
>>> keys { "threekey"; "fourkey"; };
>>> };
>> And I normally can see the named process is listening on tcp:953 on both 
>> 127.0.0.1 and 10.2.0.1.   But sometimes later, I find it listening only on 
>> 127.0.0.1.   If I do an 'rndc reconfig', it starts listening again on both 
>> addresses. Normal DNS service has continued uninterrupted.
>> I can't find footprints left from anything falling down. I'd could just 
>> install a watchdog to 'reconfig' whenever port 953 stops answering, but I'd 
>> rather figure out why it is stopping and correct the problem. To do that, I 
>> need more information.
>> Am I not looking in the correct log?
>> Do I need to crank up the logging level for something?
>> If so, for what? and how high?
> ___
> Please 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

___
Please 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: rndc stops listening

[John Thurston]

I now see this same behavior running BIND 9.16.12 on Ubuntu

I have never seen it on my instances running 9.11.x on Centos

I'd sure like to figure out why (or even when) it stops listening on 
port 953. Does anyone have any suggestions?


--
Do things because you should, not just because you can.

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska

On 12/11/2020 11:13 AM, John Thurston wrote:

Running BIND 9.16.9 on CentOS 8

I have the following in my .conf

controls {
  inet 127.0.0.1 port 953
    allow { 127.0.0.1; } keys { "mykey"; };
  inet 10.2.0.1 port 953
    allow { 10.2.3.3; 10.2.4.3; }
    keys { "threekey"; "fourkey"; };
};


And I normally can see the named process is listening on tcp:953 on both 
127.0.0.1 and 10.2.0.1.   But sometimes later, I find it listening only 
on 127.0.0.1.   If I do an 'rndc reconfig', it starts listening again on 
both addresses. Normal DNS service has continued uninterrupted.


I can't find footprints left from anything falling down. I'd could just 
install a watchdog to 'reconfig' whenever port 953 stops answering, but 
I'd rather figure out why it is stopping and correct the problem. To do 
that, I need more information.


Am I not looking in the correct log?
Do I need to crank up the logging level for something?
If so, for what? and how high?


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

rndc stops listening

[John Thurston]

Running BIND 9.16.9 on CentOS 8

I have the following in my .conf

controls {
  inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "mykey"; };
  inet 10.2.0.1 port 953
allow { 10.2.3.3; 10.2.4.3; }
keys { "threekey"; "fourkey"; };
};


And I normally can see the named process is listening on tcp:953 on both 
127.0.0.1 and 10.2.0.1.   But sometimes later, I find it listening only 
on 127.0.0.1.   If I do an 'rndc reconfig', it starts listening again on 
both addresses. Normal DNS service has continued uninterrupted.


I can't find footprints left from anything falling down. I'd could just 
install a watchdog to 'reconfig' whenever port 953 stops answering, but 
I'd rather figure out why it is stopping and correct the problem. To do 
that, I need more information.


Am I not looking in the correct log?
Do I need to crank up the logging level for something?
If so, for what? and how high?

--
--
Do things because you should, not just because you can.

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
___
Please 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

Looking for clarifications about the "TCP high-water" in `rndc status`

[Mauricio Vergara Ereche]

Hello there!

I have been reading the ARM and some of the KB, but I'm still a bit
confused on what this "TCP high-water" status exactly represent

I assume it means the amount of active TCP connections that happened at the
same time.
Does it mean connections active? or that were not closed at some point?
Or is it the amount of clients connected at the same time?
Does that counter resets after each service restart? or does it have a
period in which is recalculated? (maybe it represents the last 24 hours or
something like that?)

Thank you guys in advance,
Mauricio

-- 
Mauricio Vergara Ereche
about.me/mave
___
Please 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: rndc valid key types

[Evan Hunt]

On Tue, Jul 07, 2020 at 04:32:37PM -0700, Gregory Sloop wrote:
> I've seen reports that only HMAC-MD5 is the only valid key type.

That was the case at one time, but hasn't been for years.

> Is there any (security) reason/implications to use something "better"
> than MD5?

MD5 is broken (as is SHA1). In this specific context, a forged rndc message
is probably impracticable on any reasonable time scale, and I wouldn't fear
for security if I were using them.  *But*, they're broken, and crypto
people don't like keeping broken things around, so I wouldn't count on them
being supported forever. We've already removed MD5 support in the context
of DNSSEC keys; TSIG could come next.

So, if you want to generate a key and not have to worry about generating
another one in a year or two, I would advise against MD5 or SHA1.

> Is there any reason not to select the strongest - HMAC-SHA512?

No, go ahead. I tend to use sha256, just because it's the default
from rndc-confgen.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please 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

rndc valid key types

[Gregory Sloop]

So, I've spent some time looking at the man pages and googling without any 
definitive answer.

I'm generating some new rndc keys for my bind9 config. (9.11.3 in this 
particular case, if it matters.)

rndc-confgen has quite a number of options for the key-type - but I'm not sure 
what BIND9 will handle for RNDC.

I've seen reports that only HMAC-MD5 is the only valid key type.

...

Just before posting this, I checked the RNDC man page and found this: 
[At least I saved myself some public embarrassment! :) ]
---
rndc communicates with the name server over a TCP connection, sending commands 
authenticated with digital signatures. In the current versions of rndc and 
named, the only supported authentication algorithms are HMAC-MD5 (for 
compatibility), HMAC-SHA1, HMAC-SHA224, HMAC-SHA256 (default), HMAC-SHA384 and 
HMAC-SHA512. They use a shared secret on each end of the connection. This 
provides TSIG-style authentication for the command request and the name 
server's response. All commands sent over the channel must be signed by a 
key_id known to the server.
---

Still, the root cause for my query
Is there any (security) reason/implications to use something "better" than MD5?

I'd lean toward something like HMAC-SHA256/384/512.

Perhaps there's a discussion somewhere I haven't found - and I'd be glad to be 
pointed to that, instead of taking someone's time re-typing a bunch of details. 
But I can't seem to find anything. 
I assume it might be easier to forge an update for rndc with an MD5 key, right? 
Is there any reason not to select the strongest - HMAC-SHA512?

Just wanting to be sure I understand the implications of any particular choice.

TIA
-Greg___
Please 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: unexpected behaviour of rndc dnstap -roll

[Jakob Dhondt]

Thanks for your help!

On 21.06.20 22:30, Tony Finch wrote:
> Jakob Dhondt  wrote:
>> I am generating dnstap files using bind and regularly roll them using
>> 'rndc dnstap -roll [number]'. The way I understand the documentation is
>> that there should be max [number] old dnstap files after executing this
>> command but what actually happens is that all files are being kept so
>> that I have to remove the old ones myself.
> Yes, this is a bug. I could reproduce the problem but I couldn't see it
> by staring at the code, so I added some extra logging until I found
> the mistake. I've submitted a merge request for this patch:
>
> https://gitlab.isc.org/fanf/bind9/-/commit/29d275965c0cddc862eeccb28188b8fd124fb321
>
> Tony.

-- 

SWITCH
Jakob Dhondt, Security Engineer, SWITCH-CERT
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 16 23
jakob.dho...@switch.ch, www.switch.ch
Security-News: securityblog.switch.ch

___
Please 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: unexpected behaviour of rndc dnstap -roll

[Tony Finch]

Jakob Dhondt  wrote:
>
> I am generating dnstap files using bind and regularly roll them using
> 'rndc dnstap -roll [number]'. The way I understand the documentation is
> that there should be max [number] old dnstap files after executing this
> command but what actually happens is that all files are being kept so
> that I have to remove the old ones myself.

Yes, this is a bug. I could reproduce the problem but I couldn't see it
by staring at the code, so I added some extra logging until I found
the mistake. I've submitted a merge request for this patch:

https://gitlab.isc.org/fanf/bind9/-/commit/29d275965c0cddc862eeccb28188b8fd124fb321

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
public services available on equal terms to all
___
Please 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

unexpected behaviour of rndc dnstap -roll

[Jakob Dhondt]

Hi everyone,

I am generating dnstap files using bind and regularly roll them using
'rndc dnstap -roll [number]'. The way I understand the documentation is
that there should be max [number] old dnstap files after executing this
command but what actually happens is that all files are being kept so
that I have to remove the old ones myself.

This is what the documentation says:

dnstap ( -reopen | -roll [number] )
... If number is specified, then the number of backup log files is
limited to that number.

Am I missing something here? Is the behaviour that I'm observing the
expected one? The logs don't tell me much and I couldn't find any hints
about this on the Internet. Thanks for any help!

Kind regards,

Jakob

-- 

SWITCH
Jakob Dhondt, Security Engineer, SWITCH-CERT
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 16 23
jakob.dho...@switch.ch, www.switch.ch
Security-News: securityblog.switch.ch

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

Can we use rndc addzone to add zone in rpz configuration?

[Blason R]

Hi,

Keen to know if rndc addzone functionality can be used to add zones in bind
serving response-policy? If so then what would be my view? Do I need to
define my view to make it work?

I tried this and its failing hence wondering if rndc can be used to add
zone or delete zone on the fly?

Here is my config

**
options {
version "x";
allow-query { localhost;subnets; };
directory "/var/cache/bind";
recursion yes;
   * allow-new-zones yes;*
querylog yes;
forwarders {
9.9.9.9
 };
//  dnssec-validation auto;
request-ixfr yes;
auth-nxdomain no;# conform to RFC1035
//  listen-on-v6 { any; };
listen-on port 53 { any; };
response-policy { zone "whitlist.allow" policy passthru;
zone "immediate.block";
zone "malware.trap";
zone "block.tld";
zone "cryptojack.block";
zone "ransomwareips.block";  };
};

And I wanted to add lets say porn.block zone
___
Please 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: rndc - sync before reload?

[Evan Hunt]

On Fri, Jul 12, 2019 at 01:34:35AM +, John W. Blue wrote:
> I have zero experience with dynamic zones on BIND because all of ours are
> static.  That said, and since nobody else has commented, it seems like it
> would make sense to sync before reload.
> 
> The man says that sync writes out to the journal which shouldn't ever be
> a bad thing.

It doesn't write *to* the journal file; it takes the changes that are
encoded in the journal file and writes them out to the zone master file.

I guess that wasn't clear, so maybe the man page needs some clarification:

   sync [-clean] [zone [class [view]]]
   Sync changes in the journal file for a dynamic zone to the master
   file. If the "-clean" option is specified, the journal file is also
   removed. If no zone is specified, then all zones are synced.

"rndc reload" loads the zone from the master file *plus* the journal file,
if there is one. There's no need to sync the journal file to the master
file before reloading.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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: rndc - sync before reload?

[Alan Clegg]

On 7/14/19 8:00 PM, John W. Blue wrote:
> Please elaborate on the technical reason why instead of being terse.

I'll give a short version:

"rndc reload" existed from the early days of BIND with the first notice
in CHANGES being [bug] 287 in 9.1.0b1.

"rndc sync" came along with [func] 3084 in BIND 9.9.0a1.

You don't need to sync before you reload.

As to the internals, I dunno.

AlanC

___
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: rndc - sync before reload?

[John W. Blue]

Please elaborate on the technical reason why instead of being terse.

Thanks!

John

Sent from Nine<http://www.9folders.com/>

From: Anand Buddhdev 
Sent: Saturday, July 13, 2019 4:48 PM
To: John Thurston; bind-users@lists.isc.org
Subject: Re: rndc - sync before reload?

On 10/07/2019 20:08, John Thurston wrote:

Hi John,

> On a server with both static and dynamic zones, is there any reason to
> perform an:
>   rndc sync
> prior to issuing an:
>   rndc reload

No, there is no need for a sync before reload.

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
___
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: rndc - sync before reload?

[Anand Buddhdev]

On 10/07/2019 20:08, John Thurston wrote:

Hi John,

> On a server with both static and dynamic zones, is there any reason to
> perform an:
>   rndc sync
> prior to issuing an:
>   rndc reload

No, there is no need for a sync before reload.

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: rndc - sync before reload?

[John W. Blue]

I have zero experience with dynamic zones on BIND because all of ours are 
static.  That said, and since nobody else has commented, it seems like it would 
make sense to sync before reload.

The man says that sync writes out to the journal which shouldn't ever be a bad 
thing.

John

Sent from Nine<http://www.9folders.com/>

From: John Thurston 
Sent: Wednesday, July 10, 2019 1:09 PM
To: bind-users@lists.isc.org
Subject: rndc - sync before reload?

On a server with both static and dynamic zones, is there any reason to
perform an:
   rndc sync
prior to issuing an:
   rndc reload


--
Do things because you should, not just because you can.

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
___
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

rndc - sync before reload?

[John Thurston]

On a server with both static and dynamic zones, is there any reason to 
perform an:

  rndc sync
prior to issuing an:
  rndc reload


--
   Do things because you should, not just because you can.

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
___
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: rndc status command hangs in bind 9.14.2

[Andi Vajda]

On Wed, 12 Jun 2019, Micha? K?pie? wrote:


Hi Andi,


Is there something different about 9.14 defaults that I now need to include
in my config to get past this ?


I am unable to reproduce this, things seem to work fine, at least on a
fresh amd64 NetBSD 7.2 VM:

   # bin/rndc/rndc status
   version: BIND 9.14.2 (Stable Release) 
   running on vm0: NetBSD amd64 7.2 NetBSD 7.2 (GENERIC.201808291900Z)
   boot time: Wed, 12 Jun 2019 07:08:35 GMT
   last configured: Wed, 12 Jun 2019 07:08:35 GMT
   configuration file: /etc/named.conf
   CPUs found: 4
   worker threads: 4
   UDP listeners per interface: 4
   number of zones: 100 (99 automatic)
   debug level: 0
   xfers running: 0
   xfers deferred: 0
   soa queries in progress: 0
   query logging is OFF
   recursive clients: 0/900/1000
   tcp clients: 2/150
   server is up and running

What hardware platform are you experiencing this on?  What is your
"named -V" output?  What is your build process?  If you are still
hitting this, please open a bug report on gitlab.isc.org, providing the
answers to the questions above and any other information that may be
helpful.


I filed https://gitlab.isc.org/isc-projects/bind9/issues/1085.
The build process is:
  - cd /opt/pkgsrc/bind914
  - cvs update
  - make update
In other words, I'm using the netbsd 7.2 pkgsrc source distribution and 
build framework. I did not build bind 9.14.2 from directly downloaded 
sources myself. In particular, it seems that the netbsd 7.2 pkgsrc build

applies around 37 patch files.

I think the named -V and log excerpts answer all the other questions you 
asked above. I'm very sorry to see that the issue interface completely 
munged my formatting :-(


Thank you for your assistance !

Andi..



--
Best regards,
Micha? K?pie?


___
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: rndc status command hangs in bind 9.14.2

[Michał Kępień]

Hi Andi,

> Is there something different about 9.14 defaults that I now need to include
> in my config to get past this ?

I am unable to reproduce this, things seem to work fine, at least on a
fresh amd64 NetBSD 7.2 VM:

# bin/rndc/rndc status
version: BIND 9.14.2 (Stable Release) 
running on vm0: NetBSD amd64 7.2 NetBSD 7.2 (GENERIC.201808291900Z)
boot time: Wed, 12 Jun 2019 07:08:35 GMT
last configured: Wed, 12 Jun 2019 07:08:35 GMT
configuration file: /etc/named.conf
CPUs found: 4
worker threads: 4
UDP listeners per interface: 4
number of zones: 100 (99 automatic)
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/900/1000
tcp clients: 2/150
server is up and running

What hardware platform are you experiencing this on?  What is your
"named -V" output?  What is your build process?  If you are still
hitting this, please open a bug report on gitlab.isc.org, providing the
answers to the questions above and any other information that may be
helpful.

-- 
Best regards,
Michał Kępień
___
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

rndc status command hangs in bind 9.14.2

[Andi Vajda]

 Hi,

I've been running bind 9.12 on netbsd 7.2 without any issues.
The bind-9.12 package is now marked deprecated (eol) and we're encouraged to 
upgrade to bind 9.14.


I've been giving it a few tries and, while my server seems to be working 
normally with bind 9.14.2, it doesn't respond to rndc commands.


Running rndc -V status shows rndc stopping after 'send message'.
I see nothing in the logs that would explain this. In particular, my rndc 
key setup is working fine.
I also tried increasing log levels and never got anything added to the logs 
that was triggered by my calling rndc status.


I'm using the exact same configs between 9.12 and 9.14. With a 9.12 server 
rndc works fine (compiled from either version of bind). With a 9.14 server
rndc just hangs after sending its request message to the server. It never 
receives and parses a response. If I ctrl-c it, it says that "recv" got 
interrupted.


Is there something different about 9.14 defaults that I now need to include 
in my config to get past this ?

My named is running in a chroot cage.

Thank you for your assistance and clues !

Andi..
___
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: rndc and nsupdate failing to work for me

[Marc Chamberlin via bind-users]

On 03/14/2019 04:40 AM, Niall O'Reilly wrote:
> On 14 Mar 2019, at 5:17, Marc Chamberlin via bind-users wrote:
>
>> On 03/13/2019 08:33 PM, John W. Blue wrote:
>>> As an option, instead of including /etc/rndc.key nothing prevents you
>>> from including rndc.conf.  That way you are consistent with your useage.
> Another option is to include rndc.key from both rndc.conf and
> named.conf, which also keeps things consistent.  Additionally, it
> allows rndc.key to have stricter protection than the .conf files
> (in my case, mode bits 0640 rather than 0644).
Thanks Niall, I thought I had tried that approach when I was poking
around with rndc.conf, but apparently I must have done it wrong. The
include statement in rndc.conf does work, however I still do get the
warning - "WARNING: key file (/etc/rndc.key) exists, but using default
configuration file (/etc/rndc.conf)" which seems to be unnecessary but I
am not going to worry about it.
>
> I seem to recall actually needing to do this because of named
> objecting to the syntax of some of the configuration statements
> I needed to use in rndc.conf.
>
> I hope this helps.
Yes, it does, thanks again... Much cleaner and safer this way...    Marc...
>
> Niall O'Reilly


-- 
*Computers: the final frontier. These are the voyages of the user Marc.
His mission: to explore strange new hardware. To seek out new software
and new applications.
To boldly go where no Marc has gone before!
*
___
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: rndc and nsupdate failing to work for me

[Marc Chamberlin via bind-users]

On 03/14/2019 12:02 AM, Mark Andrews wrote:
> "rndc showzone" only works if you also have "allow-new-zones yes;” set.
Really??? Wow! Thanks Mark! I would never have guessed that, but yes it
does make rndc much happier!
>
> The last time there was a complaint about UPDATE’s not sticking the
> startup procedure was wiping out the changes.
OH! That does not bod well, means I got to go and bellyache at the
OpenSuSE developers to see if something is going on with "systemctl
restart named.service" and hopefully this won't degenerate into a finger
pointing contest! ;-) I will go poke around and take a look at the
startup scripts
>
> Mark
>
>> On 14 Mar 2019, at 10:01 am, Marc Chamberlin via bind-users 
>>  wrote:
>>
>> Hello Bind Users,
>>
>> I have been working on upgrading my Bind 9.11.2 server (running on a Linux 
>> system, OpenSuSE Leap 15) so that I can accept DNS challenges/verification 
>> from/for LetsEncrypt certificates, and I am running into a wall trying to 
>> get nsupdate (and rndc which I wanted to use to test the server with) to 
>> work with the server. So I hope some kind guru here can lead me into the 
>> light cuz I am lost
>>
>> My configuration is really not all that complicated, I am running the server 
>> on a firewall computer that supports other services such as web and email 
>> services also. I have a SOHO internal network behind the firewall computer. 
>> I have configured the Bind (named) server with the 3 standard views - 
>> localhost.resolver, internal, and external. Since I support a number of 
>> virtual hosts and real hosts I have quit a few zones defined for each view. 
>> For regular queries and things like zone transfers the server is performing 
>> OK.
>>
>> That said I will show what I think are the relevant definitions from my 
>> configuration files, with sensitive info redacted of course, and follow on 
>> with questions I have -
>>
>> named.conf -
>> There is a bunch of stuff at the beginning of this file, but I think it is 
>> irrelevant to this issue. Correct me if I am wrong and I will be happy to 
>> post it...
>>
>>> include "/etc/rndc.key"; 
>>>  controls {
>>>inet * port 953
>>>allow { any; } keys { "rndc-key"; };
>>>  };
>>>   view "localhost_resolver"
>>>  {
>>> match-clients { localhost; };
>>> match-destinations  { localhost; };
>> ... more stuff here but I don't think it is relevant
>>>   include "/etc/named.d/local/local_zones.conf";
>>>   }
>>> view "internal" { 
>>> match-clients  { 192.168.10.0/24; };
>>>match-destinations { 192.168.10.0/24; };
>>>recursion yes;
>> ... more stuff here but I don't think it is relevant   
>>
>>
>>> include "/etc/named.d/internal/internal_zones.conf";
>>> };
>>
>>> view "external" { 
>>>match-clients  { any; };
>>>match-destinations { any; };
>>>recursion no;
>> ... more stuff here but I don't think it is relevant  
>>
>>
>>>include "/etc/named.d/external/external_zones.conf";
>>> };
>> This seems pretty straightforward configuration in named.conf.  The 
>> configuration of a zone in the external view typically looks like this -
>>
>> zone "mydomain.com" in {
>> file "/etc/named.d/external/master/mydomain.com";
>> type master;
>> allow-transfer { "dnsmadeeasy1"; };
>> also-notify { xx.xxx.xx.xxx; yyy.yyy.yy.yyy; zzz.zzz.zz.zz; };
>> allow-query { any; };
>> allow-update {
>>key "letsencrypt";
>> };
>> };
>>
>> And this is what is in rndc.conf -
>>
>>
>>> key "rndc-key" {
>>> algorithm hmac-md5;
>>> secret "secretkeycodehere";
>>>  };
>>> options {
>>> default-key "rndc-key";
>>> default-server localserver;
>>> default-port 953;
>>> };
>>> server localserver {
>>> addresses   { 127.0.0.1 port 953; };
>>> key "rndc-key"; 
>>> };
>>> server intserver {
>>> addresses   { 192.168.10.100 port 953; };
>>> key "rndc-key"; 
>>> };
>>> server extserver {
>>> addresses   { xxx.yyy.zzz.aaa

Re: rndc and nsupdate failing to work for me

[Niall O'Reilly]

On 14 Mar 2019, at 5:17, Marc Chamberlin via bind-users wrote:

> On 03/13/2019 08:33 PM, John W. Blue wrote:
>>
>> As an option, instead of including /etc/rndc.key nothing prevents you
>> from including rndc.conf.  That way you are consistent with your useage.

Another option is to include rndc.key from both rndc.conf and
named.conf, which also keeps things consistent.  Additionally, it
allows rndc.key to have stricter protection than the .conf files
(in my case, mode bits 0640 rather than 0644).

I seem to recall actually needing to do this because of named
objecting to the syntax of some of the configuration statements
I needed to use in rndc.conf.

I hope this helps.

Niall O'Reilly
___
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: rndc and nsupdate failing to work for me

[Mark Andrews]

"rndc showzone" only works if you also have "allow-new-zones yes;” set.

The last time there was a complaint about UPDATE’s not sticking the
startup procedure was wiping out the changes.

Mark

> On 14 Mar 2019, at 10:01 am, Marc Chamberlin via bind-users 
>  wrote:
> 
> Hello Bind Users,
> 
> I have been working on upgrading my Bind 9.11.2 server (running on a Linux 
> system, OpenSuSE Leap 15) so that I can accept DNS challenges/verification 
> from/for LetsEncrypt certificates, and I am running into a wall trying to get 
> nsupdate (and rndc which I wanted to use to test the server with) to work 
> with the server. So I hope some kind guru here can lead me into the light cuz 
> I am lost
> 
> My configuration is really not all that complicated, I am running the server 
> on a firewall computer that supports other services such as web and email 
> services also. I have a SOHO internal network behind the firewall computer. I 
> have configured the Bind (named) server with the 3 standard views - 
> localhost.resolver, internal, and external. Since I support a number of 
> virtual hosts and real hosts I have quit a few zones defined for each view. 
> For regular queries and things like zone transfers the server is performing 
> OK.
> 
> That said I will show what I think are the relevant definitions from my 
> configuration files, with sensitive info redacted of course, and follow on 
> with questions I have -
> 
> named.conf -
> There is a bunch of stuff at the beginning of this file, but I think it is 
> irrelevant to this issue. Correct me if I am wrong and I will be happy to 
> post it...
> 
>> include "/etc/rndc.key"; 
>>  controls {
>>inet * port 953
>>allow { any; } keys { "rndc-key"; };
>>  };
>>   view "localhost_resolver"
>>  {
>> match-clients { localhost; };
>> match-destinations  { localhost; };
> ... more stuff here but I don't think it is relevant
>>   include "/etc/named.d/local/local_zones.conf";
>>   }
>> view "internal" { 
>> match-clients  { 192.168.10.0/24; };
>>match-destinations { 192.168.10.0/24; };
>>recursion yes;
> ... more stuff here but I don't think it is relevant   
> 
> 
>> include "/etc/named.d/internal/internal_zones.conf";
>> };
> 
> 
>> view "external" { 
>>match-clients  { any; };
>>match-destinations { any; };
>>recursion no;
> ... more stuff here but I don't think it is relevant  
> 
> 
>>include "/etc/named.d/external/external_zones.conf";
>> };
> 
> This seems pretty straightforward configuration in named.conf.  The 
> configuration of a zone in the external view typically looks like this -
> 
> zone "mydomain.com" in {
> file "/etc/named.d/external/master/mydomain.com";
> type master;
>     allow-transfer { "dnsmadeeasy1"; };
> also-notify { xx.xxx.xx.xxx; yyy.yyy.yy.yyy; zzz.zzz.zz.zz; };
> allow-query { any; };
> allow-update {
>key "letsencrypt";
> };
> };
> 
> And this is what is in rndc.conf -
> 
> 
>> key "rndc-key" {
>> algorithm hmac-md5;
>> secret "secretkeycodehere";
>>  };
>> options {
>> default-key "rndc-key";
>> default-server localserver;
>> default-port 953;
>> };
>> server localserver {
>> addresses   { 127.0.0.1 port 953; };
>> key "rndc-key"; 
>> };
>> server intserver {
>> addresses   { 192.168.10.100 port 953; };
>> key "rndc-key"; 
>> };
>> server extserver {
>> addresses   { xxx.yyy.zzz.aaa port 953; };
>> key "rndc-key"; 
>> };
> 
> Again, straightforward, and as I said normal queries do work  However 
> when I use rndc to poke at it, this is what happens -
> 
> 
>> # rndc showzone mydomain.com in external
>> WARNING: key file (/etc/rndc.key) exists, but using default configuration 
>> file (/etc/rndc.conf)
>> rndc: 'showzone' failed: failure
> 
> I don't understand why I am getting the warning, seems like a so what since 
> the keys are identical in both locations. (I couldn't figure out if it is 
> possible to use an include statement instead of the key definition in 
> rndc.conf)  As for the failure when I asked it to do a showzone, I don't have 
> a clue as to why this is failing. Log files are not helpful (and neit

Re: rndc and nsupdate failing to work for me

[Marc Chamberlin via bind-users]

Hi John,  thanks for replying and your thoughts! I will intersperse my
feedback within your comments -

On 03/13/2019 08:33 PM, John W. Blue wrote:
>
> Marc,
>
>  
>
> Regarding your rndc problem, I think you might be confusing rndc.
>
>  
>
> If rndc is invoked with no options, specifically “k”, then rndc
> assumes the key it needs is in the rndc.conf file.  If rndc.conf is
> not present, rndc will use the default rndc.key file.  That said,
> since rndc knows there is an /etc/rndc.key file but it choosing to use
> rndc.conf is the secret the same in both places?
>
Yes
>
>  
>
> As an option, instead of including /etc/rndc.key nothing prevents you
> from including rndc.conf.  That way you are consistent with your useage.
>
I raised an eyebrow at this suggestion thinking oh how cool...  but a
quick attempt at including rndc.conf in named.conf lead named to
bellyache about multiple "options" clauses... I will poke at it some
more, as it would be nice to minimize the possibility of getting the two
key definitions out of sync, which is why I tried it from the other
direction using the include statement in rndc.conf...
>
>  
>
> I personally do not use nsupdate, but I thought that key file had to
> be created by dnssec-keyen and if you opt to use “k” then the file
> suffix on the command line had to be “.private”.
>
Actually I did use dnssec-keygen to generate the key file! ;-) To be
precise -
> dnssec-keygen -a HMAC-SHA512 -b 512 -n HOST letsencrypt
That generates two files, one is a .key and the other is a .private  It
doesn't seem to matter which file I use with nsupdate, it seems happy
with either and both files do contain the private key. In any event, no
matter which I choose the persistence issue remains...

>  
>
> Hope that helps and good hunting!
>
At least you confirmed my thinking so far, great minds think alike!  
Marc...
>
>  
>
> John
>
>  
>
> *From:*bind-users [mailto:bind-users-boun...@lists.isc.org] *On Behalf
> Of *Marc Chamberlin via bind-users
> *Sent:* Wednesday, March 13, 2019 6:02 PM
> *To:* bind-users@lists.isc.org
> *Subject:* rndc and nsupdate failing to work for me
>
>  
>
> Hello Bind Users,
>
> I have been working on upgrading my Bind 9.11.2 server (running on a
> Linux system, OpenSuSE Leap 15) so that I can accept DNS
> challenges/verification from/for LetsEncrypt certificates, and I am
> running into a wall trying to get nsupdate (and rndc which I wanted to
> use to test the server with) to work with the server. So I hope some
> kind guru here can lead me into the light cuz I am lost
>
> My configuration is really not all that complicated, I am running the
> server on a firewall computer that supports other services such as web
> and email services also. I have a SOHO internal network behind the
> firewall computer. I have configured the Bind (named) server with the
> 3 standard views - localhost.resolver, internal, and external. Since I
> support a number of virtual hosts and real hosts I have quit a few
> zones defined for each view. For regular queries and things like zone
> transfers the server is performing OK.
>
> That said I will show what I think are the relevant definitions from
> my configuration files, with sensitive info redacted of course, and
> follow on with questions I have -
>
> named.conf -
>
> There is a bunch of stuff at the beginning of this file, but I think
> it is irrelevant to this issue. Correct me if I am wrong and I will be
> happy to post it...
>
> include "/etc/rndc.key";
>  controls {
>    inet * port 953
>    allow { any; } keys { "rndc-key"; };
>  };
>   view "localhost_resolver"
>  {
>     match-clients         { localhost; };
>     match-destinations  { localhost; };
>
> ... more stuff here but I don't think it is relevant
>
>   include "/etc/named.d/local/local_zones.conf";
>   }
>
> view "internal" {
>     match-clients  { 192.168.10.0/24; };
>    match-destinations { 192.168.10.0/24; };
>    recursion yes;
>
> ... more stuff here but I don't think it is relevant  
>
> include "/etc/named.d/internal/internal_zones.conf";
> };
>
> view "external" {
>    match-clients  { any; };
>    match-destinations { any; };
>    recursion no;
>
> ... more stuff here but I don't think it is relevant  
>
>    include "/etc/named.d/external/external_zones.conf";
> };
>
> This seems pretty straightforward configuration in named.conf.  The
> configuration of a zone in the external view typicall

RE: rndc and nsupdate failing to work for me

[John W. Blue]

Marc,

Regarding your rndc problem, I think you might be confusing rndc.

If rndc is invoked with no options, specifically “k”, then rndc assumes the key 
it needs is in the rndc.conf file.  If rndc.conf is not present, rndc will use 
the default rndc.key file.  That said, since rndc knows there is an 
/etc/rndc.key file but it choosing to use rndc.conf is the secret the same in 
both places?

As an option, instead of including /etc/rndc.key nothing prevents you from 
including rndc.conf.  That way you are consistent with your useage.

I personally do not use nsupdate, but I thought that key file had to be created 
by dnssec-keyen and if you opt to use “k” then the file suffix on the command 
line had to be “.private”.

Hope that helps and good hunting!

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Marc 
Chamberlin via bind-users
Sent: Wednesday, March 13, 2019 6:02 PM
To: bind-users@lists.isc.org
Subject: rndc and nsupdate failing to work for me


Hello Bind Users,

I have been working on upgrading my Bind 9.11.2 server (running on a Linux 
system, OpenSuSE Leap 15) so that I can accept DNS challenges/verification 
from/for LetsEncrypt certificates, and I am running into a wall trying to get 
nsupdate (and rndc which I wanted to use to test the server with) to work with 
the server. So I hope some kind guru here can lead me into the light cuz I am 
lost

My configuration is really not all that complicated, I am running the server on 
a firewall computer that supports other services such as web and email services 
also. I have a SOHO internal network behind the firewall computer. I have 
configured the Bind (named) server with the 3 standard views - 
localhost.resolver, internal, and external. Since I support a number of virtual 
hosts and real hosts I have quit a few zones defined for each view. For regular 
queries and things like zone transfers the server is performing OK.

That said I will show what I think are the relevant definitions from my 
configuration files, with sensitive info redacted of course, and follow on with 
questions I have -

named.conf -

There is a bunch of stuff at the beginning of this file, but I think it is 
irrelevant to this issue. Correct me if I am wrong and I will be happy to post 
it...
include "/etc/rndc.key";
 controls {
   inet * port 953
   allow { any; } keys { "rndc-key"; };
 };
  view "localhost_resolver"
 {
match-clients { localhost; };
match-destinations  { localhost; };
... more stuff here but I don't think it is relevant

  include "/etc/named.d/local/local_zones.conf";
  }
view "internal" {
match-clients  { 192.168.10.0/24; };
   match-destinations { 192.168.10.0/24; };
   recursion yes;
... more stuff here but I don't think it is relevant
include "/etc/named.d/internal/internal_zones.conf";
};
view "external" {
   match-clients  { any; };
   match-destinations { any; };
   recursion no;
... more stuff here but I don't think it is relevant
   include "/etc/named.d/external/external_zones.conf";
};

This seems pretty straightforward configuration in named.conf.  The 
configuration of a zone in the external view typically looks like this -

zone "mydomain.com" in {
file "/etc/named.d/external/master/mydomain.com";
type master;
allow-transfer { "dnsmadeeasy1"; };
also-notify { xx.xxx.xx.xxx; yyy.yyy.yy.yyy; zzz.zzz.zz.zz; };
allow-query { any; };
    allow-update {
   key "letsencrypt";
};
};

And this is what is in rndc.conf -
key "rndc-key" {
algorithm hmac-md5;
secret "secretkeycodehere";
 };
options {
default-key "rndc-key";
default-server localserver;
default-port 953;
};
server localserver {
addresses   { 127.0.0.1 port 953; };
key "rndc-key";
};
server intserver {
addresses   { 192.168.10.100 port 953; };
key "rndc-key";
};
server extserver {
addresses   { xxx.yyy.zzz.aaa port 953; };
key "rndc-key";
};

Again, straightforward, and as I said normal queries do work  However when 
I use rndc to poke at it, this is what happens -
# rndc showzone mydomain.com in external
WARNING: key file (/etc/rndc.key) exists, but using default configuration file 
(/etc/rndc.conf)
rndc: 'showzone' failed: failure

I don't understand why I am getting the warning, seems like a so what since the 
keys are identical in both locations. (I couldn't figure out if it is possible 
to use an include statement instead of the key definition in rndc.conf)  As for 
the failure when I asked it to do a showzone, I don't have a clue as to why 
this is failing. Log files are not helpful (and neither is this error message 
for that matter!)

I am also experiencing problems with 

rndc and nsupdate failing to work for me

[Marc Chamberlin via bind-users]

Hello Bind Users,

I have been working on upgrading my Bind 9.11.2 server (running on a
Linux system, OpenSuSE Leap 15) so that I can accept DNS
challenges/verification from/for LetsEncrypt certificates, and I am
running into a wall trying to get nsupdate (and rndc which I wanted to
use to test the server with) to work with the server. So I hope some
kind guru here can lead me into the light cuz I am lost

My configuration is really not all that complicated, I am running the
server on a firewall computer that supports other services such as web
and email services also. I have a SOHO internal network behind the
firewall computer. I have configured the Bind (named) server with the 3
standard views - localhost.resolver, internal, and external. Since I
support a number of virtual hosts and real hosts I have quit a few zones
defined for each view. For regular queries and things like zone
transfers the server is performing OK.

That said I will show what I think are the relevant definitions from my
configuration files, with sensitive info redacted of course, and follow
on with questions I have -

named.conf -

There is a bunch of stuff at the beginning of this file, but I think it
is irrelevant to this issue. Correct me if I am wrong and I will be
happy to post it...

> include "/etc/rndc.key";
>  controls {
>    inet * port 953
>    allow { any; } keys { "rndc-key"; };
>  };
>   view "localhost_resolver"
>  {
>     match-clients         { localhost; };
>     match-destinations  { localhost; };
... more stuff here but I don't think it is relevant
>   include "/etc/named.d/local/local_zones.conf";
>   }
> view "internal" {
>     match-clients  { 192.168.10.0/24; };
>    match-destinations { 192.168.10.0/24; };
>    recursion yes;
... more stuff here but I don't think it is relevant  

> include "/etc/named.d/internal/internal_zones.conf";
> };

> view "external" {
>    match-clients  { any; };
>    match-destinations { any; };
>    recursion no; 
... more stuff here but I don't think it is relevant  

>    include "/etc/named.d/external/external_zones.conf";
> };

This seems pretty straightforward configuration in named.conf.  The
configuration of a zone in the external view typically looks like this -

zone "mydomain.com" in {
    file "/etc/named.d/external/master/mydomain.com";
    type master;
    allow-transfer { "dnsmadeeasy1"; };
    also-notify { xx.xxx.xx.xxx; yyy.yyy.yy.yyy; zzz.zzz.zz.zz; };
    allow-query { any; };
    allow-update {
   key "letsencrypt";
    };
};

And this is what is in rndc.conf -

> key "rndc-key" {
>     algorithm hmac-md5;
>     secret "secretkeycodehere";
>  };
> options {
>     default-key "rndc-key";
>     default-server localserver;
>     default-port 953;
> };
> server localserver {
>     addresses   { 127.0.0.1 port 953; };
>     key "rndc-key";
> };
> server intserver {
>     addresses   { 192.168.10.100 port 953; };
>     key "rndc-key";
> };
> server extserver {
>     addresses   { xxx.yyy.zzz.aaa port 953; };
>     key "rndc-key";
> };

Again, straightforward, and as I said normal queries do work 
However when I use rndc to poke at it, this is what happens -

> # rndc showzone mydomain.com in external
> WARNING: key file (/etc/rndc.key) exists, but using default
> configuration file (/etc/rndc.conf)
> rndc: 'showzone' failed: failure

I don't understand why I am getting the warning, seems like a so what
since the keys are identical in both locations. (I couldn't figure out
if it is possible to use an include statement instead of the key
definition in rndc.conf)  As for the failure when I asked it to do a
showzone, I don't have a clue as to why this is failing. Log files are
not helpful (and neither is this error message for that matter!)

I am also experiencing problems with nsupdate in that changes I make
with it are not persistent across a restart of the named service. To
demonstrate this I have a file called test.txt -

debug yes
zone mydomain.com.
update add test.mydomain.com. 86400 TXT "bar"
show
send

and if I use it as follows this is what I see -

> # nsupdate -k /etc/letsencrypt/james/Kletsencrypt.+165+56715.key -v
> ./test.txt
I get lots of output and no indication of any problems. Using dig to see
if the update indeed works -

>  # dig +short -t txt test.mydomain.com "bar"
> "bar"

it works, but if I restart the named service, no joy -

> # systemctl restart named.service
>
> # dig +short -t txt test.mydomain.com "bar"
>
> #
>
>

the update i

Re: RNDC Stats

[Tony Finch]

N. Max Pierson  wrote:
>
> Under Incoming Requests it has QUERY's among some other stats. Is this
> the total queries across all zones? If it is, it doesn't seem to add up
> to what the total of each zone added together in the per zone stats.

Hmm, good question. I suspected it might be something to do with REFUSED
queries for zones that you are not authoritative for, but that doesn't add
up for me either, because my server sent a lot more refused responses than
the difference between its overall query count and the zone query
counts...

awk '
/queries received/ {
if (n < 2) { server += $1 }
else { zones += $1 }
n += 1;
}
/REFUSED/ { refused = $1 }
END {
printf "server %d\n", server;
printf "zones %d\n", zones;
printf "difference %d\n", server - zones;
printf "refused %d\n", refused;
}
' named.stats

server 141242445
zones 141221559
difference 20886
refused 364380

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Cape Wrath to Rattray Head including Orkney: Westerly 5 to 7, occasionally
gale 8 at first in north, becoming variable 3 or 4, then cyclonic 5 to 7
later. Slight or moderate in east, moderate or rough, occasionally very rough
in north. Showers then rain. Good, becoming moderate or 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

RNDC Stats

[N. Max Pierson]

Hi List,

I am trying to pull some metrics from our bind servers and I don't quite
understand what some for the stats in the file really mean. What I am
looking for is total queries and then a breakdown of total queries for each
zone. Under Incoming Requests it has QUERY's among some other stats. Is
this the total queries across all zones? If it is, it doesn't seem to add
up to what the total of each zone added together in the per zone stats. Can
someone please educate me on this and let me know if I am just reading the
file incorrectly? There doesn't seem to be any documentation on the stats
file itself.

Regards,
Max
___
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: dnssec - rndc list

[Tony Finch]

Leonardo Oliveira Ortiz  wrote:
>
> Im configuring DNSSec with nsec3, when i run the first rndc signing
> -list I can check the keys, but when I restart named service this
> command shows nothing... This is a problem?

No, it's benign.

When `named` is signing a zone it puts a couple of extra records at the
zone apex to record its progress. The decoded content of these records is
shown by `rndc signing -list`.

When signing is complete, the special records can be removed, so `rndc
signing -list` will show nothing. That's what `rndc signing -clear` does.

My biggest signed zone is less than 50k records unsigned, and at that size
signing still happens fast enough that I haven't ever managed to catch
`rndc signing -list` while it is in progress :-) Perhaps it's more useful
for NSEC3 with a nonzero hash iteration count...

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
St Davids Head to Great Orme Head, including St Georges Channel: Westerly 3 or
4, backing southerly or southeasterly, 4 or 5, occasionally 6 later. Slight or
moderate. Occasional drizzle later. Good, occasionally moderate later.
___
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

dnssec - rndc list

[Leonardo Oliveira Ortiz]

Hello.
I have a setup with bind 9.9 in chroot, dnssec and inline-sign now.

Im configuring DNSSec with nsec3, when i run the first rndc signing -list I can 
check the keys, but when I restart named service this command shows nothing...
This is a problem? Tried load the keys again with rndc loadkeys but still cant 
check nothing in --list


___
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: Understanding TTL in "rndc dumpdb"-output

[Michał Kępień]

> I've checked the serve-stale status, which is currently off.
> # rndc serve-stale status
> _default: off (stale-answer-ttl=1 max-stale-ttl=604800)
> _bind: off (stale-answer-ttl=1 max-stale-ttl=604800)
> 
> Is this a normal behavior, that in the "rndc dumpdb" nevertheless the TTL in
> the form of "serve-stale" is shown (even if the serve-stale-status = off)?

Yes, this is normal.

Once again (please take another look at the parenthesized part of my
previous response), max-stale-ttl is separate from stale-answer-enable.

-- 
Best regards,
Michał Kępień
___
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: Understanding TTL in "rndc dumpdb"-output

[Tom]

Hi Michal
Thank you for this feedback.

I've checked the serve-stale status, which is currently off.
# rndc serve-stale status
_default: off (stale-answer-ttl=1 max-stale-ttl=604800)
_bind: off (stale-answer-ttl=1 max-stale-ttl=604800)

Is this a normal behavior, that in the "rndc dumpdb" nevertheless the 
TTL in the form of "serve-stale" is shown (even if the 
serve-stale-status = off)?


Thank you.
Tom


On 23.10.18 10:25, Michał Kępień wrote:

After querying my resolver for "testbla11.example.com", I receive a NXDOMAIN
response with a minimum-ttl (in the soa) of 3600.
When I afterwards dump the cache of my resolver (9.12.2-P1) with "rndc
dumpdb" and look for the negative ttl, then a value much bigger than 3600 is
shown (608363):
# grep testbla /var/named/data/named_dump.db
testbla11.example.com.  608363  \-ANY   ;-$NXDOMAIN

This number decrements every second.

What is this number? The same behavior for positive answers too. The
A-record for "www.google.com" has a TTL for 300 seconds. In the "rndc
dumpdb"-output I have a value for 605082.


This happens due to the serve-stale feature being available in BIND 9.12
and later, with max-stale-ttl set to 604800 by default (note that this
does *not* mean serving stale answers is enabled by default).  The TTLs
you are seeing in the cache dump essentially indicate how much longer
any given record will be kept in the cache database.  The serve-stale
"offset" is indicated in a comment near the top of the dump; I am fairly
sure it will say "; using a 604800 second stale ttl" in your case.


___
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: Understanding TTL in "rndc dumpdb"-output

[Michał Kępień]

> After querying my resolver for "testbla11.example.com", I receive a NXDOMAIN
> response with a minimum-ttl (in the soa) of 3600.
> When I afterwards dump the cache of my resolver (9.12.2-P1) with "rndc
> dumpdb" and look for the negative ttl, then a value much bigger than 3600 is
> shown (608363):
> # grep testbla /var/named/data/named_dump.db
> testbla11.example.com.608363  \-ANY   ;-$NXDOMAIN
> 
> This number decrements every second.
> 
> What is this number? The same behavior for positive answers too. The
> A-record for "www.google.com" has a TTL for 300 seconds. In the "rndc
> dumpdb"-output I have a value for 605082.

This happens due to the serve-stale feature being available in BIND 9.12
and later, with max-stale-ttl set to 604800 by default (note that this
does *not* mean serving stale answers is enabled by default).  The TTLs
you are seeing in the cache dump essentially indicate how much longer
any given record will be kept in the cache database.  The serve-stale
"offset" is indicated in a comment near the top of the dump; I am fairly
sure it will say "; using a 604800 second stale ttl" in your case.

-- 
Best regards,
Michał Kępień
___
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

Understanding TTL in "rndc dumpdb"-output

[Tom]

Hi

After querying my resolver for "testbla11.example.com", I receive a 
NXDOMAIN response with a minimum-ttl (in the soa) of 3600.
When I afterwards dump the cache of my resolver (9.12.2-P1) with "rndc 
dumpdb" and look for the negative ttl, then a value much bigger than 
3600 is shown (608363):

# grep testbla /var/named/data/named_dump.db
testbla11.example.com.  608363  \-ANY   ;-$NXDOMAIN

This number decrements every second.

What is this number? The same behavior for positive answers too. The 
A-record for "www.google.com" has a TTL for 300 seconds. In the "rndc 
dumpdb"-output I have a value for 605082.


Any hints?
Thank you.

Kind regards,
Tom
___
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

Question for "rndc reconfig" on bind 9.11.4

[Techs-yama]

Hi, all.

Have a question for "rndc reconfig".

I tried to rndc reconfig option on 9.9.9-P5 and 9.11.4-P1 by source
installed binaries.

Behavior on 9.9.9-P5 was add new named.conf option and only add new
zone was loaded.

But, behavior on 9.11.4-P1 was add new named.conf option, add new zone
and existing zone reloaded.

Was "existing zone reloading" an assumed behavior in rndc reconfig on
BIND 9.11.4(or Higher version) ?

thanks.
___
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: Please help with stuck BIND-9.9.11-P1 named process on rndc reconfig

[Sunghwan Kim(IBI)]

Hi BIND expert,

 

I could not have sent the followings thru https://www.isc.org/bind-
subscription-contact/

due to error on the site.

 

--

I am a S/W engineer who is working on BIND, especially named in Seoul/Korea.

 

I've got reports from a customer regarding stucked "named" process which had

not been performed any request from clients for  5 secs during "rndc
reconfig"

even if it is used to be finished in 700ms

 

24-Aug-2018 17:36:39.073 general: info: received control channel command
'reconfig'

…..

24-Aug-2018 17:36:44.100 general: info: any newly configured zones are now
loaded

 

 My customer's DNS server has been installing BIND-9.9.11-P1.

 

I would like to figure out why named was stucked for even 5 secs on rndc
reconfig.

I've figured out I/O event values(majflt/s) of SAR information on the
server is quite high

which is 58.34 even if it usually is 0.18 ~ 0.32.

The server information is as following;

1. OS : CentOS 7.3

2. CPU : Intel Xeon3.5Ghz 64bits(6 CPUs, 2 cores per CPU)

3. Mem. : 8G

 

Would you please give me any information about it ?

I know a lot of fixes on “rndc reconfig” for latter version of 9.9.11-P1

 

Please take a look at the following logs from bind for your information;

=== general log =

24-Aug-2018 17:36:39.073 general: debug 1: received control channel command
'null'

24-Aug-2018 17:36:39.073 general: info: received control channel command
'reconfig'

24-Aug-2018 17:36:39.073 general: info: loading configuration from
'/etc/named.conf'

24-Aug-2018 17:36:39.159 general: info: unable to open
'conf/named.iscdlv.key' using built-in keys

24-Aug-2018 17:36:39.168 general: info: using default UDP/IPv4 port range:
[9000, 61000]

24-Aug-2018 17:36:39.169 general: info: using default UDP/IPv6 port range:
[9000, 61000]

24-Aug-2018 17:36:39.190 general: info: sizing zone task pool based on 4704
zones

24-Aug-2018 17:36:39.293 general: debug 1: zone_settimer: zone xn--
pi5bm5e/IN: enter

….(removed)…..

24-Aug-2018 17:36:41.809 general: debug 1: zone_settimer: zone xn--o78b/IN:
enter

24-Aug-2018 17:36:41.816 general: info: dns64 reverse zone: 0.0.0.0.0.0.0.0.
0.0.0.0.0.0.0.0.b.9.f.f.4.6.0.0.ip6.arpa.

….(removed)…..

24-Aug-2018 17:36:43.927 general: debug 1: now using logging configuration
from config file

24-Aug-2018 17:36:43.935 general: info: zone
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.9.f.f.4.6.0.0.ip6.arpa/IN: (master)
removed

24-Aug-2018 17:36:43.938 general: debug 1: load_configuration: success

24-Aug-2018 17:36:43.938 general: info: reloading configuration succeeded



 

It would be appreciated if you share any hints, information.

 

Regards,

Sunghwan.

 

--

(주)아이비아이(www.ibi.net)

DNS사업부/본부장

02-2165-7234/010-3558-3736

[03909]서울 마포구 매봉산로 37(상암동, DMC산학협력센터1304호)

 

___
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: rndc reconfig: Unexpected end of input

[Mark Andrews]

Check named.conf with named-checkconf.

> On 29 Aug 2018, at 4:34 am, J David  wrote:
> 
> After recently improving the tracking of errors coming from commands
> running from scripts, we found that a large number of “rndc reconfig”
> requests (about 15-20% of all requests) error out with exit status 1
> and the message:
> 
> rndc: ‘reconfig' failed: unexpected end of input
> 
> The “unexpected end of input” error is one that rndc usually issues if
> a parameter is missing.  For example, “rndc refresh” without providing
> a zone name on the command line.  But “rndc reconfig” doesn’t have any
> additional command line parameters.
> 
> In this case, the rndc reconfig is issued after adding a zone file to
> the configuration.
> 
> This is on BIND 9.12.2-P1 on FreeBSD 11.2, if that’s relevant.
> 
> Does anyone know what might be causing this error message?
> 
> Thanks for any advice!
> ___
> 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

rndc reconfig: Unexpected end of input

[J David]

After recently improving the tracking of errors coming from commands
running from scripts, we found that a large number of “rndc reconfig”
requests (about 15-20% of all requests) error out with exit status 1
and the message:

rndc: ‘reconfig' failed: unexpected end of input

The “unexpected end of input” error is one that rndc usually issues if
a parameter is missing.  For example, “rndc refresh” without providing
a zone name on the command line.  But “rndc reconfig” doesn’t have any
additional command line parameters.

In this case, the rndc reconfig is issued after adding a zone file to
the configuration.

This is on BIND 9.12.2-P1 on FreeBSD 11.2, if that’s relevant.

Does anyone know what might be causing this error message?

Thanks for any advice!
___
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

RNDC client protocol mode for NodeJS

[Ray Bellis]

For those of you that like Javascript, and like it server side, there's
now an implementation of the RNDC protocol available for NodeJS:

<https://www.npmjs.com/package/bind9-rndc>

We hope people may find this useful.

Please note that this is not officially supported ISC software.

Ray Bellis
ISC Research Fellow
___
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: questions about rndc zonestatus

[Tony Finch]

Klaus Darilion <klaus.mailingli...@pernau.at> wrote:
>
> Unfortunately the slave-status is not dumped, e.g. if the zone is n
> sync, if SOA refresh-checks suceed, if XFRs succeed?

I agree this is could be improved.

> Further, I would like to know if there are existing tools to parse the
> output, or if it is possible to get the data in a more structured form.

Hmm, I thought that should be available via the statistics channel, but
sadly not.

> Further it would be great to get a dump of all zones (e.g. without
> specifying the zone), or at least to get a dump of the configured zone
> of Bind.

This I can help with :-) and coincidentally I was playing around with it
yesterday. Last year I wrote about getting a list of zones from BIND's
json statistics channel: https://fanf.livejournal.com/146763.html

I find jq quite handy for wrangling json, but rather brain bending as a
programming language. The script I wrote in that articles was a bit
contorted. Yesterday I worked out a better version which is much more
linear:

$ curl -Ssf http://[::1]:8053/json |
  jq -S -r '.views |
to_entries |
map({ view: .key, zone: .value.zones[] }) |
.[] |
"\(.zone.name) \(.zone.class) \(.view) \(.zone.type)"'

There's also `named-checkconf -l` which lists the configured zones (and
was a feature submited by me!). It omits things like catalog zones and the
_bind view which are listed by the statistics channel, because it works on
the text of the configuration file. (I can't remember whether it includes
zones added by `rndc addzone` - I guess not.)

Tony.
-- 
f.anthony.n.finch  <d...@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Viking, North Utsire, South Utsire, Forties: Southerly or southwesterly,
veering northwesterly later, 5 or 6, decreasing 4 at times, occasionally 7
except in South Utsire. Moderate, occasionally rough in Viking and North
Utsire. Occasional rain, fog patches. 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

questions about rndc zonestatus

[Klaus Darilion]

Hi!

I would like to use this feature to check the status of my slave zones.

# rndc zonestatus nic.at
name: nic.at
type: slave
files: /etc/bind/zones/nic.at
serial: 2017121119
nodes: 77
next refresh: Tue, 19 Dec 2017 08:34:53 GMT
expires: Tue, 02 Jan 2018 07:50:08 GMT
secure: yes
inline signing: no
key maintenance: none
dynamic: no
reconfigurable via modzone: no

Unfortunately the slave-status is not dumped, e.g. if the zone is n
sync, if SOA refresh-checks suceed, if XFRs succeed? Do I miss
something? In the above example the configured masters is not available
and SOA-checks and XFR failed. Nevertheless there is no information
about the failing refresh checks for the zone.

Further, I would like to know if there are existing tools to parse the
output, or if it is possible to get the data in a more structured form.

Further it would be great to get a dump of all zones (e.g. without
specifying the zone), or at least to get a dump of the configured zone
of Bind.

thanks
Klaus


___
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

FYI: zones created using "rndc addzone" could temporarily fail to inherit option "allow-transfer"

[Michael McNally]

We recently received a bug report that newly-added zones (via rndc
addzone) were not inheriting the global allow-transfer directive
and could be transferred using AXFR by anyone able to access the
server to which they had just been added.

Further investigation revealed that the circumstances when this
might occur are very specific, transient, and unlikely to affect
most production environments.  However since we're now aware of
this defect we decided that it would be in the best interests of
our users to share this knowledge so that administrators can judge
whether or not they need to be concerned.

We assessed the effects of the defect and concluded that it does
not meet our policy criteria for handling as a security defect:
https://kb.isc.org/article/AA-00861/

It will be fixed in upcoming releases of BIND:
9.12.0, 9.11.3, 9.10.7, 9.9.11

4836.[bug]Zones created using "rndc addzone" could
   temporarily fail to inherit an "allow-transfer"
   ACL that had been configured in the options
   statement. [RT #46603]

BIND administrators need only take notice if they are dynamically
adding zones to views (including the default view) that are completely
empty of zones (no zones via named.conf, and no dynamic zones added
earlier) when named is started.

The effect of this bug is that when a zone is being added dynamically,
named fails to check for and initialize the view option 'allow-transfer'
if this had not already been done previously.  This would be unusual
in most production implementations because view initialization takes
place either when named starts up and loads its already-configured
zones, or when named processes 'rndc reload' or 'rndc reconfig'
control commands for non-empty views.

Additionally, if the dynamic zones are added with their own
zone-specific 'allow transfer' option, then this option will be
properly applied for that zone (but this does not mitigate the bug
for any other zones added without a zone-specific ACL).

In summary, this defect will only affect you if you:
 - Start named with no zones at all in some/all views
 - After named has started, add zones to empty views using 'rndc addzone'
 - Rely on dynamic zones inheriting the global or view-specific
   'allow-transfer' directive rather than specifying it for each zone
 - Don't afterwards issue 'rndc reconfig' or 'rndc reload', or restart named

One further consideration is whether or not it matters that the zones
are temporarily available for zone transfer.

ISC would like to thank Andrew Parnell at easyDNS and Dave Knight
at Snake Hill Labs for bringing this bug to our attention.

Sincerely,
ISC Support
___
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: rndc addzone type forward

[Evan Hunt]

> I'm trying to add zone of type "forward" with rndc addzone, but it fails with:

Unfortunately that's not currently possible. The configuration syntax is
misleading here. You configure forwarding in a view by putting a "zone"
statement in named.conf, but it doesn't actually build a zone *object*,
the way type "master" or "slave" does; it tells the server to set up a
different data structure entirely.  The addzone command is focused on zone
objects and doesn't know what to do with this.

(I thought I remembered documenting this limitation, but I don't see it in
the ARM; my apologies for that oversight.)

We've had a feature request in our queue for some time to make it possible
to configure forwarding via rndc. Hopefully in 9.12.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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: rndc addzone type forward

[Tony Finch]

Emil Natan <e...@foowatch.com> wrote:
>
> I also compiled BIND 9.11.0rc3, but nothing changed, no more verbosity,
> only the name of the .nzf file created changed from hash to plain text.

Try 9.11.0-P1 which has a few changes since rc3.

> Another finding is that the failure .nzf file is created, but it's empty
> and the next run of rndc addzone fails with "already exists".

Is the zone present in memory but not on disk, perhaps? Try something like:

$ curl -Ssf http://server:8053/json/v1/zones | grep name

Tony.
-- 
f.anthony.n.finch  <d...@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
South Biscay, South Fitzroy: Northeasterly 4 or 5 at times in Fitzroy,
otherwise variable 3 or 4, becoming westerly 5 or 6 in north. Slight or
moderate, becoming rough later in north. Rain or showers. Moderate or good.
___
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: rndc addzone type forward

[Emil Natan]

 Original Message 
Subject: Re: rndc addzone type forward
Local Time: November 16, 2016 5:50 PM
UTC Time: November 16, 2016 3:50 PM
From: e...@foowatch.com
To: bind-users@lists.isc.org <bind-users@lists.isc.org>








 Original Message 
Subject: Re: rndc addzone type forward
Local Time: November 16, 2016 5:12 PM
UTC Time: November 16, 2016 3:12 PM
From: d...@dotat.at
To: Emil Natan <e...@foowatch.com>
bind-users@lists.isc.org <bind-users@lists.isc.org>

Emil Natan <e...@foowatch.com> wrote:
>
> I'm trying to add zone of type "forward" with rndc addzone, but it fails with:
>
> rndc addzone zone.org '{type forward; forward only; forwarders { 
> 192.168.20.115; }; };'
> rndc: 'addzone' failed: not found

I think this happens if you are using a version before 9.11 (which has a
more verbose error) and you get the view name wrong. The view name can be
wrong if you have multiple views and you don't specify which one.

e.g. on a 9.10 server with views:

$ rndc addzone google '{ type forward; forward only; forwarders { 8.8.8.8; }; 
};'
rndc: 'addzone' failed: not found
$

And on a 9.11 server with views:

$ rndc addzone google '{ type forward; forward only; forwarders { 8.8.8.8; }; 
};'
rndc: 'addzone' failed: not found
no matching view found for '_default'
$

You can get a similar error if you specify an incorrect view:

$ rndc addzone google in error '{ type forward; forward only; forwarders { 
8.8.8.8; }; };'
rndc: 'addzone' failed: not found
no matching view found for 'error'
$

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/ - I xn--zr8h punycode
Shannon: West 6 to gale 8, perhaps severe gale 9 later. Rough or very rough,
becoming mainly high. Thundery showers. Good, occasionally poor.

Thank you for your response.
I'm not using and not specifying view, which is optional anyway. I also 
compiled BIND 9.11.0rc3, but nothing changed, no more verbosity, only the name 
of the .nzf file created changed from hash to plain text.
Another finding is that the failure .nzf file is created, but it's empty and 
the next run of rndc addzone fails with "already exists".

root@debugtzc:/usr/local/stow# find /chroot/named -name "*.nzf"
root@debugtzc:/usr/local/stow# rndc addzone google '{ type forward; forward 
only; forwarders { 8.8.8.8; }; };'
rndc: 'addzone' failed: not found
root@debugtzc:/usr/local/stow# find /chroot/named -name "*.nzf"
/chroot/named/var/named/_default.nzf
root@debugtzc:/usr/local/stow# rndc addzone google '{ type forward; forward 
only; forwarders { 8.8.8.8; }; };'
rndc: 'addzone' failed: already exists
configure_zone failed: already exists
ls -l /chroot/named/var/named/_default.nzf -rw-r--r-- 1 named named 0 Nov 16 
17:39 /chroot/named/var/named/_default.nzf

Emil

Update: despite the errors, the forwarding takes effect, checked with tcpdump.
But now I can't remove the forwarding zone:
After:
root@debugtzc:/usr/local/stow# rndc addzone google.com '{ type forward; forward 
only; forwarders { 8.8.4.4; }; };
'rndc: 'addzone' failed: not found

Here forwarding works:
18:04:36.703150 IP debugtzc.isoc.org.il.55531 > 8.8.4.4.domain: 20892+% [1au] 
A? google.com. (51)

But then:
root@debugtzc:/usr/local/stow# rndc delzone google.com
rndc: 'delzone' failed: not found
no matching zone 'google.com' in any view

And the queries for google.com are still forwarded to 8.8.4.4.

Emil___
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: rndc addzone type forward

[Emil Natan]

 Original Message 
Subject: Re: rndc addzone type forward
Local Time: November 16, 2016 5:12 PM
UTC Time: November 16, 2016 3:12 PM
From: d...@dotat.at
To: Emil Natan <e...@foowatch.com>
bind-users@lists.isc.org <bind-users@lists.isc.org>

Emil Natan <e...@foowatch.com> wrote:
>
> I'm trying to add zone of type "forward" with rndc addzone, but it fails with:
>
> rndc addzone zone.org '{type forward; forward only; forwarders { 
> 192.168.20.115; }; };'
> rndc: 'addzone' failed: not found

I think this happens if you are using a version before 9.11 (which has a
more verbose error) and you get the view name wrong. The view name can be
wrong if you have multiple views and you don't specify which one.

e.g. on a 9.10 server with views:

$ rndc addzone google '{ type forward; forward only; forwarders { 8.8.8.8; }; 
};'
rndc: 'addzone' failed: not found
$

And on a 9.11 server with views:

$ rndc addzone google '{ type forward; forward only; forwarders { 8.8.8.8; }; 
};'
rndc: 'addzone' failed: not found
no matching view found for '_default'
$

You can get a similar error if you specify an incorrect view:

$ rndc addzone google in error '{ type forward; forward only; forwarders { 
8.8.8.8; }; };'
rndc: 'addzone' failed: not found
no matching view found for 'error'
$

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/ - I xn--zr8h punycode
Shannon: West 6 to gale 8, perhaps severe gale 9 later. Rough or very rough,
becoming mainly high. Thundery showers. Good, occasionally poor.

Thank you for your response.
I'm not using and not specifying view, which is optional anyway. I also 
compiled BIND 9.11.0rc3, but nothing changed, no more verbosity, only the name 
of the .nzf file created changed from hash to plain text.
Another finding is that the failure .nzf file is created, but it's empty and 
the next run of rndc addzone fails with "already exists".

root@debugtzc:/usr/local/stow# find /chroot/named -name "*.nzf"
root@debugtzc:/usr/local/stow# rndc addzone google '{ type forward; forward 
only; forwarders { 8.8.8.8; }; };'
rndc: 'addzone' failed: not found
root@debugtzc:/usr/local/stow# find /chroot/named -name "*.nzf"
/chroot/named/var/named/_default.nzf
root@debugtzc:/usr/local/stow# rndc addzone google '{ type forward; forward 
only; forwarders { 8.8.8.8; }; };'
rndc: 'addzone' failed: already exists
configure_zone failed: already exists
ls -l /chroot/named/var/named/_default.nzf -rw-r--r-- 1 named named 0 Nov 16 
17:39 /chroot/named/var/named/_default.nzf

Emil___
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: rndc addzone type forward

[Tony Finch]

Emil Natan <e...@foowatch.com> wrote:
>
> I'm trying to add zone of type "forward" with rndc addzone, but it fails with:
>
> rndc addzone zone.org '{type forward; forward only; forwarders { 
> 192.168.20.115; }; };'
> rndc: 'addzone' failed: not found

I think this happens if you are using a version before 9.11 (which has a
more verbose error) and you get the view name wrong. The view name can be
wrong if you have multiple views and you don't specify which one.

e.g. on a 9.10 server with views:

$ rndc addzone google '{ type forward; forward only; forwarders { 8.8.8.8; }; 
};'
rndc: 'addzone' failed: not found
$

And on a 9.11 server with views:

$ rndc addzone google '{ type forward; forward only; forwarders { 8.8.8.8; }; 
};'
rndc: 'addzone' failed: not found
no matching view found for '_default'
$

You can get a similar error if you specify an incorrect view:

$ rndc addzone google in error '{ type forward; forward only; forwarders { 
8.8.8.8; }; };'
rndc: 'addzone' failed: not found
no matching view found for 'error'
$

Tony.
-- 
f.anthony.n.finch  <d...@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Shannon: West 6 to gale 8, perhaps severe gale 9 later. Rough or very rough,
becoming mainly high. Thundery 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

rndc addzone type forward

[Emil Natan]

Hello,

I'm trying to add zone of type "forward" with rndc addzone, but it fails with:


rndc addzone zone.org '{type forward; forward only; forwarders { 
192.168.20.115; }; };'
rndc: 'addzone' failed: not found

I have allow-new-zones set to yes in named.conf. Loading zones of type master 
works fine. All I see in the logs is:
Nov 16 16:12:33 debugtzs named[1018]: general: info: received control channel 
command 'addzone'

Am I missing something?

Emil___
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: rndc on local host: need named running?

[Tom Browder]

On Tuesday, August 30, 2016, Woodworth, John R <
john.woodwo...@centurylink.com> wrote:
>
> I have a slightly unorthodox view on this which may even offer a bit more
>
> security.  The answers are listed below inline.
>
>  ...

Thanks, John.

Best regards,

-Tom
___
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: rndc on local host: need named running?

[Tom Browder]

On Tuesday, August 30, 2016, Cathy Almond  wrote:

> On 28/08/2016 02:48, Lyle wrote:
> > Use any in the allow stanza.
>
> You'll be using a shared key for this to work anyway, but I'd suggest
> being slightly more paranoid than 'any' in the allow stanza - perhaps
> the address range in which your local machine is to be allocated its
> address?
>

Thanks, Cathy.

Best regards

-Tom
___
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: rndc on local host: need named running?

[Woodworth, John R]

> My plan is to have two remote, authoritative name servers
> (master and slave) for my owned domains.  I would like to use rndc
> to control them from my local host.
>
> A couple of questions:

Tom,

I have a slightly unorthodox view on this which may even offer a bit more
security.  The answers are listed below inline.

>
> 1. Does named need to be running on the local host?

No, in fact you don't even need rndc installed locally or a
machine necessarily capable of running rndc.

You can invoke rndc via ssh using ssh keys and best of all the rndc
control port does not need to be exposed to the world.

An example use would be:
  #> ssh user@secrethost rndc reconfig

Which would invoke the 'rndc reconfig' command remotely.

A point of note would be the rndc *version* would also always be
in perfect synchronization with the local version of the server
further lowering the overall LOE (maintenance) for the remote client.


>
> 2. Can I use rndc from my local host which doesn't have a fixed
> ip address?


With this configuration it would not matter the source IP (apart from
ssh configuration).  I would also highly recommend some type of
"role account" to further increase security and minimize risk of
unintentionally allowing elevated privileges.

Most of all, as with any security tool if you are not at least familiar
with ssh and any risks associated, please step cautiously and minimally
familiarize yourself with it or avoid it.  Better safe than sorry.


Regards,
John


>
> Thanks.
>
> Best regards,
>
> -Tom
>

-- THESE ARE THE DROIDS TO WHOM I REFER:

This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.
___
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: rndc on local host: need named running?

[Cathy Almond]

On 28/08/2016 02:48, Lyle wrote:
> Use any in the allow stanza.

You'll be using a shared key for this to work anyway, but I'd suggest
being slightly more paranoid than 'any' in the allow stanza - perhaps
the address range in which your local machine is to be allocated its
address?

___
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: rndc on local host: need named running?

[Lyle]

Use any in the allow stanza.


On 08/27/16 19:54, Tom Browder wrote:
On Saturday, August 27, 2016, Lyle <l...@lcrcomputer.net 
<mailto:l...@lcrcomputer.net>> wrote:


On 08/27/16 10:54, Tom Browder wrote:

https://calomel.org/dynamic_dns_ddns.htmlMy plan is to have two
2. Can I use rndc from my local host which doesn't have a fixed
ip address?


...

Let me Google that for you and the answer is:

https://www.safaribooksonline.com/library/view/dns-bind/0596004109/ch03s04.html

<https://www.safaribooksonline.com/library/view/dns-bind/0596004109/ch03s04.html>


Thanks, Lyle. I've seen that, I have the book. But it's not real clear 
to a novice that it works without the remote host knowing the incoming 
ip address.




But I have enough info now to risk putting my name servers on line 
without fear of destroying the dns system of the internet!


Best regards,

-Tom



___
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: rndc on local host: need named running?

[Tom Browder]

On Saturday, August 27, 2016, Lyle <l...@lcrcomputer.net> wrote:

> On 08/27/16 10:54, Tom Browder wrote:
>
> https://calomel.org/dynamic_dns_ddns.htmlMy plan is to have two
>
> 2. Can I use rndc from my local host which doesn't have a fixed ip address?
>
> ...

> Let me Google that for you and the answer is:
> https://www.safaribooksonline.com/library/view/dns-bind/
> 0596004109/ch03s04.html
>

Thanks, Lyle. I've seen that, I have the book. But it's not real clear to a
novice that it works without the remote host knowing the incoming ip
address.

But I have enough info now to risk putting my name servers on line without
fear of destroying the dns system of the internet!

Best regards,

-Tom
___
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: rndc on local host: need named running?

[Lyle]

On 08/27/16 10:54, Tom Browder wrote:
My plan is to have two remote, authoritative name servers (master and 
slave) for my owned domains.  I would like to use rndc to control them 
from my local host.


A couple of questions:

1. Does named need to be running on the local host?

No.


2. Can I use rndc from my local host which doesn't have a fixed ip 
address?


Let me Google that for you and the answer is:

https://www.safaribooksonline.com/library/view/dns-bind/0596004109/ch03s04.html


Thanks.

Best regards,

-Tom


___
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: rndc on local host: need named running?

[Tom Browder]

On Saturday, August 27, 2016, Warren Kumari <war...@kumari.net> wrote:

> On Saturday, August 27, 2016, Tom Browder <tom.brow...@gmail.com
> <javascript:_e(%7B%7D,'cvml','tom.brow...@gmail.com');>> wrote:
>
>> My plan is to have two remote, authoritative name servers (master and
>> slave) for my owned domains.  I would like to use rndc to control them from
>> my local host.
>> A couple of questions:
>>
>  ...

Thanks, Warren!

Best regards,

-Tom
___
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: rndc on local host: need named running?

[Warren Kumari]

On Saturday, August 27, 2016, Tom Browder <tom.brow...@gmail.com> wrote:

> My plan is to have two remote, authoritative name servers (master and
> slave) for my owned domains.  I would like to use rndc to control them from
> my local host.
>
> A couple of questions:
>
> 1. Does named need to be running on the local host?
>


 Nope.



> 2. Can I use rndc from my local host which doesn't have a fixed ip address?
>
>
Yup.

W


> Thanks.
>
> Best regards,
>
> -Tom
>


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

rndc on local host: need named running?

[Tom Browder]

My plan is to have two remote, authoritative name servers (master and
slave) for my owned domains.  I would like to use rndc to control them from
my local host.

A couple of questions:

1. Does named need to be running on the local host?

2. Can I use rndc from my local host which doesn't have a fixed ip address?

Thanks.

Best regards,

-Tom
___
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: Identify source of rndc reconfig command?

[Robert Senger]

Thank you all for your help! I found that the reconfig command was
called by a script executed by wide-dhcpv6-client. In wheezy, this
script was called once when the ipv6 address of the public ppp interface
changed, in Jessie it was called every 30 minutes for whatever reason.
Fixed that.

Cheers,

Robert

Am Montag, den 24.08.2015, 23:01 +0200 schrieb Robert Senger:
 Hi all,
 
 after upgrading from Debian Wheezy to Jessie, bind9 receives rndc
 reconfig commands every 30 minutes. I've never seen this before. Some
 of my own scripts run rndc restart/reload after fiddling with network
 interfaces, but none of these is the source of the observed 30 minutes
 interval. There are also no cron jobs.
 
 In the bind9 logs I see this:
 
 24-Aug-2015 22:53:43.431 general: info: received control channel command 
 'reconfig'
 24-Aug-2015 22:53:43.458 general: info: loading configuration from 
 '/etc/bind/named.conf'
 ... [more than 350 lines reconfig log]
 
 Running tcpdump on the lo interface gives me this:
 
 root@prokyon:/etc/bind# tcpdump -i lo port 953
 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
 listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
 21:23:35.071602 IP localhost.48466  localhost.953: Flags [S], seq 
 3862717043, win 43690, options [mss 65495,sackOK,TS val 196635776 ecr 
 0,nop,wscale 5], length 0
 21:23:35.071699 IP localhost.953  localhost.48466: Flags [S.], seq 
 2391140312, ack 3862717044, win 43690, options [mss 65495,sackOK,TS val 
 196635776 ecr 196635776,nop,wscale 5], length 0
 21:23:35.071821 IP localhost.48466  localhost.953: Flags [.], ack 1, win 
 1366, options [nop,nop,TS val 196635776 ecr 196635776], length 0
 21:23:35.075355 IP localhost.48466  localhost.953: Flags [P.], seq 1:148, 
 ack 1, win 1366, options [nop,nop,TS val 196635777 ecr 196635776], length 147
 21:23:35.075435 IP localhost.953  localhost.48466: Flags [.], ack 148, win 
 1399, options [nop,nop,TS val 196635777 ecr 196635777], length 0
 21:23:35.115513 IP localhost.953  localhost.48466: Flags [P.], seq 1:180, 
 ack 148, win 1399, options [nop,nop,TS val 196635787 ecr 196635777], length 
 179
 21:23:35.115583 IP localhost.48466  localhost.953: Flags [.], ack 180, win 
 1399, options [nop,nop,TS val 196635787 ecr 196635787], length 0
 21:23:35.116084 IP localhost.48466  localhost.953: Flags [P.], seq 148:320, 
 ack 180, win 1399, options [nop,nop,TS val 196635787 ecr 196635787], length 
 172
 21:23:35.116130 IP localhost.953  localhost.48466: Flags [.], ack 320, win 
 1433, options [nop,nop,TS val 196635787 ecr 196635787], length 0
 21:23:37.092444 IP localhost.953  localhost.48466: Flags [P.], seq 180:363, 
 ack 320, win 1433, options [nop,nop,TS val 196636281 ecr 196635787], length 
 183
 21:23:37.094097 IP localhost.48466  localhost.953: Flags [F.], seq 320, ack 
 363, win 1433, options [nop,nop,TS val 196636281 ecr 196636281], length 0
 21:23:37.130367 IP localhost.953  localhost.48466: Flags [.], ack 321, win 
 1433, options [nop,nop,TS val 196636291 ecr 196636281], length 0
 21:23:37.829134 IP localhost.953  localhost.48466: Flags [F.], seq 363, ack 
 321, win 1433, options [nop,nop,TS val 196636465 ecr 196636281], length 0
 21:23:37.829288 IP localhost.48466  localhost.953: Flags [.], ack 364, win 
 1433, options [nop,nop,TS val 196636465 ecr 196636465], length 0
 
 Is there a way to identify the source of these reconfig commands? It's
 really annoying as it messes up the log with 350 useless lines every 30
 minutes.
 
 Thanks!
 
 Robert
  
 

-- 
Robert Senger


___
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: Identify source of rndc reconfig command?

[Konstantin Stefanov]

Hi, Robert.

As I understand, something is calling rndc on your localhost. So you may
try (untested by me):

Find rndc binary,

mv rndc rndc.ORIG

Replace rndc with script which will execute something like
ps fax  /tmp/rndc.log
then exec rndc.ORIG with the same arguments.

Then you will see who invoked your rndc.
Don't forget to use full path to rndc.ORIG, as you will never know which
current directory will be when your rndc replacement will be executed
and what the value of PATH will be.

On 25.08.2015 0:01, Robert Senger wrote:
 Hi all,
 
 after upgrading from Debian Wheezy to Jessie, bind9 receives rndc
 reconfig commands every 30 minutes. I've never seen this before. Some
 of my own scripts run rndc restart/reload after fiddling with network
 interfaces, but none of these is the source of the observed 30 minutes
 interval. There are also no cron jobs.
 
 In the bind9 logs I see this:
 
 24-Aug-2015 22:53:43.431 general: info: received control channel command 
 'reconfig'
 24-Aug-2015 22:53:43.458 general: info: loading configuration from 
 '/etc/bind/named.conf'
 ... [more than 350 lines reconfig log]
 
 Running tcpdump on the lo interface gives me this:
 
 root@prokyon:/etc/bind# tcpdump -i lo port 953
 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
 listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
 21:23:35.071602 IP localhost.48466  localhost.953: Flags [S], seq 
 3862717043, win 43690, options [mss 65495,sackOK,TS val 196635776 ecr 
 0,nop,wscale 5], length 0
 21:23:35.071699 IP localhost.953  localhost.48466: Flags [S.], seq 
 2391140312, ack 3862717044, win 43690, options [mss 65495,sackOK,TS val 
 196635776 ecr 196635776,nop,wscale 5], length 0
 21:23:35.071821 IP localhost.48466  localhost.953: Flags [.], ack 1, win 
 1366, options [nop,nop,TS val 196635776 ecr 196635776], length 0
 21:23:35.075355 IP localhost.48466  localhost.953: Flags [P.], seq 1:148, 
 ack 1, win 1366, options [nop,nop,TS val 196635777 ecr 196635776], length 147
 21:23:35.075435 IP localhost.953  localhost.48466: Flags [.], ack 148, win 
 1399, options [nop,nop,TS val 196635777 ecr 196635777], length 0
 21:23:35.115513 IP localhost.953  localhost.48466: Flags [P.], seq 1:180, 
 ack 148, win 1399, options [nop,nop,TS val 196635787 ecr 196635777], length 
 179
 21:23:35.115583 IP localhost.48466  localhost.953: Flags [.], ack 180, win 
 1399, options [nop,nop,TS val 196635787 ecr 196635787], length 0
 21:23:35.116084 IP localhost.48466  localhost.953: Flags [P.], seq 148:320, 
 ack 180, win 1399, options [nop,nop,TS val 196635787 ecr 196635787], length 
 172
 21:23:35.116130 IP localhost.953  localhost.48466: Flags [.], ack 320, win 
 1433, options [nop,nop,TS val 196635787 ecr 196635787], length 0
 21:23:37.092444 IP localhost.953  localhost.48466: Flags [P.], seq 180:363, 
 ack 320, win 1433, options [nop,nop,TS val 196636281 ecr 196635787], length 
 183
 21:23:37.094097 IP localhost.48466  localhost.953: Flags [F.], seq 320, ack 
 363, win 1433, options [nop,nop,TS val 196636281 ecr 196636281], length 0
 21:23:37.130367 IP localhost.953  localhost.48466: Flags [.], ack 321, win 
 1433, options [nop,nop,TS val 196636291 ecr 196636281], length 0
 21:23:37.829134 IP localhost.953  localhost.48466: Flags [F.], seq 363, ack 
 321, win 1433, options [nop,nop,TS val 196636465 ecr 196636281], length 0
 21:23:37.829288 IP localhost.48466  localhost.953: Flags [.], ack 364, win 
 1433, options [nop,nop,TS val 196636465 ecr 196636465], length 0
 
 Is there a way to identify the source of these reconfig commands? It's
 really annoying as it messes up the log with 350 useless lines every 30
 minutes.
 
 Thanks!
 
 Robert
  
 

-- 
Konstantin Stefanov,

Research Computing Center
M.V Lomonosov Moscow State University
___
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: Identify source of rndc reconfig command?

[Tony Finch]

Robert Senger robert.sen...@lists.microscopium.de wrote:

 Is there a way to identify the source of these reconfig commands?

Turn on process accounting by installing the acct package. Run `dump-acct
/var/log/account/pacct` and look for the rndc entries. The pid and ppid
fields should allow you to trace backwards to work out what invoked rndc.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or
moderate, but rough in southwest Viking. Showers later. Good, occasionally
poor later.
___
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: Re: Identify source of rndc reconfig command?

[Timothe Litt]

Robert,

While all the advice provided is good, you might also send a suggestion
to bind9-bugs.

The received control channel command message  would be more useful if
it included the peer address  port e.g.:
   ... general: info: received control channel command 'reconfig' from
127.0.0.1:48466 .

That would avoid having to use tcpdump to identify the source of these
sorts of problems.

Other thoughts:

If you have selinux enabled, you can (temporarily) deny access to port
953 with a local policy module, and use the resulting audit log entries
to determine the command.  To avoid service disruption, use setenforce 0
(permissive) for the duration.  This is the simplest approach (fewest
tools, quickest  most certain results).  But you do need to know how to
setup a LPM... and if you're not running selinux already, it can be a
hassle to setup.  (I recommend doing it, but not in the middle of this
fire.)

Every 30 mins sounds like some sort of monitor.  Check that named.conf
isn't changing (which could trigger such a monitor.)  Or stop all system
management/monitoring packages until you find the culprit.

Consider  inotify-tools.  If a monitor is keeping an eye on bind, you
can catch it looking at (or touching) named's files.

lsof is a bit heavyweight for this.  Consider ss -p (ss is part of
iproute2) if you have it.

A final thought - look for log file managers (e.g. logrotate).  They may
be noticing named's file size  doing a reconfig to close/reopen the log
file.   (In which case, report a bug in the log manager's config -
named's own log file management avoids all those hassles.)

Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 

On 24-Aug-15 17:55, Mark Andrews wrote:
 The first thing I would do is make sure only the users you want to
 be able to use the rndc key can read it.  I would then generate a
 new rndc key and configure both rndc and named to use it.

 If that doesn't work generate a new rndc.conf file with a different
 name that refers to a new rndc key.  Teach named to use that key
 then update all the scripts that you know about to use the new
 rndc.conf file.

rndc -c rndc.conf.path

 Mark

 In message 60946bf48ada4e6fb2ed7b0aa297d...@mxph4chrw.fgremc.it, Darcy 
 Kevin
  (FCA) writes:
 Does the rndc protocol have a timeout? If so, what is it set to? I don't see 
 anything about a configurable timeout interval in the man pages for rndc or r
 ndc.conf.

 What I'd probably do is turn off rndc in named.conf, set up a dummy server 
 to listen on port 953, which just accepts the connection, but doesn't respond
  to anything sent to it. That means that whatever is sending this command is 
 going to be stuck for some period of time -- possibly infinitely -- waiting
  for a response from the server. Then you can use something like lsof (whic
 h I assume exists in Debian) to track down which process it is.

  - Kevin

 -Original Message-
 From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.o
 rg] On Behalf Of Robert Senger
 Sent: Monday, August 24, 2015 5:02 PM
 To: bind-users@lists.isc.org
 Subject: Identify source of rndc reconfig command?

 Hi all,

 after upgrading from Debian Wheezy to Jessie, bind9 receives rndc reconfig 
 commands every 30 minutes. I've never seen this before. Some of my own script
 s run rndc restart/reload after fiddling with network interfaces, but none 
 of these is the source of the observed 30 minutes interval. There are also no
  cron jobs.

 In the bind9 logs I see this:

 24-Aug-2015 22:53:43.431 general: info: received control channel command 'rec
 onfig'
 24-Aug-2015 22:53:43.458 general: info: loading configuration from '/etc/bind
 /named.conf'
 ... [more than 350 lines reconfig log]

 Running tcpdump on the lo interface gives me this:

 root@prokyon:/etc/bind# tcpdump -i lo port 953
 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode li
 stening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
 21:23:35.071602 IP localhost.48466  localhost.953: Flags [S], seq 3862717043
 , win 43690, options [mss 65495,sackOK,TS val 196635776 ecr 0,nop,wscale 5], 
 length 0
 21:23:35.071699 IP localhost.953  localhost.48466: Flags [S.], seq 239114031
 2, ack 3862717044, win 43690, options [mss 65495,sackOK,TS val 196635776 ecr 
 196635776,nop,wscale 5], length 0
 21:23:35.071821 IP localhost.48466  localhost.953: Flags [.], ack 1, win 136
 6, options [nop,nop,TS val 196635776 ecr 196635776], length 0
 21:23:35.075355 IP localhost.48466  localhost.953: Flags [P.], seq 1:148, ac
 k 1, win 1366, options [nop,nop,TS val 196635777 ecr 196635776], length 147
 21:23:35.075435 IP localhost.953  localhost.48466: Flags [.], ack 148, win 1
 399, options [nop,nop,TS val 196635777 ecr 196635777], length 0
 21:23:35.115513 IP localhost

Identify source of rndc reconfig command?

[Robert Senger]

Hi all,

after upgrading from Debian Wheezy to Jessie, bind9 receives rndc
reconfig commands every 30 minutes. I've never seen this before. Some
of my own scripts run rndc restart/reload after fiddling with network
interfaces, but none of these is the source of the observed 30 minutes
interval. There are also no cron jobs.

In the bind9 logs I see this:

24-Aug-2015 22:53:43.431 general: info: received control channel command 
'reconfig'
24-Aug-2015 22:53:43.458 general: info: loading configuration from 
'/etc/bind/named.conf'
... [more than 350 lines reconfig log]

Running tcpdump on the lo interface gives me this:

root@prokyon:/etc/bind# tcpdump -i lo port 953
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
21:23:35.071602 IP localhost.48466  localhost.953: Flags [S], seq 3862717043, 
win 43690, options [mss 65495,sackOK,TS val 196635776 ecr 0,nop,wscale 5], 
length 0
21:23:35.071699 IP localhost.953  localhost.48466: Flags [S.], seq 2391140312, 
ack 3862717044, win 43690, options [mss 65495,sackOK,TS val 196635776 ecr 
196635776,nop,wscale 5], length 0
21:23:35.071821 IP localhost.48466  localhost.953: Flags [.], ack 1, win 1366, 
options [nop,nop,TS val 196635776 ecr 196635776], length 0
21:23:35.075355 IP localhost.48466  localhost.953: Flags [P.], seq 1:148, ack 
1, win 1366, options [nop,nop,TS val 196635777 ecr 196635776], length 147
21:23:35.075435 IP localhost.953  localhost.48466: Flags [.], ack 148, win 
1399, options [nop,nop,TS val 196635777 ecr 196635777], length 0
21:23:35.115513 IP localhost.953  localhost.48466: Flags [P.], seq 1:180, ack 
148, win 1399, options [nop,nop,TS val 196635787 ecr 196635777], length 179
21:23:35.115583 IP localhost.48466  localhost.953: Flags [.], ack 180, win 
1399, options [nop,nop,TS val 196635787 ecr 196635787], length 0
21:23:35.116084 IP localhost.48466  localhost.953: Flags [P.], seq 148:320, 
ack 180, win 1399, options [nop,nop,TS val 196635787 ecr 196635787], length 172
21:23:35.116130 IP localhost.953  localhost.48466: Flags [.], ack 320, win 
1433, options [nop,nop,TS val 196635787 ecr 196635787], length 0
21:23:37.092444 IP localhost.953  localhost.48466: Flags [P.], seq 180:363, 
ack 320, win 1433, options [nop,nop,TS val 196636281 ecr 196635787], length 183
21:23:37.094097 IP localhost.48466  localhost.953: Flags [F.], seq 320, ack 
363, win 1433, options [nop,nop,TS val 196636281 ecr 196636281], length 0
21:23:37.130367 IP localhost.953  localhost.48466: Flags [.], ack 321, win 
1433, options [nop,nop,TS val 196636291 ecr 196636281], length 0
21:23:37.829134 IP localhost.953  localhost.48466: Flags [F.], seq 363, ack 
321, win 1433, options [nop,nop,TS val 196636465 ecr 196636281], length 0
21:23:37.829288 IP localhost.48466  localhost.953: Flags [.], ack 364, win 
1433, options [nop,nop,TS val 196636465 ecr 196636465], length 0

Is there a way to identify the source of these reconfig commands? It's
really annoying as it messes up the log with 350 useless lines every 30
minutes.

Thanks!

Robert
 

-- 
Robert Senger


___
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: Identify source of rndc reconfig command?

[Darcy Kevin (FCA)]

Does the rndc protocol have a timeout? If so, what is it set to? I don't see 
anything about a configurable timeout interval in the man pages for rndc or 
rndc.conf.

What I'd probably do is turn off rndc in named.conf, set up a dummy server to 
listen on port 953, which just accepts the connection, but doesn't respond to 
anything sent to it. That means that whatever is sending this command is going 
to be stuck for some period of time -- possibly infinitely -- waiting for a 
response from the server. Then you can use something like lsof (which I 
assume exists in Debian) to track down which process it is.

- Kevin

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Robert Senger
Sent: Monday, August 24, 2015 5:02 PM
To: bind-users@lists.isc.org
Subject: Identify source of rndc reconfig command?

Hi all,

after upgrading from Debian Wheezy to Jessie, bind9 receives rndc reconfig 
commands every 30 minutes. I've never seen this before. Some of my own scripts 
run rndc restart/reload after fiddling with network interfaces, but none of 
these is the source of the observed 30 minutes interval. There are also no cron 
jobs.

In the bind9 logs I see this:

24-Aug-2015 22:53:43.431 general: info: received control channel command 
'reconfig'
24-Aug-2015 22:53:43.458 general: info: loading configuration from 
'/etc/bind/named.conf'
... [more than 350 lines reconfig log]

Running tcpdump on the lo interface gives me this:

root@prokyon:/etc/bind# tcpdump -i lo port 953
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode 
listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
21:23:35.071602 IP localhost.48466  localhost.953: Flags [S], seq 3862717043, 
win 43690, options [mss 65495,sackOK,TS val 196635776 ecr 0,nop,wscale 5], 
length 0
21:23:35.071699 IP localhost.953  localhost.48466: Flags [S.], seq 2391140312, 
ack 3862717044, win 43690, options [mss 65495,sackOK,TS val 196635776 ecr 
196635776,nop,wscale 5], length 0
21:23:35.071821 IP localhost.48466  localhost.953: Flags [.], ack 1, win 1366, 
options [nop,nop,TS val 196635776 ecr 196635776], length 0
21:23:35.075355 IP localhost.48466  localhost.953: Flags [P.], seq 1:148, ack 
1, win 1366, options [nop,nop,TS val 196635777 ecr 196635776], length 147
21:23:35.075435 IP localhost.953  localhost.48466: Flags [.], ack 148, win 
1399, options [nop,nop,TS val 196635777 ecr 196635777], length 0
21:23:35.115513 IP localhost.953  localhost.48466: Flags [P.], seq 1:180, ack 
148, win 1399, options [nop,nop,TS val 196635787 ecr 196635777], length 179
21:23:35.115583 IP localhost.48466  localhost.953: Flags [.], ack 180, win 
1399, options [nop,nop,TS val 196635787 ecr 196635787], length 0
21:23:35.116084 IP localhost.48466  localhost.953: Flags [P.], seq 148:320, 
ack 180, win 1399, options [nop,nop,TS val 196635787 ecr 196635787], length 172
21:23:35.116130 IP localhost.953  localhost.48466: Flags [.], ack 320, win 
1433, options [nop,nop,TS val 196635787 ecr 196635787], length 0
21:23:37.092444 IP localhost.953  localhost.48466: Flags [P.], seq 180:363, 
ack 320, win 1433, options [nop,nop,TS val 196636281 ecr 196635787], length 183
21:23:37.094097 IP localhost.48466  localhost.953: Flags [F.], seq 320, ack 
363, win 1433, options [nop,nop,TS val 196636281 ecr 196636281], length 0
21:23:37.130367 IP localhost.953  localhost.48466: Flags [.], ack 321, win 
1433, options [nop,nop,TS val 196636291 ecr 196636281], length 0
21:23:37.829134 IP localhost.953  localhost.48466: Flags [F.], seq 363, ack 
321, win 1433, options [nop,nop,TS val 196636465 ecr 196636281], length 0
21:23:37.829288 IP localhost.48466  localhost.953: Flags [.], ack 364, win 
1433, options [nop,nop,TS val 196636465 ecr 196636465], length 0

Is there a way to identify the source of these reconfig commands? It's really 
annoying as it messes up the log with 350 useless lines every 30 minutes.

Thanks!

Robert
 

--
Robert Senger


___
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: Identify source of rndc reconfig command?

[Mark Andrews]

The first thing I would do is make sure only the users you want to
be able to use the rndc key can read it.  I would then generate a
new rndc key and configure both rndc and named to use it.

If that doesn't work generate a new rndc.conf file with a different
name that refers to a new rndc key.  Teach named to use that key
then update all the scripts that you know about to use the new
rndc.conf file.

 rndc -c rndc.conf.path

Mark

In message 60946bf48ada4e6fb2ed7b0aa297d...@mxph4chrw.fgremc.it, Darcy Kevin
 (FCA) writes:
 Does the rndc protocol have a timeout? If so, what is it set to? I don't see 
 anything about a configurable timeout interval in the man pages for rndc or r
 ndc.conf.
 
 What I'd probably do is turn off rndc in named.conf, set up a dummy server 
 to listen on port 953, which just accepts the connection, but doesn't respond
  to anything sent to it. That means that whatever is sending this command is 
 going to be stuck for some period of time -- possibly infinitely -- waiting
  for a response from the server. Then you can use something like lsof (whic
 h I assume exists in Debian) to track down which process it is.
 
   - Kevin
 
 -Original Message-
 From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.o
 rg] On Behalf Of Robert Senger
 Sent: Monday, August 24, 2015 5:02 PM
 To: bind-users@lists.isc.org
 Subject: Identify source of rndc reconfig command?
 
 Hi all,
 
 after upgrading from Debian Wheezy to Jessie, bind9 receives rndc reconfig 
 commands every 30 minutes. I've never seen this before. Some of my own script
 s run rndc restart/reload after fiddling with network interfaces, but none 
 of these is the source of the observed 30 minutes interval. There are also no
  cron jobs.
 
 In the bind9 logs I see this:
 
 24-Aug-2015 22:53:43.431 general: info: received control channel command 'rec
 onfig'
 24-Aug-2015 22:53:43.458 general: info: loading configuration from '/etc/bind
 /named.conf'
 ... [more than 350 lines reconfig log]
 
 Running tcpdump on the lo interface gives me this:
 
 root@prokyon:/etc/bind# tcpdump -i lo port 953
 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode li
 stening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
 21:23:35.071602 IP localhost.48466  localhost.953: Flags [S], seq 3862717043
 , win 43690, options [mss 65495,sackOK,TS val 196635776 ecr 0,nop,wscale 5], 
 length 0
 21:23:35.071699 IP localhost.953  localhost.48466: Flags [S.], seq 239114031
 2, ack 3862717044, win 43690, options [mss 65495,sackOK,TS val 196635776 ecr 
 196635776,nop,wscale 5], length 0
 21:23:35.071821 IP localhost.48466  localhost.953: Flags [.], ack 1, win 136
 6, options [nop,nop,TS val 196635776 ecr 196635776], length 0
 21:23:35.075355 IP localhost.48466  localhost.953: Flags [P.], seq 1:148, ac
 k 1, win 1366, options [nop,nop,TS val 196635777 ecr 196635776], length 147
 21:23:35.075435 IP localhost.953  localhost.48466: Flags [.], ack 148, win 1
 399, options [nop,nop,TS val 196635777 ecr 196635777], length 0
 21:23:35.115513 IP localhost.953  localhost.48466: Flags [P.], seq 1:180, ac
 k 148, win 1399, options [nop,nop,TS val 196635787 ecr 196635777], length 179
 21:23:35.115583 IP localhost.48466  localhost.953: Flags [.], ack 180, win 1
 399, options [nop,nop,TS val 196635787 ecr 196635787], length 0
 21:23:35.116084 IP localhost.48466  localhost.953: Flags [P.], seq 148:320, 
 ack 180, win 1399, options [nop,nop,TS val 196635787 ecr 196635787], length 1
 72
 21:23:35.116130 IP localhost.953  localhost.48466: Flags [.], ack 320, win 1
 433, options [nop,nop,TS val 196635787 ecr 196635787], length 0
 21:23:37.092444 IP localhost.953  localhost.48466: Flags [P.], seq 180:363, 
 ack 320, win 1433, options [nop,nop,TS val 196636281 ecr 196635787], length 1
 83
 21:23:37.094097 IP localhost.48466  localhost.953: Flags [F.], seq 320, ack 
 363, win 1433, options [nop,nop,TS val 196636281 ecr 196636281], length 0
 21:23:37.130367 IP localhost.953  localhost.48466: Flags [.], ack 321, win 1
 433, options [nop,nop,TS val 196636291 ecr 196636281], length 0
 21:23:37.829134 IP localhost.953  localhost.48466: Flags [F.], seq 363, ack 
 321, win 1433, options [nop,nop,TS val 196636465 ecr 196636281], length 0
 21:23:37.829288 IP localhost.48466  localhost.953: Flags [.], ack 364, win 1
 433, options [nop,nop,TS val 196636465 ecr 196636465], length 0
 
 Is there a way to identify the source of these reconfig commands? It's really
  annoying as it messes up the log with 350 useless lines every 30 minutes.
 
 Thanks!
 
 Robert
  
 
 --
 Robert Senger
 
 
 ___
 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

rndc status field meaning please

[이윤호]

hello 
 
how are you today?  haha
 
i'm  bind user 
 
rndc status field mean about request
 
 
CPUs found: 4
​ physical cpu ? 
worker threads: 4
physical cpu in core?
UDP listeners per interface: 2
very diffcult  nic port intercafe? 
one interface = udp :1 ? 
number of zones: 16
/etc/named.conf  zone field number 
i'm understand
debug level: 0
log detail debug level 
i'm ok
xfers running: 0
zone transfer 
i'm ok
xfers deferred: 0
zone transfer slow time out?
i'm confused
soa queries in progress: 0
what is field mean?
query logging is ON
logging queries.log 
i'm ok
recursive clients: 0/9900/1
recursivw query 
tcp clients: 0/100
tcp query 
server is up and running
 
 
 
 
bind!! you have rndc manual?
 
please rndc manual   i got manual
 
. bye   i'm very trash englishsorry...
 
   
 
___
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