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