Update to 9.18 failed due to libuv

[Jiaming Zhang]

Dear community,

Recently I was trying to upgrade bind from 9.16 to 9.18. However, running 
`./configure` return an error stating the `libuv` was not found. I have this 
library installed (version 1.41.1) via dnf, and can can find it using `rpm -ql` 
which shows the library is under `/usr/lib64`. I'm using Oracle Linux 8 (RHEL 8 
compatible).

My questions are: 1) is there a way to specify the location of the respective 
library file during the configuration; and 2) if not, is there a walk around? 
(download the source maybe, but is there another way?)

Thanks in advance.

ps. I tried using the isc/bind repo, but it seems they offer only x86-64 
binary, no src, no arm.

Regards,
Jimmy
-- 
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: Update to 9.18 failed due to libuv

[Anand Buddhdev]

On 04/03/2024 13:56, Jiaming Zhang wrote:

Hi Jiaming,


Recently I was trying to upgrade bind from 9.16 to 9.18. However, running 
`./configure` return an error stating the `libuv` was not found. I have this 
library installed (version 1.41.1) via dnf, and can can find it using `rpm -ql` 
which shows the library is under `/usr/lib64`. I'm using Oracle Linux 8 (RHEL 8 
compatible).


When compiling BIND, you need the development header files for libuv, so 
you have to install the "libuv-devel" package.


Regards,
Anand
--
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: Update to 9.18 failed due to libuv

[Jiaming Zhang]

Then I should download the source, there's no devel package for this one in the 
repo.

Met vriendelijke groet / Best regards,
Jiaming Zhang

Yixi Meta
Tel: +31 (0)85 800 99 88 / +31 (0)6 12 98 08 07
Email: j.zh...@yiximeta.com
Website: yiximeta.com

De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan 
dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze 
e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de 
afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail 
of informatie uit deze e-mail is alleen toegestaan met voorafgaande 
schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd 
bij de Kamer van Koophandel in het handelsregister onder nummer 85744115.

The content of this message is intended solely for the addressee. No rights can 
be derived from this message or its attachments. If you are not the intended 
recipient, we kindly request you to delete the message and inform the sender. 
It is strictly prohibited to disclose, copy or distribute this email or the 
information inside it, without a written consent from the sender. Yixi Meta is 
registered with the Dutch Chamber of Commerce trade register with number 
85744115.

Van: Anand Buddhdev 
Verzonden: Monday, March 4, 2024 2:04:35 PM
Aan: Jiaming Zhang ; bind-users@lists.isc.org 

Onderwerp: Re: Update to 9.18 failed due to libuv

On 04/03/2024 13:56, Jiaming Zhang wrote:

Hi Jiaming,

> Recently I was trying to upgrade bind from 9.16 to 9.18. However, running 
> `./configure` return an error stating the `libuv` was not found. I have this 
> library installed (version 1.41.1) via dnf, and can can find it using `rpm 
> -ql` which shows the library is under `/usr/lib64`. I'm using Oracle Linux 8 
> (RHEL 8 compatible).

When compiling BIND, you need the development header files for libuv, so
you have to install the "libuv-devel" package.

Regards,
Anand
-- 
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: Update to 9.18 failed due to libuv

[Petr Špaček]

On 04. 03. 24 14:06, Jiaming Zhang wrote:
Then I should download the source, there's no devel package for this one 
in the repo.


First question is if you need to compile yourself. Most people don't and 
can use precompiled packages. Have a look here:

https://kb.isc.org/docs/isc-packages-for-bind-9

If you need to recompile I suggest submitting support request with your 
distributor, missing devel packages are a problem in their distribution.


As a workaround you can enable the EPEL repo (I guess?).

--
Petr Špaček
Internet Systems Consortium
--
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: Update to 9.18 failed due to libuv

[Anand Buddhdev]

On 04/03/2024 14:06, Jiaming Zhang wrote:


Then I should download the source, there's no devel package for this one in the 
repo.


That's not necessary. Oracle Linux keeps many of the -devel packages in 
its "codeready_builder" repository, which is not enabled by default. As 
root, you need to run "crb enable", and then you'll be able to install 
"libuv-devel".


Regards,
Anand
--
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

XFR killed by security

[Peter]

Hi folks,

  a few days ago I apparently lost the beneficence of my zone feeds,
and XFR started to get into timeout.

Looking at the usual culprits I then found this:
   DNS Response containing multiple DNSSEC RRSIG Entries (Algorithm
   14) - Possible CVE-2023-50387 Activity
   [Classification: Detection of a Denial of Service Attack]
   {TCP} 192.0.47.132:53 -> 

I don't find it really surprizing that XFR would contain "multiple
RRSIG entries". But, according to the strategy ("shoot first, ask when
the corpses stack to the ceiling"), this thing just kills the transfers.

So, what is it about? Is it something serious?

cheerio,
PMc
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Problem upgrading to 9.18 - important feature being removed

[Matthijs Mekking]

On 3/1/24 12:23, G.W. Haywood wrote:

Hi there,

On Fri, 1 Mar 2024, Ond?ej Sur? wrote:

On 26. 2. 2024, at 22:41, Al Whaley wrote:

> A lot of pain and suffering in this world comes from people being
> sure they have a 'better idea' and everybody needs to do whatever.
> This feels a bit like that. ...

... ultimately, the developers working on BIND 9 are just a few
people and it's absolutely reasonable to remove rarely used features
- especially if there's a replacement ...

For every decision we make, be it adding a new feature or removing
an old feature, we do carefully consider the implications ...


And in this case I think it would be unfair to the developers not to
mention that more than two years ago, before actually implementing
this change, the developers did ask for comment and there was debate.
If the OP took a part in that debate I missed it.


See here for the FYI: 
https://lists.isc.org/mailman/htdig/bind-users/2022-November/106948.html


In short, we said we would go forward with the deprecation, despite key 
creation in HSM's was not yet supported (it will be in 9.20, already 
merged in our development release).


There is functional parity, everything you do with auto-dnssec can also 
be done with dnssec-policy. If you don't want to do automatic key 
rollovers, use 'lifetime unlimited' on keys.


There is a section on manual key rollover in our kb article: 
https://kb.isc.org/docs/dnssec-key-and-signing-policy


- Matthijs





8<--
Date: Tue, 10 Aug 2021 10:02:59 +0200
From: Matthijs Mekking 
To: bind-users@lists.isc.org
Subject: Deprecating auto-dnssec and inline-signing in 9.18+
Message-ID: 
Content-Type: text/plain; charset=utf-8; format=flowed

Hi users,

We are planning to deprecate the options 'auto-dnssec' and 
'inline-signing' in BIND 9.18. The reason for this is because 
'dnssec-policy' is the preferred way of maintaining your DNSSEC zone.


Deprecating means that you can still use the options in 9.18, but a 
warning will be logged and it is very likely that the options will be 
removed in BIND 9.20.


We would like to encourage you to change your configurations to 
'dnssec-policy'. See this KB article for migration help:


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

Do you have reasons for keeping 'inline-signing' or 'auto-dnssec' 
configurations? Is there a use case that is not (yet) covered by 
'dnssec-policy'? Any other concerns? Please let us know.

8<--

To try to make this more positive, Maybe the lesson here is that if
you're using BIND other than because it happened to come with your
distro, then it's probably a good idea to keep an eye on this list to
monitor the plans for development.  If it says that in the ARM, which
IMO it probably should, I missed that too.


--
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: XFR killed by security

[Ondřej Surý]

> On 4. 3. 2024, at 14:55, Peter  wrote:
> 
> I don't find it really surprizing that XFR would contain "multiple
> RRSIG entries".

Unfortunately, this is obviously surprising to the vendor of the security 
device. This needs to be fixed there, not here. As for the CVE, you have the 
number that can be used, but here’s the blogpost for reference: 
https://www.isc.org/blogs/2024-bind-security-release/

Ondrej
--
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.-- 
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: XFR killed by security

[Peter]

On Mon, Mar 04, 2024 at 03:43:48PM +0100, Ondřej Surý wrote:
! > On 4. 3. 2024, at 14:55, Peter  wrote:
! > 
! > I don't find it really surprizing that XFR would contain "multiple
! > RRSIG entries".
! 
! Unfortunately, this is obviously surprising to the vendor of the security 
device. This needs to be fixed there, not here. As for the CVE, you have the 
number that can be used, but here’s the blogpost for reference: 
https://www.isc.org/blogs/2024-bind-security-release/

Thank You, Ondrej, this link shortens my path. This is what I wanted
to know.
So the current version of BIND mitigates the issue, and the somehow
ill-devised security rule can then simply be excluded. Wonderful.

cheerio,
PMc
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Bind9 "split zones"

[Taavi Ansper via bind-users]

Hi

I am trying to understand bind9 more thorughly.

Backstory: We have been using bind9 for a long time and overhauling it 
for more "usage".


We have been using a "hidden master dns" logic with views for different 
usages.


E.g. Client -> Slave DNS Server <- (Transfer zones from hidden master)-> 
Hidden Master.


We had two views "external" and "internal" and now we added a new view 
"dmz" aswell.


In one of those zones we had an interesting DNS "thingy" where for 
example a CIDR 192.168.100.0/24 was generating entries to the main 
"hidden dns" server via includes. It uses a domain called example.com. 
Now another DNS server created DNS entries for the same CIDR 
192.168.100.0/24 but it had a different domain "subdomain.example.com". 
Including that info was easy.


In the Slave DNS

zone "example.com" {
    file blaah
    type slave
    masters { main_hidden_dns_server }
}

zone "subdomain.example.com" {
    file blaah
    type slave;
    masters { other_dns_server }
}

But now comes the problem. When generating a PTR record 
100.168.192.in-addr.arpa, I wish to combine both of these "results" into 
one lookup. How can I do that? I tried to add:


zone "100.168.192.in-addr.arpa" {
    file blaah
    type slave;
    masters { other_dns_server }
    forward first;
    forwarders {  main_hidden_dns_server }
}

But this forwarding logic doesnt work. I have a feeling the forwarding 
only works specific zones.  and you can't combine two of the same 
"names" into one. Am I correct and in order for PTR records to work I 
need to get them into a single file?


--

Taavi Ansper
taavi.ans...@cyber.ee

--
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: Problem upgrading to 9.18 - important feature being removed

[Al Whaley]

Matthij, Petr,

Thanks for responding.

I am trying to make the case that one can NOT do the same things with 
'lifetime unlimited'.  One can do some of the same positive things, but 
only if conditions are just right, and one cannot block the negative 
overriding key replacement.  If I have it all wrong, and one can do the 
same things, then I would like to understand that, but currently that 
does not seem to be the case.


With 'auto-dnssec maintain' one tells bind to update the zone signing 
with any RR changes and keep the signing up to date.  As long as bind 
finds suitable keys in the key directory, I'm done at that point.  I 
don't have to worry that there are conditions that will trigger bind to 
replace my keys with some that it likes better, because that code 
doesn't even exist in earlier versions.


Without that 'maintain' feature, but using 'lifetime unlimited' bind 
will, if it feels like it, replace my keys with some it makes itself, 
which of course takes my domain(s) offline as they no longer comply with 
the consistency check with the DS record at the TLD / next level up.  
This is viewed by some as simply a migration problem, and therefore 
simply a 'one off' thing, and once one is past that point and settled 
with 9.20, no problems exist.  But this isn't true.  If I change my 
configs in some way that bind doesn't like, or I install a new update 
that has slightly different criteria for key suitability testing in the 
new code, that could cause bind to 'deprecate' my keys and make its 
own.  I don't want bind to be making that decision.  I talked more about 
this problem in an earlier email.


I would like two new features in the dnssec-policy statement.

1) please add 'key-gen no' to stop not only key generation but the 
decision process about whether my keys are unsuitable so that bind 
doesn't reject them any more than it would in 9.16.  If future versions 
of bind have additional criteria that would cause it to deprecate my 
current keys, this would block them.


2) also please add 'algorithm any'.  right now if I have a mix of 
algorithms (e.g. 8 and 13) I can't have one single default policy.  If I 
don't specify an algorithm, bind defaults to 13, instead of 
'unspecified'.  My algorithm 8 keys will be deemed unsuitable, 
deprecated,  and will be replaced by algorithm 13 keys - a bad thing.  
This is one of the sources of instability that I am trying to 
communicate.  If at some point 13 is not well regarded and everyone is 
being shepherded to some other algorithm, let's just for the minute call 
it '22', then when I update bind, all my keys would get regenerated to 
algorithm 22 if my policy statement doesn't specify an algorithm; the 
default would be changed.  Then all my domains are broken.  I know that 
I can have my software generate bind configs with different 
dnssec-policy statements with different algoritms given explicitly, by 
rummaging around in the key directory, figuring out which algorithm the 
keys are using for various domains, and make sure the appropriate policy 
statements with the right algorithm number are generated for various 
domains, but it would be so much cleaner if I could have the algorithm 
unspecified.  Also, just to communicate what I imagine this would mean 
in all cases, if I had 'key-gen yes' (presumably the default) in a 
policy statement and 'algorithm any', when bind regenerated a key, it 
would use the same algorithm as the current keys.  If there weren't any 
current keys, then it could use the latest greatest algorithm (currently 
13) though it might be best to be able to specify this, or one could 
have it just not generate any and throw an error message (which I would 
prefer).  With large numbers of domains, there will always be a mix of 
algorithms.  Relations with other organizations can slow down 
conversions from older algorithms to new ones.


My main point here is that I am not just trying to get bind to not 'time 
out' my keys (with 'lifetime unlimited'), I am trying to prevent it from 
deciding my keys don't meet 'current standards' and make new ones.  As 
far as I know, there's no way to do that.


regards

Al

On 3/4/2024 06:05, Matthijs Mekking wrote:



On 3/1/24 12:23, G.W. Haywood wrote:

Hi there,

On Fri, 1 Mar 2024, Ond?ej Sur? wrote:

On 26. 2. 2024, at 22:41, Al Whaley wrote:

> A lot of pain and suffering in this world comes from people being
> sure they have a 'better idea' and everybody needs to do whatever.
> This feels a bit like that. ...

... ultimately, the developers working on BIND 9 are just a few
people and it's absolutely reasonable to remove rarely used features
- especially if there's a replacement ...

For every decision we make, be it adding a new feature or removing
an old feature, we do carefully consider the implications ...


And in this case I think it would be unfair to the developers not to
mention that more than two years ago, before actually implementing
this change, the developers did as

Re: Bind9 "split zones"

[Greg Choules via bind-users]

Hi.
If I understand you correctly, you are trying to get your resolver to go to
two different places (main_hidden_dns_server and other_dns_server) for
answers to the same question, and then want it combine those answers into a
single response to the client, which contains PTR records for both names?

If I got that correct, then it won't. If you want multiple PTR records to
be associated with different names then they have to be in the same
zone/zone file.

A few comments:
- The statement "forward first' means, try forwarding first and only if
that fails, then try recursion.
- Adding forwarders to a secondary zone tells the server what to do for
names delegated from that zone. e.g. if the zone is "example.com" and it
contains "sub NS another.server.somewhere.else." then a query to it for "
name.sub.example.com" will follow the "forwarders" statement because "
sub.example.com" has been delegated away.
- Do you really want to be forwarding to your hidden primary anyway?
- Why are two different servers both authoritative for
"100.168.192.in-addr.arpa"? That's asking for trouble.

Hope that helps.
Greg

On Mon, 4 Mar 2024 at 15:35, Taavi Ansper via bind-users <
bind-users@lists.isc.org> wrote:

> Hi
>
> I am trying to understand bind9 more thorughly.
>
> Backstory: We have been using bind9 for a long time and overhauling it
> for more "usage".
>
> We have been using a "hidden master dns" logic with views for different
> usages.
>
> E.g. Client -> Slave DNS Server <- (Transfer zones from hidden master)->
> Hidden Master.
>
> We had two views "external" and "internal" and now we added a new view
> "dmz" aswell.
>
> In one of those zones we had an interesting DNS "thingy" where for
> example a CIDR 192.168.100.0/24 was generating entries to the main
> "hidden dns" server via includes. It uses a domain called example.com.
> Now another DNS server created DNS entries for the same CIDR
> 192.168.100.0/24 but it had a different domain "subdomain.example.com".
> Including that info was easy.
>
> In the Slave DNS
>
> zone "example.com" {
>  file blaah
>  type slave
>  masters { main_hidden_dns_server }
> }
>
> zone "subdomain.example.com" {
>  file blaah
>  type slave;
>  masters { other_dns_server }
> }
>
> But now comes the problem. When generating a PTR record
> 100.168.192.in-addr.arpa, I wish to combine both of these "results" into
> one lookup. How can I do that? I tried to add:
>
> zone "100.168.192.in-addr.arpa" {
>  file blaah
>  type slave;
>  masters { other_dns_server }
>  forward first;
>  forwarders {  main_hidden_dns_server }
> }
>
> But this forwarding logic doesnt work. I have a feeling the forwarding
> only works specific zones.  and you can't combine two of the same
> "names" into one. Am I correct and in order for PTR records to work I
> need to get them into a single file?
>
> --
> 
> Taavi Ansper
> taavi.ans...@cyber.ee
>
> --
> 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: Bind9 "split zones"

[Taavi Ansper via bind-users]

Hi

Thanks for the quick response!

Answering the last question. There are two different systems where DNS names are generated from. One is actually phpipam where we generate entries from 
and the second one is a virtualization platform, where we also dig in the DB to generate entries for VM-s


As I don't think we have had issues with PTR records so not having a "fix" is 
not an issue.

In the end the solution is not use one IP range for both use cases.

Taavi Ansper
taavi.ans...@cyber.ee

On 04.03.24 19:06, Greg Choules wrote:

Hi.
If I understand you correctly, you are trying to get your resolver to go to two different places (main_hidden_dns_server and other_dns_server) for 
answers to the same question, and then want it combine those answers into a single response to the client, which contains PTR records for both names?


If I got that correct, then it won't. If you want multiple PTR records to be associated with different names then they have to be in the same zone/zone 
file.


A few comments:
- The statement "forward first' means, try forwarding first and only if that 
fails, then try recursion.
- Adding forwarders to a secondary zone tells the server what to do for names delegated from that zone. e.g. if the zone is "example.com 
" and it contains "sub NS another.server.somewhere.else." then a query to it for "name.sub.example.com 
" will follow the "forwarders" statement because "sub.example.com " has been delegated away.

- Do you really want to be forwarding to your hidden primary anyway?
- Why are two different servers both authoritative for 
"100.168.192.in-addr.arpa"? That's asking for trouble.

Hope that helps.
Greg

On Mon, 4 Mar 2024 at 15:35, Taavi Ansper via bind-users mailto:bind-users@lists.isc.org>> wrote:

Hi

I am trying to understand bind9 more thorughly.

Backstory: We have been using bind9 for a long time and overhauling it
for more "usage".

We have been using a "hidden master dns" logic with views for different
usages.

E.g. Client -> Slave DNS Server <- (Transfer zones from hidden master)->
Hidden Master.

We had two views "external" and "internal" and now we added a new view
"dmz" aswell.

In one of those zones we had an interesting DNS "thingy" where for
example a CIDR 192.168.100.0/24  was generating 
entries to the main
"hidden dns" server via includes. It uses a domain called example.com 
.
Now another DNS server created DNS entries for the same CIDR
192.168.100.0/24  but it had a different domain 
"subdomain.example.com ".
Including that info was easy.

In the Slave DNS

zone "example.com " {
  file blaah
  type slave
  masters { main_hidden_dns_server }
}

zone "subdomain.example.com " {
  file blaah
  type slave;
  masters { other_dns_server }
}

But now comes the problem. When generating a PTR record
100.168.192.in-addr.arpa, I wish to combine both of these "results" into
one lookup. How can I do that? I tried to add:

zone "100.168.192.in-addr.arpa" {
  file blaah
  type slave;
  masters { other_dns_server }
  forward first;
  forwarders {  main_hidden_dns_server }
}

But this forwarding logic doesnt work. I have a feeling the forwarding
only works specific zones.  and you can't combine two of the same
"names" into one. Am I correct and in order for PTR records to work I
need to get them into a single file?

-- 


Taavi Ansper
taavi.ans...@cyber.ee 

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