forwarding zone setup from a BIND slave (without recursion?)
RK K
rvkota at gmail.com
Thu Apr 8 00:45:43 UTC 2021
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-request at lists.isc.org> wrote:
> Send bind-users mailing list submissions to
> bind-users at 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-request at lists.isc.org
>
> You can reach the person managing the list at
> bind-users-owner at 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 <ca at nodns4.us>
> To: bind-users at lists.isc.org
> Subject: Re: forwarding zone setup from a BIND slave (without
> recursion?)
> Message-ID: <a8f126db4876d2406054c6e65a12fe3f at 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 <dot at dotat.at>
> To: Chuck Aurora <ca at nodns4.us>
> Cc: bind-users at lists.isc.org
> Subject: Re: forwarding zone setup from a BIND slave (without
> recursion?)
> Message-ID: <cdbcf6e-f0c3-9ac4-ee7a-d0c237de602e at dotat.at>
> Content-Type: text/plain; charset=US-ASCII
>
> Chuck Aurora <ca at 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 <dot at 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.thurston at alaska.gov>
> To: bind-users at lists.isc.org
> Subject: Re: rndc stops listening
> Message-ID: <5df942c4-78b8-39be-2df5-33f5ea387e9b at 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.Thurston at 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? <ondrej at isc.org>
> To: John Thurston <john.thurston at alaska.gov>
> Cc: bind-users at lists.isc.org
> Subject: Re: rndc stops listening
> Message-ID: <B9892FD6-D99B-4B3A-B51E-BD5470B97BA9 at 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.thurston at 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.Thurston at 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 at 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 <marka at isc.org>
> To: Tony Finch <dot at dotat.at>
> Cc: Chuck Aurora <ca at nodns4.us>, bind-users at lists.isc.org
> Subject: Re: forwarding zone setup from a BIND slave (without
> recursion?)
> Message-ID: <8F2E2C5B-9568-498D-984F-8DCCB4A83F64 at isc.org>
> Content-Type: text/plain; charset=us-ascii
>
>
>
> > On 8 Apr 2021, at 00:37, Tony Finch <dot at dotat.at> wrote:
> >
> > Chuck Aurora <ca at 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 <dot at 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 at 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: marka at 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
> ------------------------------
>
> End of bind-users Digest, Vol 3678, Issue 2
> *******************************************
>
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210407/60d76829/attachment-0001.htm>
More information about the bind-users
mailing list