configure notify for ixfer?

[Cuttler, Brian R (HEALTH) via bind-users]

My dns secondary is often behind on its dynamic zone tables.
It looks to me like we are doing automatic transfer IXFR but not requently enough, but randomly.

It looks to me that default 10 second interval for min transfer wait time.

I'm missing something but haven't found the magic yet.

Both primary/secondary BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.5 on Centos 7.9.

Goal is to have dynamic entries replicated on the secondary within a few minutes if not a few seconds.

From what I'm reading I should be sending a notify from the primary to the secondary when a dynamic zone is updated but I don't seem to be doing that.

Would someone please point me to the option I'm missing to do so? I've either completely missed it, mis-understood what I read or am going in the wrong direction.

01-Jun-2021 07:49:05.425 xfer-out: client @0x7f17335f9450 10.50.156.70#45583 (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR started (serial 1501355783 -> 1501355796)
01-Jun-2021 07:49:05.426 xfer-out: client @0x7f17335f9450 10.50.156.70#45583 (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR ended
01-Jun-2021 08:46:52.595 xfer-out: client @0x7f17334a7e80 10.50.156.70#39191 (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR started (serial 1501355796 -> 1501355835)
01-Jun-2021 08:46:52.596 xfer-out: client @0x7f17334a7e80 10.50.156.70#39191 (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR ended
01-Jun-2021 09:35:10.776 xfer-out: client @0x7f1732f45d60 10.50.156.70#39230 (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR started (serial 1501355835 -> 1501355858)
01-Jun-2021 09:35:10.776 xfer-out: client @0x7f1732f45d60 10.50.156.70#39230 (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR ended

Thanks in advance,
Brian


Brian Cuttler

ITG - Information Technology Group, Network and System Administrator
Wadsworth Center, NYS Department of Health
Empire State Plaza, Albany, NY 12201
[phone] | ***@health.ny.gov<mailto:***@health.ny.gov>

[Anand Buddhdev]

On 01/06/2021 17:18, Cuttler, Brian R (HEALTH) via bind-users wrote:

Hi Brian,

> From what I'm reading I should be sending a notify from the primary
> to the secondary when a dynamic zone is updated but I don't seem to be
> doing that.
>
> Would someone please point me to the option I'm missing to do so?
> I've either completely missed it, mis-understood what I read or am going in
> the wrong direction.

You need an "also-notify" option for that zone. Read more about this in
the BIND documentation:

https://bind9.readthedocs.io/en/v9_16_16/reference.html#zone-transfers

While this documentation refers to the latest stable version of BIND, it
should still apply to the older version you're using.

Regards,
Anand
_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[MAYER Hans]

Dear All,

I have a strange behaviour which I can’t explain. So I am asking for help.
In my named.conf I have two views. One view is called „intern“ ( German internally ) and the other is called „fueralle“ ( German "for everyone" )
In the internal view I have a response-policy with two zones, a „drop“ zone and a „passthru“ zone where I rewrite some IP addresses for internal use. The "match-clients“ definition is defined with „lokal“ which is the local IPv4 address range 192.168.0.0/16 and the public IPv6 address but no loopback, either IPv6 or IPv4.
The "for everyone“ zone has everything else. It has the domain name as master and some others as slave and also "168.192.IN-ADDR.ARPA“ ; match-clients is defined with „any“
The server is physically located in network 192.168.0.0 and reachable from the world via NAT and has also a public available IPv6 address.

Now the behaviour is the following: When I query from the local IPv6 or IPv4 network with „dig -x“ for an IP address I get back „status: NXDOMAIN“
But when I do the same on the server itself using the loopback addresses for IPv6 or IPv4 it works fine. It also works, if the query comes from the Internet over IPv4 with NAT or with the public IPv6 address. If I query „normal forward“ for an IP with a given name then it works in any case and from every location. This is interesting because the reverse lookup zone and the normal forward zone are both in the same view „fueralle“.

If I remove the views it works as I would expect.

I am using BIND 9.16.16 (Stable Release) <id:0c314d8> running on Linux x86_64 4.19.0-16-amd64

Any help is welcome.


Kind regards
Hans

--

Ing. Dipl.-Ing. Hans Mayer
Systems Analyst
Network Unix Security Team (NUST)
Information and Communication Technologies (ICT)

International Institute for Applied Systems Analysis (IIASA)
Schlossplatz 1
A-2361 Laxenburg, Austria
Phone: [phone] Ext 215
Mobile: [phone]
Web: http://www.iiasa.ac.at
E-Mail: ***@iiasa.at<mailto:***@iiasa.at>

Note: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it.





On 01.06.2021, at 17:31, Anand Buddhdev <***@ripe.net<mailto:***@ripe.net>> wrote:

On 01/06/2021 17:18, Cuttler, Brian R (HEALTH) via bind-users wrote:

Hi Brian,

From what I'm reading I should be sending a notify from the primary
to the secondary when a dynamic zone is updated but I don't seem to be
doing that.

Would someone please point me to the option I'm missing to do so?
I've either completely missed it, mis-understood what I read or am going in
the wrong direction.

You need an "also-notify" option for that zone. Read more about this in
the BIND documentation:

https://bind9.readthedocs.io/en/v9_16_16/reference.html#zone-transfers

While this documentation refers to the latest stable version of BIND, it
should still apply to the older version you're using.

Regards,
Anand
_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Tony Finch]

MAYER Hans <***@iiasa.ac.at> wrote:
>

I can see why the behaviour of your server is confusing! I'll explain what
is happening in detail below, but here's the basic idea:

Each view in a configuration is separate from the others: `named` first
chooses which view to use (based on match-clients etc.) then handles the
query purely within that view. If a zone is only configured in one view
then that zone configuration will not be used to answer queries that are
handled by another view.

By itself, that basic idea isn't enough to explain what's happening with
your server, so let's look at the details, then I'll outline some
solutions.

> Now the behaviour is the following: When I query from the local IPv6 or
> IPv4 network with „dig -x“ for an IP address I get back „status:
> NXDOMAIN“

In this case your query is matching the "intern" view, which doesn't know
about your RFC 1918 reverse DNS zone, so it resolves the query using the
public DNS, which says NXDOMAIN.

> But when I do the same on the server itself using the loopback addresses
> for IPv6 or IPv4 it works fine. It also works, if the query comes from
> the Internet over IPv4 with NAT or with the public IPv6 address.

In these cases your query is reaching the "fueralle" view, which does know
about your reverse DNS zone.

> If I query „normal forward“ for an IP with a given name then it works in
> any case and from every location. This is interesting because the
> reverse lookup zone and the normal forward zone are both in the same
> view „fueralle“.

This is where it gets complicated! There are two cases:

When you query your forward zone from an external IP address, or from a
loopback IP address, the query is handled by the "fueralle" view, which
knows about your forward zone, so it can answer the query.

When you query from an internal IP address, it is handled by the "intern"
view which doesn't know about your forward zone. So it does normal
recursive resolution, which (I guess!) eventally tells the server to query
itself via the public NAT or IPv6 addresses, so the recursive query is
answered by the "fueralle" view.

If you turn on query logging (and if my guess is right) you should see
two entries in the query log for this last kind of query, one in the
"intern" view, and a matching one in the "fueralle" view.

To make your views behave more consistently, the solution is to make sure
that each view knows about all the zones that it needs to.

So your "intern" view should have your forward zone and your RFC 1918
reverse zone, and your "fueralle" view should only have your forward zone
(because you don't want to publish a private zone on a public server).

There are a couple of ways to make the forward zone appear in both views.

You can use the "in-view" zone configuration option, which makes this view
re-use a zone configuration from another view.

You can continue to rely on the resolver, but that is less reliable
because it will not work if/when your network loses external connectivity.

What you must not do is simply copy the same primary or secondary zone
configuration into multiple views: if you do that, you will have multiple
zone configurations trying to use the same files, and they will conflict
with each other.

Tony.
--
f.anthony.n.finch <***@dotat.at> https://dotat.at/
Plymouth, Biscay: Variable 2 to 4. Slight or moderate. Mainly fair.
Moderate or good.

[MAYER Hans]

Dear Tony,

Many thanks for your really very detailed answer.
I will take a look into details and let you know within the next days.

Kind regards
Hans



-----Original Message-----
From: Tony Finch <***@hermes.cam.ac.uk> On Behalf Of Tony Finch
Sent: Sunday, June 6, 2021 10:54 PM
To: MAYER Hans <***@iiasa.ac.at>
Cc: bind-***@lists.isc.org
Subject: Re: reverse lookup for RFC1918 in view failed

MAYER Hans <***@iiasa.ac.at> wrote:
>

I can see why the behaviour of your server is confusing! I'll explain what is happening in detail below, but here's the basic idea:

Each view in a configuration is separate from the others: `named` first chooses which view to use (based on match-clients etc.) then handles the query purely within that view. If a zone is only configured in one view then that zone configuration will not be used to answer queries that are handled by another view.

By itself, that basic idea isn't enough to explain what's happening with your server, so let's look at the details, then I'll outline some solutions.

> Now the behaviour is the following: When I query from the local IPv6
> or
> IPv4 network with „dig -x“ for an IP address I get back „status:
> NXDOMAIN“

In this case your query is matching the "intern" view, which doesn't know about your RFC 1918 reverse DNS zone, so it resolves the query using the public DNS, which says NXDOMAIN.

> But when I do the same on the server itself using the loopback
> addresses for IPv6 or IPv4 it works fine. It also works, if the query
> comes from the Internet over IPv4 with NAT or with the public IPv6 address.

In these cases your query is reaching the "fueralle" view, which does know about your reverse DNS zone.

> If I query „normal forward“ for an IP with a given name then it works
> in any case and from every location. This is interesting because the
> reverse lookup zone and the normal forward zone are both in the same
> view „fueralle“.

This is where it gets complicated! There are two cases:

When you query your forward zone from an external IP address, or from a loopback IP address, the query is handled by the "fueralle" view, which knows about your forward zone, so it can answer the query.

When you query from an internal IP address, it is handled by the "intern"
view which doesn't know about your forward zone. So it does normal recursive resolution, which (I guess!) eventally tells the server to query itself via the public NAT or IPv6 addresses, so the recursive query is answered by the "fueralle" view.

If you turn on query logging (and if my guess is right) you should see two entries in the query log for this last kind of query, one in the "intern" view, and a matching one in the "fueralle" view.

To make your views behave more consistently, the solution is to make sure that each view knows about all the zones that it needs to.

So your "intern" view should have your forward zone and your RFC 1918 reverse zone, and your "fueralle" view should only have your forward zone (because you don't want to publish a private zone on a public server).

There are a couple of ways to make the forward zone appear in both views.

You can use the "in-view" zone configuration option, which makes this view re-use a zone configuration from another view.

You can continue to rely on the resolver, but that is less reliable because it will not work if/when your network loses external connectivity.

What you must not do is simply copy the same primary or secondary zone configuration into multiple views: if you do that, you will have multiple zone configurations trying to use the same files, and they will conflict with each other.

Tony.
--
f.anthony.n.finch <***@dotat.at> https://dotat.at/ Plymouth, Biscay: Variable 2 to 4. Slight or moderate. Mainly fair.
Moderate or 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-***@lists.isc.org
https://lists.isc.org/mailman/listinf

[Mark Andrews]

> On 2 Jun 2021, at 01:18, Cuttler, Brian R (HEALTH) via bind-users <bind-***@lists.isc.org> wrote:
>
> My dns secondary is often behind on its dynamic zone tables.
> It looks to me like we are doing automatic transfer IXFR but not requently enough, but randomly.
>
> It looks to me that default 10 second interval for min transfer wait time.
>
> I'm missing something but haven't found the magic yet.
>
> Both primary/secondary BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.5 on Centos 7.9.
>
> Goal is to have dynamic entries replicated on the secondary within a few minutes if not a few seconds.
>
> From what I’m reading I should be sending a notify from the primary to the secondary when a dynamic zone is updated but I don’t seem to be doing that.
>
> Would someone please point me to the option I’m missing to do so? I’ve either completely missed it, mis-understood what I read or am going in the wrong direction.
>
> 01-Jun-2021 07:49:05.425 xfer-out: client @0x7f17335f9450 10.50.156.70#45583 (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR started (serial 1501355783 -> 1501355796)
> 01-Jun-2021 07:49:05.426 xfer-out: client @0x7f17335f9450 10.50.156.70#45583 (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR ended
> 01-Jun-2021 08:46:52.595 xfer-out: client @0x7f17334a7e80 10.50.156.70#39191 (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR started (serial 1501355796 -> 1501355835)
> 01-Jun-2021 08:46:52.596 xfer-out: client @0x7f17334a7e80 10.50.156.70#39191 (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR ended
> 01-Jun-2021 09:35:10.776 xfer-out: client @0x7f1732f45d60 10.50.156.70#39230 (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR started (serial 1501355835 -> 1501355858)
> 01-Jun-2021 09:35:10.776 xfer-out: client @0x7f1732f45d60 10.50.156.70#39230 (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR ended
>
> Thanks in advance,
> Brian

Named uses the NS records for the zone to find the addresses of the secondary servers to send the NOTIFY messages to. Both primary and secondary servers do this by default. The nameserver listed in the SOA record MNAME field is excluded this process. Ensure you have address record for all your nameservers.

If a secondary is not listed in the NS RRset then you can use also-notify as Anand said.

> Brian Cuttler
>
> ITG - Information Technology Group, Network and System Administrator
> Wadsworth Center, NYS Department of Health
> Empire State Plaza, Albany, NY 12201
> [phone] | ***@health.ny.gov
>
>
> _______________________________________________
> 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-***@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone] INTERNET: ***@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-***@lists.isc.org
https://

[Dan Sjolseth via bind-users]

Inside the zone statement of the primary add:

also-notify { ipofsecondary };

This will make transfer in microseconds.

Let me know if it works for you.

Dan



On Jun 1, 2021, at 7:24 PM, Mark Andrews <***@isc.org> wrote:


On 2 Jun 2021, at 01:18, Cuttler, Brian R (HEALTH) via bind-users <bind-***@lists.isc.org> wrote:

My dns secondary is often behind on its dynamic zone tables.
It looks to me like we are doing automatic transfer IXFR but not requently enough, but randomly.

It looks to me that default 10 second interval for min transfer wait time.

I'm missing something but haven't found the magic yet.

Both primary/secondary BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.5 on Centos 7.9.

Goal is to have dynamic entries replicated on the secondary within a few minutes if not a few seconds.

From what I’m reading I should be sending a notify from the primary to the secondary when a dynamic zone is updated but I don’t seem to be doing that.

Would someone please point me to the option I’m missing to do so? I’ve either completely missed it, mis-understood what I read or am going in the wrong direction.

01-Jun-2021 07:49:05.425 xfer-out: client @0x7f17335f9450 10.50.156.70#45583 (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR started (serial 1501355783 -> 1501355796)
01-Jun-2021 07:49:05.426 xfer-out: client @0x7f17335f9450 10.50.156.70#45583 (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR ended
01-Jun-2021 08:46:52.595 xfer-out: client @0x7f17334a7e80 10.50.156.70#39191 (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR started (serial 1501355796 -> 1501355835)
01-Jun-2021 08:46:52.596 xfer-out: client @0x7f17334a7e80 10.50.156.70#39191 (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR ended
01-Jun-2021 09:35:10.776 xfer-out: client @0x7f1732f45d60 10.50.156.70#39230 (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR started (serial 1501355835 -> 1501355858)
01-Jun-2021 09:35:10.776 xfer-out: client @0x7f1732f45d60 10.50.156.70#39230 (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR ended

Thanks in advance,
Brian

Named uses the NS records for the zone to find the addresses of the secondary servers to send the NOTIFY messages to. Both primary and secondary servers do this by default. The nameserver listed in the SOA record MNAME field is excluded this process. Ensure you have address record for all your nameservers.

If a secondary is not listed in the NS RRset then you can use also-notify as Anand said.

Brian Cuttler

ITG - Information Technology Group, Network and System Administrator
Wadsworth Center, NYS Department of Health
Empire State Plaza, Albany, NY 12201
[phone] | ***@health.ny.gov


_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone] INTERNET: ***@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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Cuttler, Brian R (HEALTH) via bind-users]

Mark, Dan,

Thank you both.
I was so very sure that I'd missed something and with your correctly pointing out I'd missed an NS record I was able to find and correct the issue.

My static zones were written correctly but my dynamic zones were in fact missing the NS resource record the made the secondary authoritative and as a result was not notifying for dynamic changes.

Thank you very much,
Brian

-----Original Message-----
From: Mark Andrews <***@isc.org>
Sent: Tuesday, June 1, 2021 9:24 PM
To: Cuttler, Brian R (HEALTH) <***@health.ny.gov>
Cc: bind-***@lists.isc.org
Subject: Re: configure notify for ixfer?

ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails.


> On 2 Jun 2021, at 01:18, Cuttler, Brian R (HEALTH) via bind-users <bind-***@lists.isc.org> wrote:
>
> My dns secondary is often behind on its dynamic zone tables.
> It looks to me like we are doing automatic transfer IXFR but not requently enough, but randomly.
>
> It looks to me that default 10 second interval for min transfer wait time.
>
> I'm missing something but haven't found the magic yet.
>
> Both primary/secondary BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.5 on Centos 7.9.
>
> Goal is to have dynamic entries replicated on the secondary within a few minutes if not a few seconds.
>
> From what I’m reading I should be sending a notify from the primary to the secondary when a dynamic zone is updated but I don’t seem to be doing that.
>
> Would someone please point me to the option I’m missing to do so? I’ve either completely missed it, mis-understood what I read or am going in the wrong direction.
>
> 01-Jun-2021 07:49:05.425 xfer-out: client @0x7f17335f9450 10.50.156.70#45583 (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR started (serial 1501355783 -> 1501355796)
> 01-Jun-2021 07:49:05.426 xfer-out: client @0x7f17335f9450 10.50.156.70#45583 (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR ended
> 01-Jun-2021 08:46:52.595 xfer-out: client @0x7f17334a7e80 10.50.156.70#39191 (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR started (serial 1501355796 -> 1501355835)
> 01-Jun-2021 08:46:52.596 xfer-out: client @0x7f17334a7e80 10.50.156.70#39191 (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR ended
> 01-Jun-2021 09:35:10.776 xfer-out: client @0x7f1732f45d60 10.50.156.70#39230 (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR started (serial 1501355835 -> 1501355858)
> 01-Jun-2021 09:35:10.776 xfer-out: client @0x7f1732f45d60 10.50.156.70#39230 (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR ended
>
> Thanks in advance,
> Brian

Named uses the NS records for the zone to find the addresses of the secondary servers to send the NOTIFY messages to. Both primary and secondary servers do this by default. The nameserver listed in the SOA record MNAME field is excluded this process. Ensure you have address record for all your nameservers.

If a secondary is not listed in the NS RRset then you can use also-notify as Anand said.

> Brian Cuttler
>
> ITG - Information Technology Group, Network and System Administrator
> Wadsworth Center, NYS Department of Health
> Empire State Plaza, Albany, NY 12201
> [phone] | ***@health.ny.gov
>
>
> _______________________________________________
> Please visit https://protect2.fireeye.com/v1/url?k=8f65c3b5-d0fefa91-8f673a80-000babd9f8b3-d6808c41e68e0cd5&q=1&e=4f4b3cdc-575a-4936-891d-c4a4e8046fba&u=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-users to unsubscribe from this list
>
> ISC funds the development of this software with paid support subscriptions. Contact us at https://protect2.fireeye.com/v1/url?k=092146da-56ba7ffe-0923bfef-000babd9f8b3-2fc9fe389296b63e&q=1&e=4f4b3cdc-575a-4936-891d-c4a4e8046fba&u=https%3A%2F%2Fwww.isc.org%2Fcontact%2F for more information.
>
>
> bind-users mailing list
> bind-***@lists.isc.org
> https://protect2.fireeye.com/v1/url?k=1ca916b3-43322f97-1cabef86-000babd9f8b3-069582d2fad357d5&q=1&e=4f4b3cdc-575a-4936-891d-c4a4e8046fba&u=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-users

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone] INTERNET: ***@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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-user