Message "Loop detected resolving..." and different query-behavior after flushing a cache entry
Hi list Using BIND-9.19.10: An A-query on our resolver for "ns2.comtronic.ch" causes the following info in the named.log, after the first response was answered to the client and cached and then the entry is flushed from cache with "rndc flushname ns2.comtronic.ch": 21-Feb-2023 09:23:15.463 resolver: info: loop detected resolving 'ns2.comtronic.ch/A' The appropriate tcpdump for BIND-9.19.10 while the loop is detected looks like this (after flushing the cached name with "rndc flushname ns2.comtronic.ch"): # Client query 09:27:25.957381 IP 10.100.2.62.54792 > 10.100.102.21.53: 4744+ [1au] A? ns2.comtronic.ch. (57) # Query from the resolver to the authoritative server for A 09:27:25.957984 IP6 2001:db8::affe.20495 > 2a02:1368:1:47::53.53: 50231 [1au] A? ns2.comtronic.ch. (45) # Querying TLD nameserver for A and 09:27:25.958177 IP6 2001:db8::affe.13748 > 2001:678:3::1.53: 9026% [1au] ? ns2.comtronic.ch. (45) 09:27:25.958283 IP6 2001:db8::affe.2773 > 2001:678:3::1.53: 20217% [1au] A? ns2.comtronic.ch. (45) # Response from the authoritative 09:27:25.958684 IP6 2a02:1368:1:47::53.53 > 2001:db8::affe.20495: 50231*- 1/0/1 A 195.200.242.162 (61) # Response back to the client 09:27:25.958915 IP 10.100.102.21.53 > 10.100.2.62.54792: 4744 1/0/1 A 195.200.242.162 (89) # Delegations back from the TLD nameserver for the A and query 09:27:25.960140 IP6 2001:678:3::1.53 > 2001:db8::affe.13748: 9026- 0/10/10 (695) 09:27:25.960284 IP6 2001:678:3::1.53 > 2001:db8::affe.2773: 20217- 0/10/10 (695) # Query against another authoritative for A and 09:27:25.960516 IP6 2001:db8::affe.30306 > 2a02:1368:1:48::53.53: 6112% [1au] ? ns2.comtronic.ch. (45) 09:27:25.960543 IP6 2001:db8::affe.5267 > 2a02:1368:1:48::53.53: 8517% [1au] A? ns2.comtronic.ch. (45) # Answer back from the authoritative (no record found for "ns2.comtronic.ch) 09:27:25.961284 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.5267: 8517*- 1/0/1 A 195.200.242.162 (61) 09:27:25.961374 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.30306: 6112*- 0/1/1 (96) BIND-9.19.10 behaves differently to BIND-9.18.12 regarding -Lookups. BIND-9.18.12 doesn't query for lookup after flushing the name, where BIND-9.19.10 always does with the same configuration..., why? See below, here is the appropriate tcpdump with BIND-9.18.12 for a enforced "loop detection resolving" info (after flushing the name with "rndc flushname ns2.comtronic.ch"): # Query from the client 09:36:34.242064 IP 10.100.2.62.59765 > 10.100.102.21.53: 58600+ [1au] A? ns2.comtronic.ch. (57) # Query from the resolver to the authoritative 09:36:34.242787 IP6 2001:db8::affe.4717 > 2a02:1368:1:48::53.53: 26321 [1au] A? ns2.comtronic.ch. (45) # Query from the resolver to the TLD server 09:36:34.242880 IP6 2001:db8::affe.25272 > 2001:620:0:ff::56.53: 50695% [1au] A? ns2.comtronic.ch. (45) # Response back from the authoritative server 09:36:34.243673 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.4717: 26321*- 1/0/1 A 195.200.242.162 (61) # Response back to the client 09:36:34.243841 IP 10.100.102.21.53 > 10.100.2.62.59765: 58600 1/0/1 A 195.200.242.162 (89) # Delegation answer from the TLD server 09:36:34.244556 IP6 2001:620:0:ff::56.53 > 2001:db8::affe.25272: 50695- 0/10/10 (695) # A 2nd query to the same authoritative 09:36:34.244750 IP6 2001:db8::affe.18083 > 2a02:1368:1:48::53.53: 21395% [1au] A? ns2.comtronic.ch. (45) # 2nd response back from the authoritative server 09:36:34.245246 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.18083: 21395*- 1/0/1 A 195.200.242.162 (61) The info "loop detected resolving" is always reproducable in BIND-9.19.10 after flushing the name "ns2.comtronic.ch", but only sporadic in BIND-9.18.12. So my questions are: - What does "loop detected resolving 'ns2.comtronic.ch/A' means here? - Why is "loop detected resolving 'ns2.comtronic.ch/A'" always reproducable in BIND-9.19.10 and sporadic in BIND-9.18.12? - Why does BIND-9.19.10 behaves differently to BIND-9.18.12 regarding lookups after flushing the name "ns2.comtronic.ch"? - BIND-9.19.10 does A and lookups after flushing the name "ns2.comtronic.ch", where BIND-9.18.12 only queries for A records Many thanks for any hints. Best regards, Tom -- 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: Message "Loop detected resolving..." and different query-behavior after flushing a cache entry
Tom, the ADB (Address DataBase) responsible for caching the delegations had been heavily refactoring in 9.19 branch, I think the best course of action would be to fill a GitLab issue with the description, so we can follow-up there. 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. 2. 2023, at 10:03, Tom wrote: > > Hi list > > Using BIND-9.19.10: > > An A-query on our resolver for "ns2.comtronic.ch" causes the following info > in the named.log, after the first response was answered to the client and > cached and then the entry is flushed from cache with "rndc flushname > ns2.comtronic.ch": > 21-Feb-2023 09:23:15.463 resolver: info: loop detected resolving > 'ns2.comtronic.ch/A' > > > The appropriate tcpdump for BIND-9.19.10 while the loop is detected looks > like this (after flushing the cached name with "rndc flushname > ns2.comtronic.ch"): > > # Client query > 09:27:25.957381 IP 10.100.2.62.54792 > 10.100.102.21.53: 4744+ [1au] A? > ns2.comtronic.ch. (57) > > # Query from the resolver to the authoritative server for A > 09:27:25.957984 IP6 2001:db8::affe.20495 > 2a02:1368:1:47::53.53: 50231 [1au] > A? ns2.comtronic.ch. (45) > > > # Querying TLD nameserver for A and > 09:27:25.958177 IP6 2001:db8::affe.13748 > 2001:678:3::1.53: 9026% [1au] > ? ns2.comtronic.ch. (45) > 09:27:25.958283 IP6 2001:db8::affe.2773 > 2001:678:3::1.53: 20217% [1au] A? > ns2.comtronic.ch. (45) > > # Response from the authoritative > 09:27:25.958684 IP6 2a02:1368:1:47::53.53 > 2001:db8::affe.20495: 50231*- > 1/0/1 A 195.200.242.162 (61) > > # Response back to the client > 09:27:25.958915 IP 10.100.102.21.53 > 10.100.2.62.54792: 4744 1/0/1 A > 195.200.242.162 (89) > > > # Delegations back from the TLD nameserver for the A and query > 09:27:25.960140 IP6 2001:678:3::1.53 > 2001:db8::affe.13748: 9026- 0/10/10 > (695) > 09:27:25.960284 IP6 2001:678:3::1.53 > 2001:db8::affe.2773: 20217- 0/10/10 > (695) > > > # Query against another authoritative for A and > 09:27:25.960516 IP6 2001:db8::affe.30306 > 2a02:1368:1:48::53.53: 6112% [1au] > ? ns2.comtronic.ch. (45) > 09:27:25.960543 IP6 2001:db8::affe.5267 > 2a02:1368:1:48::53.53: 8517% [1au] > A? ns2.comtronic.ch. (45) > > > # Answer back from the authoritative (no record found for > "ns2.comtronic.ch) > 09:27:25.961284 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.5267: 8517*- 1/0/1 > A 195.200.242.162 (61) > 09:27:25.961374 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.30306: 6112*- > 0/1/1 (96) > > > > BIND-9.19.10 behaves differently to BIND-9.18.12 regarding -Lookups. > BIND-9.18.12 doesn't query for lookup after flushing the name, where > BIND-9.19.10 always does with the same configuration..., why? > See below, here is the appropriate tcpdump with BIND-9.18.12 for a enforced > "loop detection resolving" info (after flushing the name with "rndc flushname > ns2.comtronic.ch"): > > # Query from the client > 09:36:34.242064 IP 10.100.2.62.59765 > 10.100.102.21.53: 58600+ [1au] A? > ns2.comtronic.ch. (57) > > # Query from the resolver to the authoritative > 09:36:34.242787 IP6 2001:db8::affe.4717 > 2a02:1368:1:48::53.53: 26321 [1au] > A? ns2.comtronic.ch. (45) > > # Query from the resolver to the TLD server > 09:36:34.242880 IP6 2001:db8::affe.25272 > 2001:620:0:ff::56.53: 50695% [1au] > A? ns2.comtronic.ch. (45) > > # Response back from the authoritative server > 09:36:34.243673 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.4717: 26321*- > 1/0/1 A 195.200.242.162 (61) > > # Response back to the client > 09:36:34.243841 IP 10.100.102.21.53 > 10.100.2.62.59765: 58600 1/0/1 A > 195.200.242.162 (89) > > # Delegation answer from the TLD server > 09:36:34.244556 IP6 2001:620:0:ff::56.53 > 2001:db8::affe.25272: 50695- > 0/10/10 (695) > > # A 2nd query to the same authoritative > 09:36:34.244750 IP6 2001:db8::affe.18083 > 2a02:1368:1:48::53.53: 21395% > [1au] A? ns2.comtronic.ch. (45) > > # 2nd response back from the authoritative server > 09:36:34.245246 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.18083: 21395*- > 1/0/1 A 195.200.242.162 (61) > > > > The info "loop detected resolving" is always reproducable in BIND-9.19.10 > after flushing the name "ns2.comtronic.ch", but only sporadic in BIND-9.18.12. > > So my questions are: > - What does "loop detected resolving 'ns2.comtronic.ch/A' means here? > - Why is "loop detected resolving 'ns2.comtronic.ch/A'" always reproducable > in BIND-9.19.10 and sporadic in BIND-9.18.12? > - Why does BIND-9.19.10 behaves differently to BIND-9.18.12 regarding > lookups after flushing the name "ns2.comtronic.ch"? >- BIND-9.19.10 does A and lookups after flushing the name > "ns2.comtronic.ch", where BIND-9.18.12 only queries for A records > > > Many thanks for any hints. > Best regards, > Tom > -- > Visit https://l
Re: Message "Loop detected resolving..." and different query-behavior after flushing a cache entry
Hi Ondrej I've created the issue: https://gitlab.isc.org/isc-projects/bind9/-/issues/3885 Best regards, Tom On 2/21/23 14:24, Ondřej Surý wrote: Tom, the ADB (Address DataBase) responsible for caching the delegations had been heavily refactoring in 9.19 branch, I think the best course of action would be to fill a GitLab issue with the description, so we can follow-up there. 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. 2. 2023, at 10:03, Tom wrote: Hi list Using BIND-9.19.10: An A-query on our resolver for "ns2.comtronic.ch" causes the following info in the named.log, after the first response was answered to the client and cached and then the entry is flushed from cache with "rndc flushname ns2.comtronic.ch": 21-Feb-2023 09:23:15.463 resolver: info: loop detected resolving 'ns2.comtronic.ch/A' The appropriate tcpdump for BIND-9.19.10 while the loop is detected looks like this (after flushing the cached name with "rndc flushname ns2.comtronic.ch"): # Client query 09:27:25.957381 IP 10.100.2.62.54792 > 10.100.102.21.53: 4744+ [1au] A? ns2.comtronic.ch. (57) # Query from the resolver to the authoritative server for A 09:27:25.957984 IP6 2001:db8::affe.20495 > 2a02:1368:1:47::53.53: 50231 [1au] A? ns2.comtronic.ch. (45) # Querying TLD nameserver for A and 09:27:25.958177 IP6 2001:db8::affe.13748 > 2001:678:3::1.53: 9026% [1au] ? ns2.comtronic.ch. (45) 09:27:25.958283 IP6 2001:db8::affe.2773 > 2001:678:3::1.53: 20217% [1au] A? ns2.comtronic.ch. (45) # Response from the authoritative 09:27:25.958684 IP6 2a02:1368:1:47::53.53 > 2001:db8::affe.20495: 50231*- 1/0/1 A 195.200.242.162 (61) # Response back to the client 09:27:25.958915 IP 10.100.102.21.53 > 10.100.2.62.54792: 4744 1/0/1 A 195.200.242.162 (89) # Delegations back from the TLD nameserver for the A and query 09:27:25.960140 IP6 2001:678:3::1.53 > 2001:db8::affe.13748: 9026- 0/10/10 (695) 09:27:25.960284 IP6 2001:678:3::1.53 > 2001:db8::affe.2773: 20217- 0/10/10 (695) # Query against another authoritative for A and 09:27:25.960516 IP6 2001:db8::affe.30306 > 2a02:1368:1:48::53.53: 6112% [1au] ? ns2.comtronic.ch. (45) 09:27:25.960543 IP6 2001:db8::affe.5267 > 2a02:1368:1:48::53.53: 8517% [1au] A? ns2.comtronic.ch. (45) # Answer back from the authoritative (no record found for "ns2.comtronic.ch) 09:27:25.961284 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.5267: 8517*- 1/0/1 A 195.200.242.162 (61) 09:27:25.961374 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.30306: 6112*- 0/1/1 (96) BIND-9.19.10 behaves differently to BIND-9.18.12 regarding -Lookups. BIND-9.18.12 doesn't query for lookup after flushing the name, where BIND-9.19.10 always does with the same configuration..., why? See below, here is the appropriate tcpdump with BIND-9.18.12 for a enforced "loop detection resolving" info (after flushing the name with "rndc flushname ns2.comtronic.ch"): # Query from the client 09:36:34.242064 IP 10.100.2.62.59765 > 10.100.102.21.53: 58600+ [1au] A? ns2.comtronic.ch. (57) # Query from the resolver to the authoritative 09:36:34.242787 IP6 2001:db8::affe.4717 > 2a02:1368:1:48::53.53: 26321 [1au] A? ns2.comtronic.ch. (45) # Query from the resolver to the TLD server 09:36:34.242880 IP6 2001:db8::affe.25272 > 2001:620:0:ff::56.53: 50695% [1au] A? ns2.comtronic.ch. (45) # Response back from the authoritative server 09:36:34.243673 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.4717: 26321*- 1/0/1 A 195.200.242.162 (61) # Response back to the client 09:36:34.243841 IP 10.100.102.21.53 > 10.100.2.62.59765: 58600 1/0/1 A 195.200.242.162 (89) # Delegation answer from the TLD server 09:36:34.244556 IP6 2001:620:0:ff::56.53 > 2001:db8::affe.25272: 50695- 0/10/10 (695) # A 2nd query to the same authoritative 09:36:34.244750 IP6 2001:db8::affe.18083 > 2a02:1368:1:48::53.53: 21395% [1au] A? ns2.comtronic.ch. (45) # 2nd response back from the authoritative server 09:36:34.245246 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.18083: 21395*- 1/0/1 A 195.200.242.162 (61) The info "loop detected resolving" is always reproducable in BIND-9.19.10 after flushing the name "ns2.comtronic.ch", but only sporadic in BIND-9.18.12. So my questions are: - What does "loop detected resolving 'ns2.comtronic.ch/A' means here? - Why is "loop detected resolving 'ns2.comtronic.ch/A'" always reproducable in BIND-9.19.10 and sporadic in BIND-9.18.12? - Why does BIND-9.19.10 behaves differently to BIND-9.18.12 regarding lookups after flushing the name "ns2.comtronic.ch"? - BIND-9.19.10 does A and lookups after flushing the name "ns2.comtronic.ch", where BIND-9.18.12 only queries for A records Many thanks for any hints. Best regards, Tom -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of
Is there an incompatibility between 9.16.37/9.18.11 and 9.9 when doing HMAC-MD5 AXFR?
Hi all
Due to circumstances beyond my control a remote partner needs to use a 9.9.9
version of bind and we are required to use HMAC-MD5 for zone transfers. There
is no (big) security concern since the networks are isolated and not exposed to
the larger Internet.
When the secondary requests an AXFR I see:
client @0x nnn.nnn.nnn.nnn#xx: request has invalid signature:
TSIG : tsig verify failure (BADSIG)
Doing a dig directly (with the same key) I get the zone:
client @0x nnn.nnn.nnn.nnn#xx /key (zone.tld): transfer
of 'zone.tld/IN': AXFR started: TSIG (serial )
Is there any known incompatibilities - preferably with workarounds :) - that
anyone knows about?
I apologize in advance if the info is lacking but here are, what I consider,
the relevant parts from named.conf:
key "." {
algorithm hmac-md5;
secret "XX";
};
acl servers {
nnn.nnn.nnn.nnn;
nnn.nnn.nnn.nnn;
nnn.nnn.nnn.nnn;
};
acl transfer {
!servers;
!localhost;
!nnn.nnn.nnn.nnn;
any;
};
zone "zone.tld." IN {
type master;
file "/etc/bind/zones/zone.file";
allow-transfer { !transfer; key .; };
};
Again - sorry if this is insufficient information.
It could be as simple as the remote not having everything in order but they
swear up and down that they have checked, doublechecked and enlisted multiple
persons in doing the checks.
I would appreciate any and all hints even if they are farfetched.
Best Regards
Patrik Graeser
--
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 incompatibility between 9.16.37/9.18.11 and 9.9 when doing HMAC-MD5 AXFR?
Hi Patrik. 9.9? Classic! :D
I don't believe there should be any incompatibilities. Are you perhaps
falling foul of this? From Cricket's book, chapter 11
It’s important that the name of the key—not just the binary data the key
points to— be identical on both ends of the transaction. If it’s not, the
recipient tries to verify the TSIG record and finds it doesn’t know the key
that the TSIG record says was used to compute the hash value. That causes
errors such as the following:
Jan 4 16:05:35 wormhole named[86705]: client 192.249.249.1#4666: request
has invalid signature: TSIG tsig-key.movie.edu: tsig verify failure
(BADKEY)
I'd take packet captures of both cases and compare them, see what the
differences are.
Hope that helps.
Greg
On Tue, 21 Feb 2023 at 16:06, Patrik.Graser--- via bind-users <
bind-users@lists.isc.org> wrote:
> Hi all
>
>
>
> Due to circumstances beyond my control a remote partner needs to use a
> 9.9.9 version of bind and we are required to use HMAC-MD5 for zone
> transfers. There is no (big) security concern since the networks are
> isolated and not exposed to the larger Internet.
>
>
>
> When the secondary requests an AXFR I see:
>
> client @0x nnn.nnn.nnn.nnn#xx: request has invalid
> signature: TSIG : tsig verify failure (BADSIG)
>
>
>
> Doing a dig directly (with the same key) I get the zone:
>
> client @0x nnn.nnn.nnn.nnn#xx /key (zone.tld):
> transfer of ‘zone.tld/IN': AXFR started: TSIG (serial )
>
>
>
> Is there any known incompatibilities – preferably with workarounds :) -
> that anyone knows about?
>
>
>
> I apologize in advance if the info is lacking but here are, what I
> consider, the relevant parts from named.conf:
>
>
>
> key "." {
>
> algorithm hmac-md5;
>
> secret "XX";
>
> };
>
>
>
> acl servers {
>
> nnn.nnn.nnn.nnn;
>
> nnn.nnn.nnn.nnn;
>
> nnn.nnn.nnn.nnn;
>
> };
>
>
>
> acl transfer {
>
> !servers;
>
> !localhost;
>
> !nnn.nnn.nnn.nnn;
>
> any;
>
> };
>
>
>
> zone "zone.tld." IN {
>
> type master;
>
> file "/etc/bind/zones/zone.file";
>
> allow-transfer { !transfer; key .; };
>
> };
>
>
>
> Again – sorry if this is insufficient information.
>
> It could be as simple as the remote not having everything in order but
> they swear up and down that they have checked, doublechecked and enlisted
> multiple persons in doing the checks.
>
>
>
> I would appreciate any and all hints even if they are farfetched.
>
>
>
> Best Regards
>
> Patrik Graeser
> --
> 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
limit the number of invalid domain queries
Hi , I have a DNS server using BIND 9.16 software. I have a phenomenon where there are many queries from different IPs to the subdomains of cosy.vn (these subdomains do not exist; the domain name cosy.vn is the main domain I am using). These queries cause an overload for my system. I have used IP blocking solution, but these IPs are many and constantly changing. I would like to ask is there a way to configure blocking of queries from those strange IPs to my subdomains? Thanks and looking forward to your support. Chinhlk -- 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: limit the number of invalid domain queries
It sounds like you are subject of a DoS attack or are being used in a DoS attack against someone else. Often the IP addresses are forged. In other cases they come from recursive servers that are also being abused. You can configure response rate limiting. https://bind9.readthedocs.io/en/v9_16_9/reference.html?highlight=Response%20rate%20limiting#response-rate-limiting You can also sign the zone using NSEC which will allow recursive servers that support DNSSEC synthesis to return responses for names that don’t exist without contacting your server as often. They need to contact you enough to build up the NSEC chain to be able to synthesis the NXDOMAIN response. > On 22 Feb 2023, at 13:32, Chinhlk wrote: > > Hi , > > I have a DNS server using BIND 9.16 software. > I have a phenomenon where there are many queries from different IPs to the > subdomains of cosy.vn (these subdomains do not exist; the domain name cosy.vn > is the main domain I am using). These queries cause an overload for my > system. I have used IP blocking solution, but these IPs are many and > constantly changing. > I would like to ask is there a way to configure blocking of queries from > those strange IPs to my subdomains? > > Thanks and looking forward to your support. > > Chinhlk > -- > 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 -- 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
