<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello Crist,</p>
<p>I have implemented the recommended changes. It works forward and
reverse for the test record, from out domain or others, or for
almost all of the test records.</p>
<p>There are still some spurious failures, such as this one:</p>
<p>200 IN CNAME 200.186.198.193.dhcp.slava.alu.hr.<br>
201 IN CNAME 201.186.198.193.dhcp.slava.alu.hr.<br>
</p>
<p>nslookup 193.198.186.200 works and .201 doesn't, despite the
symmetric definition:</p>
<p><font face="monospace">root@domac:/etc/bind/zones# nslookup
193.198.186.200<br>
200.186.198.193.in-addr.arpa canonical name =
200.192/27.186.198.193.in-addr.arpa.<br>
200.192/27.186.198.193.in-addr.arpa canonical name =
200.186.198.193.dhcp.slava.alu.hr.<br>
200.186.198.193.dhcp.slava.alu.hr name =
test-record1.slava.alu.hr.<br>
<br>
Authoritative answers can be found from:<br>
186.198.193.dhcp.slava.alu.hr nameserver = domac.alu.hr.<br>
domac.alu.hr internet address = 161.53.235.3<br>
<br>
root@domac:/etc/bind/zones# nslookup 193.198.186.201<br>
** server can't find 201.186.198.193.in-addr.arpa: NXDOMAIN<br>
<br>
root@domac:/etc/bind/zones#<br>
</font></p>
<p>I can't get to the bottom of this, I don't know enough BIND9
internals.</p>
<p>It will take real-life production load tomorrow to see how this
will behave with DHCP DDNS updates. :-)</p>
<p>You said ABSOLUTELY NO WARRANTY but I am an open source fan and I
can live with that ;-)</p>
<p>Until tomorrow, then ...</p>
<p>Kind regards,<br>
Mirsad Todorovac<br>
</p>
<div class="moz-cite-prefix">On 12/12/2021 10:33 AM, Mirsad Goran
Todorovac wrote:<br>
</div>
<blockquote type="cite"
cite="mid:d7af0834-0707-ce78-a475-ad74a2919d67@alu.unizg.hr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Hi Crist,</p>
<p>Now the resolution from the problematic record started working
again without any change in zones or BIND9 options, also without
the server process restart ... :-/</p>
<p><font face="monospace">root@domac:~# nslookup -query=any
195.192/27.186.198.193.in-addr.arpa.<br>
Server: 161.53.235.3<br>
Address: 161.53.235.3#53<br>
<br>
195.192/27.186.198.193.in-addr.arpa name =
test-record.slava.alu.hr.<br>
<br>
root@domac:~# nslookup -query=ptr 193.198.186.195<br>
Server: 161.53.235.3<br>
Address: 161.53.235.3#53<br>
<br>
Non-authoritative answer:<br>
195.186.198.193.in-addr.arpa canonical name =
195.192/27.186.198.193.in-addr.arpa.<br>
195.192/27.186.198.193.in-addr.arpa name =
test-record.slava.alu.hr.<br>
<br>
Authoritative answers can be found from:<br>
192/27.186.198.193.in-addr.arpa nameserver = domac.alu.hr.<br>
domac.alu.hr internet address = 161.53.235.3<br>
<br>
root@domac:~#<br>
</font></p>
<p>I guess this was something with timeouts. Suppose this will
work satisfactory on desktops that usually keep the same IP
address assigned by DHCP across the lease renewals, but not for
laptops, Android and iPhone devices that connect and disconnect,
and change network ...</p>
<p>Why I want smartphones to have reverse PTRs is to see in logs
if something becomes virus infected or even spambot, and not
have to browse DHCP leases in forensic analysis, which my fellow
administrator probably would not know how to do ...</p>
<p>Kind regards,<br>
Mirsad Todorovac<br>
</p>
<div class="moz-cite-prefix">On 12/12/2021 10:19 AM, Mirsad Goran
Todorovac wrote:<br>
</div>
<blockquote type="cite"
cite="mid:3403fe48-f49f-36e0-e696-e92cf8d00854@alu.unizg.hr">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>Hi Crist,</p>
<p>Thank you for your explanation. It was much appreciated.<br>
However, as I previously asserted, it is impossible to know
how the system will behave without testing it with real life
production load on Monday :-)<br>
</p>
<div class="moz-cite-prefix">On 12/11/2021 11:18 PM, Crist Clark
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAAcrURJfm2dmY_5qYkXzj3AMf6=p6wbDquPK+3f6Rc+0R==1nQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div dir="ltr">
<div dir="ltr">Looks like you're trying to use the setup in
that serverfault link. That example only works on an
internal network.</div>
</div>
</blockquote>
I thought the 186.198.193. part was enough to make the zone
unique. But your assertion is correct: I would collide if any
other administrators on other subnets in range 193.198.186.0/24
decide to make reverse DHCP DDNS update in the future. Thanks
for the thought!<br>
<blockquote type="cite"
cite="mid:CAAcrURJfm2dmY_5qYkXzj3AMf6=p6wbDquPK+3f6Rc+0R==1nQ@mail.gmail.com">
<div dir="ltr">
<div>The point of the example I gave is that you are going
to build your own reverse zone inside of a zone you
control on the Internet. Now that you've given some
examples, I can perhaps make it more obvious what I'm
suggesting. Your DNS zone would look something like,</div>
<div><br>
</div>
<div>
<blockquote type="cite">
<p>$ORIGIN 192-27.186.198.193.in-addr.arpa.<br>
<br>
@ IN NS <a href="http://domac.alu.hr/"
target="_blank" moz-do-not-send="true">domac.alu.hr</a>.<br>
@ IN NS <a
href="http://bjesomar.srce.hr/" target="_blank"
moz-do-not-send="true">bjesomar.srce.hr</a>.<br>
<br>
195 IN PTR <a
href="http://test-record.slava.alu.hr/"
target="_blank" moz-do-not-send="true">test-record.dhcp.slava.alu.hr</a>.<br>
<br>
$GENERATE 200-222 $ CNAME $.<a
href="http://186.198.193.dhcp.slava.alu.hr"
moz-do-not-send="true">186.198.193.dhcp.slava.alu.hr</a>.</p>
</blockquote>
</div>
<div><br>
</div>
<div>And your DHCP configuration,</div>
<div>
<blockquote type="cite">
<p> ddns-domainname "<a href="http://slava.alu.hr/"
target="_blank" moz-do-not-send="true">slava.alu.hr</a>";<br>
ddns-rev-domainname "<a
href="http://dhcp.slaval.alu.hr"
moz-do-not-send="true">dhcp.slaval.alu.hr</a>";<br>
zone <a href="http://slava.alu.hr/" target="_blank"
moz-do-not-send="true">slava.alu.hr</a>. {<br>
primary 127.0.0.1;<br>
key DDNS_UPDATE;<br>
}</p>
</blockquote>
</div>
<div>NOT TESTED. NO GUARANTEES. NOT SUITABLE FOR ANY GIVEN
PURPOSE. YOUR MILEAGE MAY VARY. PLEASE CONSULT YOUR
PERSONAL PHYSICIAN BEFORE STARTING ISC PRODUCTS.</div>
</div>
</blockquote>
Noted. :-) I am not afraid of experimenting. But failures of the
experimental setup are perceived as my incompetence, and success
taken for granted the very next day ;-)<br>
<blockquote type="cite"
cite="mid:CAAcrURJfm2dmY_5qYkXzj3AMf6=p6wbDquPK+3f6Rc+0R==1nQ@mail.gmail.com">
<div dir="ltr">
<div>One other odd thing, sometimes you refer to a
"192/27.186.198.193.in-addr.arpa" zone and sometimes
"192-27.186.198.193.in-addr.arpa." Those are different
names and are not interchangeable. Both are totally fine
for use in DNS, but a lot of administrators don't like the
'/' in zone names since they often use the zone name in
file names. Slashes present a problem in file names on
*nix flavored OSes. I used the dash, '-', version in my
example.</div>
</div>
</blockquote>
<p>This setup is mandated from the upper level sysadmins and I
cannot control it, I can only beg them to use a hyphen as in
RFC 2317 chapter 4 last paragraph, but I cannot guarantee that
they will change it. It is their arbitrary decision. :-/</p>
<p>Frankly, /27 is more readable, but if it creates havoc in
Linux resolver, then what the heck ...</p>
<p>Thank you very much again for your advice. I will post back
here on the results with your recommended zone setup.</p>
<p>Kind regards,<br>
Mirsad Todorovac<br>
</p>
<blockquote type="cite"
cite="mid:CAAcrURJfm2dmY_5qYkXzj3AMf6=p6wbDquPK+3f6Rc+0R==1nQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi again,</p>
<p>I had some luck in making this setup work. So far,
so good ... However, there's no telling how the DHCP
DDNS will function with the new 186.198.193.dhcp.
zone before Monday morning when the subsidiary
computers power up.</p>
<p>However, I have an odd behavior which I cannot
explain: without any change to zone a reverse
resolution stopped working. The setup just doesn't
seem stable enough to work with DHCP-updated dynamic
DNS in our organization, with a lot of smartphones
and wireless devices frequently signing on and off.</p>
<p>The zone is:</p>
<p><font face="monospace">$ORIGIN
192/27.186.198.193.in-addr.arpa.<br>
<br>
@ IN NS <a
href="http://domac.alu.hr" target="_blank"
moz-do-not-send="true">domac.alu.hr</a>.<br>
;@ IN NS <a
href="http://bjesomar.srce.hr" target="_blank"
moz-do-not-send="true">bjesomar.srce.hr</a>.<br>
<br>
195 IN PTR <a
href="http://test-record.slava.alu.hr"
target="_blank" moz-do-not-send="true">test-record.slava.alu.hr</a>.<br>
<br>
200 IN CNAME 200.186.198.193.dhcp.<br>
201 IN CNAME 201.186.198.193.dhcp.<br>
</font><br>
; MT 20211211:<br>
; Here's the magic:<br>
<br>
$GENERATE 202-222 $ CNAME $.186.198.193.dhcp.<br>
<br>
The command output shows that resolution succeeds,
but nslookup can't finish it for some unknown
spurious reason.</p>
<p><font face="monospace">root@domac:~# nslookup
-query=any 195.192/27.186.198.193.in-addr.arpa.<br>
Server: 161.53.235.3<br>
Address: 161.53.235.3#53<br>
<br>
195.192/27.186.198.193.in-addr.arpa name = <a
href="http://test-record.slava.alu.hr"
target="_blank" moz-do-not-send="true">test-record.slava.alu.hr</a>.<br>
<br>
root@domac:~# nslookup -query=ptr 193.198.186.195<br>
Server: 161.53.235.3<br>
Address: 161.53.235.3#53<br>
<br>
** server can't find 195.186.198.193.in-addr.arpa:
NXDOMAIN<br>
<br>
root@domac:~#<br>
</font></p>
<p>This kind of setup that sometimes works and
sometimes doesn't will make me look incompetent.<br>
I know that BIND 9 is great open source server with
lots of bells and whistles. But right now I can't
study all those and I just want to survive,
providing a solution fast enough for our uplevel
sysadmins.</p>
<p>The /etc/bind/named.conf.local part looks like:</p>
<p><font face="monospace">zone
"192/27.186.198.193.in-addr.arpa" in {<br>
type master;<br>
file
"/etc/bind/zones/192-27.186.198.193.in-addr.arpa.db";<br>
};<br>
<br>
zone "186.198.193.dhcp" in {<br>
type master;<br>
file
"/var/cache/bind/186.198.193.dhcp.db";<br>
allow-update { key DDNS_UPDATE; };<br>
};<br>
</font><br>
</p>
<p>What possibly could be killing the name resolution
between resolving
195.192/27.186.198.193.in-addr.arpa to <a
href="http://test-record.slava.alu.hr"
target="_blank" moz-do-not-send="true">test-record.slava.alu.hr</a>.
and resolving 193.198.186.195 that apparently fails?</p>
<div>Is there a way to see more interim debugging
output?</div>
<div><br>
</div>
<div>Thank you very much.</div>
<div><br>
</div>
<div>Kind regards,<br>
Mirsad Todorovac</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>On 12/11/2021 10:25 AM, Mirsad Goran Todorovac
wrote:<br>
</div>
<blockquote type="cite">
<p>Hi Crist,</p>
<p>Thank you for your reply and the information
provided.</p>
<p>I have roughly implemented this workaround. I was
hoping there was a way to instruct BIND to
masquerade a delegated domain with data from
another (dynamically updated from ISC DHCP) zone.<br>
</p>
<p>More accurately, my (from upper level) mandated
delegation is the literal
192/27.186.198.193.in-addr.arpa, using
192-27.186.198.193.in-addr.arpa says "ignoring
records outside of the origin" or something like
that.</p>
<p>I have used the following records in the zone:</p>
<p>$ORIGIN 192/27.186.198.193.in-addr.arpa.<br>
<br>
@ IN NS <a
href="http://domac.alu.hr" target="_blank"
moz-do-not-send="true">domac.alu.hr</a>.<br>
@ IN NS <a
href="http://bjesomar.srce.hr" target="_blank"
moz-do-not-send="true">bjesomar.srce.hr</a>.<br>
<br>
195 IN PTR <a
href="http://test-record.slava.alu.hr"
target="_blank" moz-do-not-send="true">test-record.slava.alu.hr</a>.<br>
<br>
$GENERATE 200-222 $ CNAME $.186.198.193.dhcp.<br>
</p>
<p>/etc/dhcp/dhcpd.conf has this:</p>
<p> ddns-domainname "<a href="http://slava.alu.hr"
target="_blank" moz-do-not-send="true">slava.alu.hr</a>";<br>
ddns-rev-domainname "dhcp";<br>
zone <a href="http://slava.alu.hr"
target="_blank" moz-do-not-send="true">slava.alu.hr</a>.
{<br>
primary 127.0.0.1;<br>
key DDNS_UPDATE;<br>
}<br>
zone 186.198.193.dhcp. {<br>
primary 127.0.0.1;<br>
key DDNS_UPDATE;<br>
}<br>
<br>
However, don't I have to convince people managing
<a href="http://bjesomar.srce.hr" target="_blank"
moz-do-not-send="true">bjesomar.srce.hr</a> to
be a slave server for the "186.198.193.dhcp" zone?
Or the dynamically updated reverse PTR record will
have effect only in my local domain (which I had
even before the entire setup), won't it?</p>
<p>Also, I get spurious REFUSED or NXDOMAIN errors,
some pass with time, so there must be some TTL or
timeout.<br>
</p>
<p>Kind regards,</p>
<p>Mirsad<br>
</p>
<div>On 12/11/2021 6:04 AM, Crist Clark wrote:<br>
</div>
<blockquote type="cite">
<div dir="auto">No idea if this is the best way.
It is a way.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Do you control any other zone?
Let’s say you own “example.com.” You can tell
ISC DHCP to build the reverse zone at an
arbitrary base name instead of in-addr.arpa.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Configure DHCP to put the reverse
records at say, “rev.example.com.” So you’ll get
records at,</div>
<div dir="auto"><br>
</div>
<div dir="auto"><a
href="http://193.186.198.193.rev.example.com"
target="_blank" moz-do-not-send="true">193.186.198.193.rev.example.com</a></div>
<div dir="auto"><a
href="http://194.186.198.193.rev.example.com"
target="_blank" moz-do-not-send="true">194.186.198.193.rev.example.com</a></div>
<div dir="auto">…</div>
<div dir="auto"><br>
</div>
<div dir="auto">And in your RFC 2317-style
delegation, you then enumerate another CNAME
layer,</div>
<div dir="auto"><br>
</div>
<div dir="auto">$ORIGIN
192-27.186.198.193.in-addr.arpa.</div>
<div dir="auto">193 IN CNAME <a
href="http://193.186.198.193.rev.example.com"
target="_blank" moz-do-not-send="true">193.186.198.193.rev.example.com</a>.</div>
<div dir="auto">194 IN CNAME <a
href="http://194.186.198.193.rev.example.com"
target="_blank" moz-do-not-send="true">194.186.198.193.rev.example.com</a>.</div>
<div dir="auto">…</div>
<div dir="auto"><br>
<div class="gmail_quote" dir="auto">
<div dir="ltr" class="gmail_attr">On Fri, Dec
10, 2021 at 2:51 PM Mirsad Goran Todorovac
<<a
href="mailto:mirsad.todorovac@alu.unizg.hr"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">mirsad.todorovac@alu.unizg.hr</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p><font
style="font-family:monospace;color:rgb(0,0,0)"
face="monospace">Hello,</font></p>
<p><font
style="font-family:monospace;color:rgb(0,0,0)"
face="monospace">I have a problem with
DHCP DDNS update to BIND 9 reverse PTR
zone subnet that is owned by several
organizations, so I can't get a direct
DHCP DDNS update access with a key or
with hostname.</font></p>
<p><font
style="font-family:monospace;color:rgb(0,0,0)"
face="monospace">I have been delegated
domain name <code
style="font-family:monospace">192-27.186.198.193.in-addr.arpa
from the upper level admins, and
that appears to be immutable.</code></font></p>
<p><code style="font-family:monospace">However,
my subnet is <a
href="http://193.198.186.192/27"
style="font-family:monospace"
target="_blank"
moz-do-not-send="true">193.198.186.192/27</a>,
and DHCP only knows how to perform
DDNS update to
186.198.193.in-addr.arpa. (See here: <a
href="https://serverfault.com/questions/806875/how-to-tell-isc-dhcp-correct-zone-for-reverse-zone-ddns-update"
style="font-family:monospace"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://serverfault.com/questions/806875/how-to-tell-isc-dhcp-correct-zone-for-reverse-zone-ddns-update</a>
and here: <a
href="https://lists.isc.org/mailman/htdig/dhcp-users/2006-August/001422.html"
style="font-family:monospace"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.isc.org/mailman/htdig/dhcp-users/2006-August/001422.html</a>
).<br>
</code></p>
<p><code style="font-family:monospace">(This
setup is because we have DHCP
addresses that are not over NAT, but
/24 subnet is shared with other
organizations, even under another
Minstry.)</code></p>
<p><code style="font-family:monospace">I
want to have the effect of delegating
the same database to upper level under
their zone name, while updating the
same database under my DHCP-understood
zone name.</code></p>
<p><code style="font-family:monospace">I
tried this /etc/bind/named.conf.local:</code></p>
<pre style="font-family:monospace"><code style="font-family:monospace">zone "192-27.186.198.193.in-addr.arpa" in {
type master;
file "/var/cache/bind/192-27.186.198.193.in-addr.arpa.db";
};
zone "186.198.193.in-addr.arpa" in {
type master;
file "/var/cache/bind/192-27.186.198.193.in-addr.arpa.db";
allow-update { key DDNS_UPDATE; };
};
</code></pre>
<font
style="font-family:monospace;color:rgb(0,0,0)"
face="monospace"> </font>
<p><font
style="font-family:monospace;color:rgb(0,0,0)"
face="monospace">(Two zones with the
same file.)</font></p>
<font
style="font-family:monospace;color:rgb(0,0,0)"
face="monospace"> </font>
<p><font
style="font-family:monospace;color:rgb(0,0,0)"
face="monospace">What I got was:</font></p>
<font
style="font-family:monospace;color:rgb(0,0,0)"
face="monospace"> </font>
<pre style="font-family:monospace"><code style="font-family:monospace">root@domac:/etc/bind# named-checkconf
/etc/bind/named.conf.local:49: writeable file '/var/cache/bind/192-27.186.198.193.in-addr.arpa.db': already in use: /etc/bind/named.conf.local:44
root@domac:/etc/bind#
Can you please tell me is there a way to achieve the effect of the above (illegal) setup?
I can't change DHCP nor I know an option to tell it to accept update to </code><code style="font-family:monospace"><code style="font-family:monospace">192-27.186.198.193.in-addr.arpa</code>
(it is a syntax error).
The DHCP dhcpd.conf subnet configuration is:
</code><code style="font-family:monospace"><code style="font-family:monospace">subnet 193.198.186.192 netmask 255.255.255.224 {
range 193.198.186.200 193.198.186.222; # MT 20211210
option subnet-mask 255.255.255.224;
option domain-name-servers 161.53.235.3, 161.53.2.70;
option domain-name "<a href="http://slava.alu.hr" style="font-family:monospace" target="_blank" moz-do-not-send="true">slava.alu.hr</a>";
ddns-domainname "<a href="http://slava.alu.hr" style="font-family:monospace" target="_blank" moz-do-not-send="true">slava.alu.hr</a>";
zone <a href="http://slava.alu.hr" style="font-family:monospace" target="_blank" moz-do-not-send="true">slava.alu.hr</a>. {
primary 127.0.0.1;
key DDNS_UPDATE;
}
zone 186.198.193.in-addr.arpa. {
primary 127.0.0.1;
key DDNS_UPDATE;
}
option broadcast-address 193.198.186.223;
option routers 193.198.186.193;
default-lease-time 43200;
max-lease-time 86400;
}
</code>
Thank you very much for your time reading this mail and help.
Kind regards,
--
Mirsad Goran Todorovac
Academy of Fine Arts | Faculty of Graphic Arts
University of Zagreb
</code></pre>
</div>
_______________________________________________<br>
Please visit <a
href="https://lists.isc.org/mailman/listinfo/bind-users"
rel="noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.isc.org/mailman/listinfo/bind-users</a>
to unsubscribe from this list<br>
<br>
ISC funds the development of this software
with paid support subscriptions. Contact us
at <a href="https://www.isc.org/contact/"
rel="noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.isc.org/contact/</a>
for more information.<br>
<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">bind-users@lists.isc.org</a><br>
<a
href="https://lists.isc.org/mailman/listinfo/bind-users"
rel="noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote>
</div>
</div>
</blockquote>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://www.isc.org/contact/</a> for more information.
bind-users mailing list
<a href="mailto:bind-users@lists.isc.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">bind-users@lists.isc.org</a>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.isc.org/mailman/listinfo/bind-users</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
Please visit <a
href="https://lists.isc.org/mailman/listinfo/bind-users"
rel="noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.isc.org/mailman/listinfo/bind-users</a>
to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid
support subscriptions. Contact us at <a
href="https://www.isc.org/contact/" rel="noreferrer"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.isc.org/contact/</a>
for more information.<br>
<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">bind-users@lists.isc.org</a><br>
<a
href="https://lists.isc.org/mailman/listinfo/bind-users"
rel="noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote>
</div>
</div>
</blockquote>
</blockquote>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Please visit <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list
ISC funds the development of this software with paid support subscriptions. Contact us at <a class="moz-txt-link-freetext" href="https://www.isc.org/contact/">https://www.isc.org/contact/</a> for more information.
bind-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a>
</pre>
</blockquote>
</body>
</html>