<div dir="ltr"><div>Chuck, Tony,</div><div><br></div><div>Thank you all for sharing the ideas.. very much appreciated.</div><div><br></div><div><div>Thank you</div>Kind Regards,<br>Ravi Kota <br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 7, 2021 at 7:25 PM <<a href="mailto:bind-users-request@lists.isc.org">bind-users-request@lists.isc.org</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">Send bind-users mailing list submissions to<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:bind-users-request@lists.isc.org" target="_blank">bind-users-request@lists.isc.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:bind-users-owner@lists.isc.org" target="_blank">bind-users-owner@lists.isc.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of bind-users digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: forwarding zone setup from a BIND slave (without<br>
recursion?) (Chuck Aurora)<br>
2. Re: forwarding zone setup from a BIND slave (without<br>
recursion?) (Tony Finch)<br>
3. Re: rndc stops listening (John Thurston)<br>
4. Re: rndc stops listening (Ond?ej Sur?)<br>
5. Re: forwarding zone setup from a BIND slave (without<br>
recursion?) (Mark Andrews)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 07 Apr 2021 07:53:01 -0500<br>
From: Chuck Aurora <<a href="mailto:ca@nodns4.us" target="_blank">ca@nodns4.us</a>><br>
To: <a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
Subject: Re: forwarding zone setup from a BIND slave (without<br>
recursion?)<br>
Message-ID: <<a href="mailto:a8f126db4876d2406054c6e65a12fe3f@nodns4.us" target="_blank">a8f126db4876d2406054c6e65a12fe3f@nodns4.us</a>><br>
Content-Type: text/plain; charset=US-ASCII; format=flowed<br>
<br>
On 2021-04-07 03:59, Marki wrote:<br>
> To elaborate a little bit on that... Indeed that is how it works,<br>
> unfortunately. When you start using forwarders or stubs, recursion<br>
> needs to be enabled because you're no longer looking for your own<br>
> authoritative data only.<br>
<br>
A stub or static-stub zone would not require recursion. In that case<br>
named is asking for authoritative data from upstream. But type<br>
forward zones indeed cannot work if recursion is disabled.<br>
<br>
> What I've learned from this list is that you should split<br>
> authoritative and recursive service.<br>
<br>
I would suggest that as a general best practice, but not an absolute<br>
one. There's nothing wrong with having internal-only authoritative<br>
zones on your recursive resolver. The potential problem comes when<br>
you're a globally-published NS for your zones; having recursion<br>
enabled can make you vulnerable to more possible attacks.<br>
<br>
I'd say it depends more who/what you are. Small-timers are not at so<br>
much risk for this than large sites and ISPs. But there too, the<br>
paranoid would go for two instances of named, authoritative and<br>
recursive, on a small hosted server even where it's only offering<br>
recursion to itself.<br>
<br>
> May I ask what is the reasoning behind your current setup (pointing<br>
> your users to the non-recursive service)? What would you like to<br>
> achieve? What would you like to prevent?<br>
<br>
Agreed, that is strange. It does not seem that an authoritative-only<br>
named can be very useful for end users.<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 7 Apr 2021 15:37:33 +0100<br>
From: Tony Finch <<a href="mailto:dot@dotat.at" target="_blank">dot@dotat.at</a>><br>
To: Chuck Aurora <<a href="mailto:ca@nodns4.us" target="_blank">ca@nodns4.us</a>><br>
Cc: <a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
Subject: Re: forwarding zone setup from a BIND slave (without<br>
recursion?)<br>
Message-ID: <<a href="mailto:cdbcf6e-f0c3-9ac4-ee7a-d0c237de602e@dotat.at" target="_blank">cdbcf6e-f0c3-9ac4-ee7a-d0c237de602e@dotat.at</a>><br>
Content-Type: text/plain; charset=US-ASCII<br>
<br>
Chuck Aurora <<a href="mailto:ca@nodns4.us" target="_blank">ca@nodns4.us</a>> wrote:<br>
><br>
> A stub or static-stub zone would not require recursion. In that case<br>
> named is asking for authoritative data from upstream. But type<br>
> forward zones indeed cannot work if recursion is disabled.<br>
<br>
Be careful in this kind of situation to be very clear about which client<br>
or server is doing what: in this case, it isn't clear what doesn't require<br>
recursion for stub or static stub.<br>
<br>
All three types of zone configuration (stub, static stub, and forward)<br>
are only useful on a server that is providing recursive service.<br>
<br>
Forward zones require the upstream server to be recursive too.<br>
<br>
Stub and static-stub expect the upstream server to be authoritative;<br>
the stub server list is a hint that gets replaced by the authoritative<br>
server list from the zone (a bit like the root hints) whereas static-stub<br>
only uses the configured upstream servers.<br>
<br>
> > What I've learned from this list is that you should split<br>
> > authoritative and recursive service.<br>
><br>
> I would suggest that as a general best practice, but not an absolute<br>
> one. There's nothing wrong with having internal-only authoritative<br>
> zones on your recursive resolver. The potential problem comes when<br>
> you're a globally-published NS for your zones; having recursion<br>
> enabled can make you vulnerable to more possible attacks.<br>
<br>
Right: the rule is that authoritative servers listed as targets of NS<br>
records should be authoritative-only; it's OK if recursive servers have<br>
authoritative copies of zones: it can make them more resilient to outages,<br>
though it does slightly weird things to DNSSEC validation.<br>
<br>
Tony.<br>
-- <br>
f.anthony.n.finch <<a href="mailto:dot@dotat.at" target="_blank">dot@dotat.at</a>> <a href="https://dotat.at/" rel="noreferrer" target="_blank">https://dotat.at/</a><br>
Whitby to Gibraltar Point: Northwest 4 to 6 becoming variable 2 to 4,<br>
then southwest 4 to 6 later. Very rough at first in north, otherwise<br>
moderate or rough. Snow showers, then rain for a time later. Good,<br>
occasionally very poor at first.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 7 Apr 2021 09:31:47 -0800<br>
From: John Thurston <<a href="mailto:john.thurston@alaska.gov" target="_blank">john.thurston@alaska.gov</a>><br>
To: <a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
Subject: Re: rndc stops listening<br>
Message-ID: <<a href="mailto:5df942c4-78b8-39be-2df5-33f5ea387e9b@alaska.gov" target="_blank">5df942c4-78b8-39be-2df5-33f5ea387e9b@alaska.gov</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
I now see this same behavior running BIND 9.16.12 on Ubuntu<br>
<br>
I have never seen it on my instances running 9.11.x on Centos<br>
<br>
I'd sure like to figure out why (or even when) it stops listening on <br>
port 953. Does anyone have any suggestions?<br>
<br>
--<br>
Do things because you should, not just because you can.<br>
<br>
John Thurston 907-465-8591<br>
<a href="mailto:John.Thurston@alaska.gov" target="_blank">John.Thurston@alaska.gov</a><br>
Department of Administration<br>
State of Alaska<br>
<br>
On 12/11/2020 11:13 AM, John Thurston wrote:<br>
> Running BIND 9.16.9 on CentOS 8<br>
> <br>
> I have the following in my .conf<br>
>> controls {<br>
>> ? inet 127.0.0.1 port 953<br>
>> ??? allow { 127.0.0.1; } keys { "mykey"; };<br>
>> ? inet 10.2.0.1 port 953<br>
>> ??? allow { 10.2.3.3; 10.2.4.3; }<br>
>> ??? keys { "threekey"; "fourkey"; };<br>
>> };<br>
> <br>
> And I normally can see the named process is listening on tcp:953 on both <br>
> 127.0.0.1 and 10.2.0.1.?? But sometimes later, I find it listening only <br>
> on 127.0.0.1.?? If I do an 'rndc reconfig', it starts listening again on <br>
> both addresses. Normal DNS service has continued uninterrupted.<br>
> <br>
> I can't find footprints left from anything falling down. I'd could just <br>
> install a watchdog to 'reconfig' whenever port 953 stops answering, but <br>
> I'd rather figure out why it is stopping and correct the problem. To do <br>
> that, I need more information.<br>
> <br>
> Am I not looking in the correct log?<br>
> Do I need to crank up the logging level for something?<br>
> If so, for what? and how high?<br>
> <br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Wed, 7 Apr 2021 19:46:59 +0200<br>
From: Ond?ej Sur? <<a href="mailto:ondrej@isc.org" target="_blank">ondrej@isc.org</a>><br>
To: John Thurston <<a href="mailto:john.thurston@alaska.gov" target="_blank">john.thurston@alaska.gov</a>><br>
Cc: <a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
Subject: Re: rndc stops listening<br>
Message-ID: <<a href="mailto:B9892FD6-D99B-4B3A-B51E-BD5470B97BA9@isc.org" target="_blank">B9892FD6-D99B-4B3A-B51E-BD5470B97BA9@isc.org</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
John,<br>
<br>
please report the issue to the ISC GitLab.<br>
<br>
Thanks,<br>
--<br>
Ond?ej Sur? ? ISC (He/Him)<br>
<br>
My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.<br>
<br>
> On 7. 4. 2021, at 19:32, John Thurston <<a href="mailto:john.thurston@alaska.gov" target="_blank">john.thurston@alaska.gov</a>> wrote:<br>
> <br>
> ?I now see this same behavior running BIND 9.16.12 on Ubuntu<br>
> <br>
> I have never seen it on my instances running 9.11.x on Centos<br>
> <br>
> I'd sure like to figure out why (or even when) it stops listening on port 953. Does anyone have any suggestions?<br>
> <br>
> --<br>
> Do things because you should, not just because you can.<br>
> <br>
> John Thurston 907-465-8591<br>
> <a href="mailto:John.Thurston@alaska.gov" target="_blank">John.Thurston@alaska.gov</a><br>
> Department of Administration<br>
> State of Alaska<br>
> <br>
>> On 12/11/2020 11:13 AM, John Thurston wrote:<br>
>> Running BIND 9.16.9 on CentOS 8<br>
>> I have the following in my .conf<br>
>>> controls {<br>
>>> inet 127.0.0.1 port 953<br>
>>> allow { 127.0.0.1; } keys { "mykey"; };<br>
>>> inet 10.2.0.1 port 953<br>
>>> allow { 10.2.3.3; 10.2.4.3; }<br>
>>> keys { "threekey"; "fourkey"; };<br>
>>> };<br>
>> And I normally can see the named process is listening on tcp:953 on both 127.0.0.1 and 10.2.0.1. But sometimes later, I find it listening only on 127.0.0.1. If I do an 'rndc reconfig', it starts listening again on both addresses. Normal DNS service has continued uninterrupted.<br>
>> I can't find footprints left from anything falling down. I'd could just install a watchdog to 'reconfig' whenever port 953 stops answering, but I'd rather figure out why it is stopping and correct the problem. To do that, I need more information.<br>
>> Am I not looking in the correct log?<br>
>> Do I need to crank up the logging level for something?<br>
>> If so, for what? and how high?<br>
> _______________________________________________<br>
> Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">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">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">bind-users@lists.isc.org</a><br>
> <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Thu, 8 Apr 2021 09:25:21 +1000<br>
From: Mark Andrews <<a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a>><br>
To: Tony Finch <<a href="mailto:dot@dotat.at" target="_blank">dot@dotat.at</a>><br>
Cc: Chuck Aurora <<a href="mailto:ca@nodns4.us" target="_blank">ca@nodns4.us</a>>, <a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
Subject: Re: forwarding zone setup from a BIND slave (without<br>
recursion?)<br>
Message-ID: <<a href="mailto:8F2E2C5B-9568-498D-984F-8DCCB4A83F64@isc.org" target="_blank">8F2E2C5B-9568-498D-984F-8DCCB4A83F64@isc.org</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
<br>
<br>
> On 8 Apr 2021, at 00:37, Tony Finch <<a href="mailto:dot@dotat.at" target="_blank">dot@dotat.at</a>> wrote:<br>
> <br>
> Chuck Aurora <<a href="mailto:ca@nodns4.us" target="_blank">ca@nodns4.us</a>> wrote:<br>
>> <br>
>> A stub or static-stub zone would not require recursion. In that case<br>
>> named is asking for authoritative data from upstream. But type<br>
>> forward zones indeed cannot work if recursion is disabled.<br>
> <br>
> Be careful in this kind of situation to be very clear about which client<br>
> or server is doing what: in this case, it isn't clear what doesn't require<br>
> recursion for stub or static stub.<br>
> <br>
> All three types of zone configuration (stub, static stub, and forward)<br>
> are only useful on a server that is providing recursive service.<br>
> <br>
> Forward zones require the upstream server to be recursive too.<br>
<br>
More correctly, the upstream server has to serve the entire namespace being<br>
forwarded if it does not off recursion to the client for forwarding to<br>
work.<br>
<br>
> Stub and static-stub expect the upstream server to be authoritative;<br>
> the stub server list is a hint that gets replaced by the authoritative<br>
> server list from the zone (a bit like the root hints) whereas static-stub<br>
> only uses the configured upstream servers.<br>
> <br>
>>> What I've learned from this list is that you should split<br>
>>> authoritative and recursive service.<br>
>> <br>
>> I would suggest that as a general best practice, but not an absolute<br>
>> one. There's nothing wrong with having internal-only authoritative<br>
>> zones on your recursive resolver. The potential problem comes when<br>
>> you're a globally-published NS for your zones; having recursion<br>
>> enabled can make you vulnerable to more possible attacks.<br>
> <br>
> Right: the rule is that authoritative servers listed as targets of NS<br>
> records should be authoritative-only; it's OK if recursive servers have<br>
> authoritative copies of zones: it can make them more resilient to outages,<br>
> though it does slightly weird things to DNSSEC validation.<br>
> <br>
> Tony.<br>
> -- <br>
> f.anthony.n.finch <<a href="mailto:dot@dotat.at" target="_blank">dot@dotat.at</a>> <a href="https://dotat.at/" rel="noreferrer" target="_blank">https://dotat.at/</a><br>
> Whitby to Gibraltar Point: Northwest 4 to 6 becoming variable 2 to 4,<br>
> then southwest 4 to 6 later. Very rough at first in north, otherwise<br>
> moderate or rough. Snow showers, then rain for a time later. Good,<br>
> occasionally very poor at first.<br>
> <br>
> _______________________________________________<br>
> Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">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">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">bind-users@lists.isc.org</a><br>
> <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
<br>
-- <br>
Mark Andrews, ISC<br>
1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
PHONE: +61 2 9871 4742 INTERNET: <a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<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">https://www.isc.org/contact/</a> for more information.<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
<br>
<br>
------------------------------<br>
<br>
End of bind-users Digest, Vol 3678, Issue 2<br>
*******************************************<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"></div></div></div>