Re: 9.16.19 repeated crashes on FreeBSD 12.2-p6

[Mark Andrews]

> On 13 Aug 2021, at 15:12, Randy Bush  wrote:
> 
>> Presumably you are running with `named -u`
> 
># grep named /etc/rc.conf
>named_enable=YES
>named_program=/usr/local/sbin/named
>named_conf=/usr/home/dns/named.conf
>named_chrootdir=""
>named_chroot_autoupdate=NO
>named_uid=bind
>named_gid=bind
>named_wait=YES
>named_auto_forward=YES
>named_flags="-u bind"
>named_auto_forward_only=NO
> 
> named crashed
> 
># find / -name *.core
>#
> 
> what am i misunderstanding?

Named calls set{re}uid(2), when running with `named -u`, which DISABLES core
dumps of the process unless the kernel has been told otherwise.  This has
to be done by the ADMINISTRATOR as it is a SYSTEM WIDE configuration knob.
There is no per process knob.

See the afore mentioned KB articles for how to do this.

> randy

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

Re: 9.16.19 repeated crashes on FreeBSD 12.2-p6

[Randy Bush]

> Presumably you are running with `named -u`

# grep named /etc/rc.conf
named_enable=YES
named_program=/usr/local/sbin/named
named_conf=/usr/home/dns/named.conf
named_chrootdir=""
named_chroot_autoupdate=NO
named_uid=bind
named_gid=bind
named_wait=YES
named_auto_forward=YES
named_flags="-u bind"
named_auto_forward_only=NO

named crashed

# find / -name *.core
#

what am i misunderstanding?

randy
___
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: 9.16.19 repeated crashes on FreeBSD 12.2-p6

[Mark Andrews]

> On 13 Aug 2021, at 10:03, Randy Bush  wrote:
> 
> FreeBSD 12.2-RELEASE-p6 GENERIC on amd64
> bind 9.16.19 from binary ports
> 
> ok, i was quietly waiting for a fix to magically appear and is hasn't.
> 
> i am getting 10-20 crashes a day on each of two servers.  it is not
> leaving disk flowers; and i see no config option to encourage it to do
> so.

Presumably you are running with `named -u` so tell the kernel to allow
core dumps for suid binaries [1] or allow an ordinary user to bind to
reserved ports [2] and start named as the ordinary user rather than using
'named -u’.  Use chroot rather su if you are using `named -t`.

su -u user named …

chroot -u user  named … 

[1] https://kb.isc.org/docs/aa-00340
[2] https://kb.isc.org/docs/aa-00621

Mark

> randy
> 
> ---
> ra...@psg.com
> `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
> signatures are back, thanks to dmarc header butchery
> ___
> 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

Re: Switching key types for authorizing updates

[Mark Andrews]

You could also switch to using SIG(0) instead of TSIG.  The the client
can just update the KEY RRset which is stored in the zone.

> On 13 Aug 2021, at 03:49, John Thurston  wrote:
> 
> On 8/12/2021 5:00 AM, Tony Finch wrote:
>> i.e. using the "subdomain" rule type instead of "selfsub", so the
>> domain name (second foo...) doesn't need to match the keyname (first
>> foo...)
> 
> 
> Yes, indeed. That's the ticket.
> Thank you very much, Tony.
> 
> --
> 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

-- 
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.19 repeated crashes on FreeBSD 12.2-p6

[Randy Bush]

FreeBSD 12.2-RELEASE-p6 GENERIC on amd64
bind 9.16.19 from binary ports

ok, i was quietly waiting for a fix to magically appear and is hasn't.

i am getting 10-20 crashes a day on each of two servers.  it is not
leaving disk flowers; and i see no config option to encourage it to do
so.

randy

---
ra...@psg.com
`gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
signatures are back, thanks to dmarc header butchery
___
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: Switching key types for authorizing updates

[John Thurston]

On 8/12/2021 5:00 AM, Tony Finch wrote:

i.e. using the "subdomain" rule type instead of "selfsub", so the
domain name (second foo...) doesn't need to match the keyname (first
foo...)



Yes, indeed. That's the ticket.
Thank you very much, Tony.

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

Re: Switching key types for authorizing updates

[Tony Finch]

John Thurston  wrote:
>
> But as far as I can tell, the name of the key needs to match the hostname in
> the update-policy statement. I can define a new aes-256 key, but it can't have
> the name "foo.bar.baz.com" while the current md5 key is defined. Nor can I
> find a way to craft an update-policy statement line to let a new key with a
> different name manipulate the desired TXT records, while letting the current
> key continue to work.

I think you want something like:

update-policy {
grant "foo.bar.baz.com_aes256" subdomain "foo.bar.baz.com" TXT;
};

i.e. using the "subdomain" rule type instead of "selfsub", so the
domain name (second foo...) doesn't need to match the keyname (first
foo...)

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
work to the benefit of 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

Re: Deprecating auto-dnssec and inline-signing in 9.18+

[Ralph Seichter]

* Tim Daneliuk via bind-users:

> I believe the DS record is what I have to provide my registrar as I
> understand it.

That depends on the top level domain. For example, .de uses DS records,
while .com uses DNSKEY reords. Best to ask your registrar.

-Ralph
___
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: Can't get Bind to publish CDS/CDNSKEY using dnssec-policy

[Josef Vybíhal]

Thank you for pointing me to that issue !2857
, that's exactly
what I hit. Now when I see the details, it makes sense.

I have cleared the domain from all keys and dnssec-policy settings. Then
assigned the dnssec-policy to unsigned domain and bam, CDS+CDNSKEY records
are published after time specified in policy.

Josef

On Thu, Aug 12, 2021 at 10:08 AM Matthijs Mekking  wrote:

> Hi,
>
> On 12-08-2021 09:02, Josef Vybíhal wrote:
> > Hi, for a second day, I am scratching my head over (automatic)
> > publishing CDS/CDNSKEY records. When I read Matthijs Mekkings KB article
> > at https://kb.isc.org/docs/dnssec-key-and-signing-policy
> > , I wanted to
> try
> > dnssec-policy. Up until now, I successfully was using inline-signing
> > with auto-dnssec.
> >
> > I configured my dnssec-policy to match the current key setting, but I
> > probably made a mistake and it did not match it, so a new key was
> > generated. No big deal, it's a test domain, rollover is not a problem.
>
> I am sorry, I am afraid you hit a bug:
> https://gitlab.isc.org/isc-projects/bind9/-/issues/2857
>
> The legacy key metadata has no information about the role of keys. It
> determines the role from the key flags: 256 means it is a ZSK, and 257
> is converted to a KSK. In other words, migrating a CSK won't work.
>
> I am working on a fix so that you will be able to migrate CSKs.
>
> For now I have added a warning to the KB article.
>
>
> > Since my TLD supports CDNSKEY, I want to leverage it. So I removed
> > current DS record from the domain and expected Bind to publish
> > CDS/CDNSKEY
> > (
> https://bind9.readthedocs.io/en/latest/dnssec-guide.html#the-cds-and-cdnskey-resource-records
> > <
> https://bind9.readthedocs.io/en/latest/dnssec-guide.html#the-cds-and-cdnskey-resource-records>).
>
> > Unfortunately I can not get bind to automatically publish them. No clue
> > why. I kind of expected bind topublish them on PublishCDS:
> > 20210811135045 (Wed Aug 11 15:50:45 2021) automatically.
>
> The metadata is indeed an indication of when certain events are expected
> to happen. But if BIND determines it is not safe to do so, there may be
> a delay.
>
>  From the output below, it looks like not all zone signatures have been
> propagated yet:
>
>  >- zone rrsig: rumoured
>
> The PublishCDS metadata is usually set to the the time that the DNSKEY
> has been published, plus dnskey-ttl, zone-propagation-delay, and
> publish-safety. If it is the first key for the zone, the time to
> propagate the zone signatures is taken into account. But in your case
> two other keys already existed.
>
> The PublishCDS metadata can be set more accurately if we can detect that
> none of the other keys have a secure delegation (I think we can).
>
>
> Best regards,
>
> Matthijs
>
>
> > domain: irmorava.cz 
> > version: BIND 9.16.19
> > OS: CentOS 8 Stream + packages from copr.
> >
> > named.conf:
> > dnssec-policy "pepa" {
> > keys {
> > csk key-directory lifetime unlimited algorithm 13;
> > };
> >
> > // Key timings
> > dnskey-ttl PT1H;
> > publish-safety PT1H;
> > retire-safety PT1H;
> > purge-keys P1D;
> >
> > // Signature timings
> > signatures-refresh P5D;
> > signatures-validity P14D;
> > signatures-validity-dnskey P14D;
> >
> > // Zone parameters
> > max-zone-ttl PT1H;
> > zone-propagation-delay PT5M;
> > parent-ds-ttl PT1H;
> > parent-propagation-delay PT1H;
> > nsec3param iterations 1 optout false salt-length 16;
> > };
> >
> > zone "irmorava.cz " {
> > type master;
> > file "master/irmorava.cz.zone";
> > allow-update { none; };
> > key-directory "keys/irmorava.cz ";
> > dnssec-policy pepa;
> > notify yes;
> > allow-transfer { pepa_abc; };
> > };
> >
> >
> > dig irmorava.cz  @127.0.0.1 
> > DNSKEY +short +norec
> > 257 3 13 Xsfq5rEgoE+iT+cvq0OZz43MiLiRLeH8SUAEIprn0/J3PNZSYVlCeNuF
> > 5lfNo6uM0TeApujDhmQ1FPNINKxa2Q==
> >
> >
> > rndc dnssec -status irmorava.cz 
> > dnssec-policy: pepa
> > current time:  Thu Aug 12 08:38:40 2021
> >
> > key: 22788 (ECDSAP256SHA256), CSK
> >published:  yes - since Wed Aug 11 10:20:00 2021
> >key signing:yes - since Wed Aug 11 10:20:00 2021
> >zone signing:   yes - since Wed Aug 11 12:25:00 2021
> >
> >No rollover scheduled
> >- goal:   omnipresent
> >- dnskey: omnipresent
> >- ds: hidden
> >- zone rrsig: rumoured
> >- key rrsig:  omnipresent
> >
> > key: 44055 (ECDSAP256SHA256), CSK
> >published:  no
> >key signing:no
> >zone signing:   no
> >
> >Key has been removed from the zone
> >- goal:   hidden
> >- dnskey: hidden
> >- ds: hidden
> >- zone rrsig: unretentive
> >- key rrsig:  hidden
> >
> > key: 35549 (ECDSAP256SHA256), CSK
> >publ

Re: Can't get Bind to publish CDS/CDNSKEY using dnssec-policy

[Matthijs Mekking]

Hi,

On 12-08-2021 09:02, Josef Vybíhal wrote:
Hi, for a second day, I am scratching my head over (automatic) 
publishing CDS/CDNSKEY records. When I read Matthijs Mekkings KB article 
at https://kb.isc.org/docs/dnssec-key-and-signing-policy 
, I wanted to try 
dnssec-policy. Up until now, I successfully was using inline-signing 
with auto-dnssec.


I configured my dnssec-policy to match the current key setting, but I 
probably made a mistake and it did not match it, so a new key was 
generated. No big deal, it's a test domain, rollover is not a problem.


I am sorry, I am afraid you hit a bug: 
https://gitlab.isc.org/isc-projects/bind9/-/issues/2857


The legacy key metadata has no information about the role of keys. It 
determines the role from the key flags: 256 means it is a ZSK, and 257 
is converted to a KSK. In other words, migrating a CSK won't work.


I am working on a fix so that you will be able to migrate CSKs.

For now I have added a warning to the KB article.


Since my TLD supports CDNSKEY, I want to leverage it. So I removed 
current DS record from the domain and expected Bind to publish 
CDS/CDNSKEY 
(https://bind9.readthedocs.io/en/latest/dnssec-guide.html#the-cds-and-cdnskey-resource-records 
). 
Unfortunately I can not get bind to automatically publish them. No clue 
why. I kind of expected bind topublish them on PublishCDS: 
20210811135045 (Wed Aug 11 15:50:45 2021) automatically.


The metadata is indeed an indication of when certain events are expected 
to happen. But if BIND determines it is not safe to do so, there may be 
a delay.


From the output below, it looks like not all zone signatures have been 
propagated yet:


>- zone rrsig: rumoured

The PublishCDS metadata is usually set to the the time that the DNSKEY 
has been published, plus dnskey-ttl, zone-propagation-delay, and 
publish-safety. If it is the first key for the zone, the time to 
propagate the zone signatures is taken into account. But in your case 
two other keys already existed.


The PublishCDS metadata can be set more accurately if we can detect that 
none of the other keys have a secure delegation (I think we can).



Best regards,

Matthijs



domain: irmorava.cz 
version: BIND 9.16.19
OS: CentOS 8 Stream + packages from copr.

named.conf:
dnssec-policy "pepa" {
keys {
csk key-directory lifetime unlimited algorithm 13;
};

// Key timings
dnskey-ttl PT1H;
publish-safety PT1H;
retire-safety PT1H;
purge-keys P1D;

// Signature timings
signatures-refresh P5D;
signatures-validity P14D;
signatures-validity-dnskey P14D;

// Zone parameters
max-zone-ttl PT1H;
zone-propagation-delay PT5M;
parent-ds-ttl PT1H;
parent-propagation-delay PT1H;
nsec3param iterations 1 optout false salt-length 16;
};

zone "irmorava.cz " {
type master;
file "master/irmorava.cz.zone";
allow-update { none; };
key-directory "keys/irmorava.cz ";
dnssec-policy pepa;
notify yes;
allow-transfer { pepa_abc; };
};


dig irmorava.cz  @127.0.0.1  
DNSKEY +short +norec
257 3 13 Xsfq5rEgoE+iT+cvq0OZz43MiLiRLeH8SUAEIprn0/J3PNZSYVlCeNuF 
5lfNo6uM0TeApujDhmQ1FPNINKxa2Q==



rndc dnssec -status irmorava.cz 
dnssec-policy: pepa
current time:  Thu Aug 12 08:38:40 2021

key: 22788 (ECDSAP256SHA256), CSK
   published:      yes - since Wed Aug 11 10:20:00 2021
   key signing:    yes - since Wed Aug 11 10:20:00 2021
   zone signing:   yes - since Wed Aug 11 12:25:00 2021

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

key: 44055 (ECDSAP256SHA256), CSK
   published:      no
   key signing:    no
   zone signing:   no

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

key: 35549 (ECDSAP256SHA256), CSK
   published:      no
   key signing:    no
   zone signing:   no

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



/var/named/keys/irmorava.cz/Kirmorava.cz.+013+22788.state 
:

; This is the state of key 22788, for irmorava.cz .
Algorithm: 13
Length: 256
Lifetime: 0
Predecessor: 44055
KSK: yes
ZSK: yes
Generated: 20210811082000 (Wed Aug 11 10:20:00 2021)
Published: 20210811082000 (Wed Aug 11 10:20:00 2021)
Active: 20210811102500 (Wed Aug 11 12:25:00 2021)
DSPublish: 20210811131037 (Wed Aug 11 15:10:37 2021)
DSRemoved: 20210811131020 (Wed Aug 11 15:10:20 2021)
*PublishCDS: 20210811135045 (Wed Aug 11 15:50:45 2021)
*DNSKEYChange: 20210

Can't get Bind to publish CDS/CDNSKEY using dnssec-policy

[Josef Vybíhal]

Hi, for a second day, I am scratching my head over (automatic) publishing
CDS/CDNSKEY records. When I read Matthijs Mekkings KB article at
https://kb.isc.org/docs/dnssec-key-and-signing-policy, I wanted to try
dnssec-policy. Up until now, I successfully was using inline-signing with
auto-dnssec.

I configured my dnssec-policy to match the current key setting, but I
probably made a mistake and it did not match it, so a new key was
generated. No big deal, it's a test domain, rollover is not a problem.

Since my TLD supports CDNSKEY, I want to leverage it. So I removed current
DS record from the domain and expected Bind to publish CDS/CDNSKEY (
https://bind9.readthedocs.io/en/latest/dnssec-guide.html#the-cds-and-cdnskey-resource-records).
Unfortunately I can not get bind to automatically publish them. No clue
why. I kind of expected bind to publish them on PublishCDS: 20210811135045
(Wed Aug 11 15:50:45 2021) automatically.

domain: irmorava.cz
version: BIND 9.16.19
OS: CentOS 8 Stream + packages from copr.

named.conf:
dnssec-policy "pepa" {
keys {
csk key-directory lifetime unlimited algorithm 13;
};

// Key timings
dnskey-ttl PT1H;
publish-safety PT1H;
retire-safety PT1H;
purge-keys P1D;

// Signature timings
signatures-refresh P5D;
signatures-validity P14D;
signatures-validity-dnskey P14D;

// Zone parameters
max-zone-ttl PT1H;
zone-propagation-delay PT5M;
parent-ds-ttl PT1H;
parent-propagation-delay PT1H;
nsec3param iterations 1 optout false salt-length 16;
};

zone "irmorava.cz" {
type master;
file "master/irmorava.cz.zone";
allow-update { none; };
key-directory "keys/irmorava.cz";
dnssec-policy pepa;
notify yes;
allow-transfer { pepa_abc; };
};


dig irmorava.cz @127.0.0.1 DNSKEY +short +norec
257 3 13 Xsfq5rEgoE+iT+cvq0OZz43MiLiRLeH8SUAEIprn0/J3PNZSYVlCeNuF
5lfNo6uM0TeApujDhmQ1FPNINKxa2Q==


rndc dnssec -status irmorava.cz
dnssec-policy: pepa
current time:  Thu Aug 12 08:38:40 2021

key: 22788 (ECDSAP256SHA256), CSK
  published:  yes - since Wed Aug 11 10:20:00 2021
  key signing:yes - since Wed Aug 11 10:20:00 2021
  zone signing:   yes - since Wed Aug 11 12:25:00 2021

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

key: 44055 (ECDSAP256SHA256), CSK
  published:  no
  key signing:no
  zone signing:   no

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

key: 35549 (ECDSAP256SHA256), CSK
  published:  no
  key signing:no
  zone signing:   no

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



/var/named/keys/irmorava.cz/Kirmorava.cz.+013+22788.state:
; This is the state of key 22788, for irmorava.cz.
Algorithm: 13
Length: 256
Lifetime: 0
Predecessor: 44055
KSK: yes
ZSK: yes
Generated: 20210811082000 (Wed Aug 11 10:20:00 2021)
Published: 20210811082000 (Wed Aug 11 10:20:00 2021)
Active: 20210811102500 (Wed Aug 11 12:25:00 2021)
DSPublish: 20210811131037 (Wed Aug 11 15:10:37 2021)
DSRemoved: 20210811131020 (Wed Aug 11 15:10:20 2021)

*PublishCDS: 20210811135045 (Wed Aug 11 15:50:45 2021)*DNSKEYChange:
20210811102500 (Wed Aug 11 12:25:00 2021)
ZRRSIGChange: 20210811082000 (Wed Aug 11 10:20:00 2021)
KRRSIGChange: 20210811102500 (Wed Aug 11 12:25:00 2021)
DSChange: 20210811082000 (Wed Aug 11 10:20:00 2021)
DNSKEYState: omnipresent
ZRRSIGState: rumoured
KRRSIGState: omnipresent
DSState: hidden
GoalState: omnipresent


As you can see, I rolled over 2 more keys, but the desired records were not
published. Yesterday I tried manually 'dnssec-settime -P sync now
Kirmorava.cz.+013+22788.key'. I have waited as I read here
https://lists.isc.org/pipermail/bind-users/2020-April/102903.html but still
no luck.

I am sure I am missing something stupidly simple. Could someone please give
me any hint? Or are 'parental-agents' required to be configured? Does not
seem right way to me.

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