forwarding zone setup from a BIND slave (without recursion?)

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

forwarding zone setup from a BIND slave (without recursion?)

RK K
All,

We have a set of BIND primary servers (MASTERs) and a set of secondary servers (slaves to the MASTERs). 
The secondary BIND DNS servers disabled recursion ( with "recursion no;" ) in the global options. 
All the applications/systems do use secondary DNS servers for name resolution.

Now there is a need to configure a forwarding zone in the "secondary DNS servers" to an external DNS server.

In this scenario, in-order for the secondary server to forward the DNS query to an external DNS server, is it required to enable the recursion in the global options on the secondary servers?
Based on reference material, I did not see such a requirement. But my observation is the query is not getting forwarded ( tried to check using the packet trace)
When recursion is enabled, the query is getting forwarded.

The BIND version I am using is 9.11.2.x.

Appreciate your ideas and help.

Thank you
Kind Regards,
Ravi Kota

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: forwarding zone setup from a BIND slave (without recursion?)

Matus UHLAR - fantomas
On 06.04.21 22:47, RK K wrote:

>We have a set of BIND primary servers (MASTERs) and a set of secondary
>servers (slaves to the MASTERs).
>The secondary BIND DNS servers disabled recursion ( with "*recursion no;" *)
>in the global options.
>All the applications/systems do use secondary DNS servers for name
>resolution.
>
>Now there is a need to configure a forwarding zone in the "secondary DNS
>servers" to an external DNS server.
>
>In this scenario, in-order for the secondary server to forward the DNS
>query to an external DNS server, is it required to enable the recursion in
>the global options on the secondary servers?

yes.

>Based on reference material, I did not see such a requirement. But my
>observation is the query is not getting forwarded ( tried to check using
>the packet trace)
>When recursion is enabled, the query is getting forwarded.
>
>The BIND version I am using is 9.11.2.x.

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
It's now safe to throw off your computer.
_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: forwarding zone setup from a BIND slave (without recursion?)

Marki

Hello,

On 4/7/2021 10:35 AM, Matus UHLAR - fantomas wrote:
On 06.04.21 22:47, RK K wrote:
In this scenario, in-order for the secondary server to forward the DNS
query to an external DNS server, is it required to enable the recursion in
the global options on the secondary servers?

yes.

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.

What I've learned from this list is that you should split authoritative and recursive service.

In other words, you need two types of servers:

1) A non-recursive one in the backend containing your authoritative zones only. This can be a hidden master setup, somewhat like what you are using now.

2) The one your users access has recursion enabled, and contains stubs to the authoritative service. Obviously, it can also contain stubs (or forwarders) to anywhere else. At the same time it is performing full recursive service unless you take authority for the root zone.

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?

Bye,

Marki


_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: forwarding zone setup from a BIND slave (without recursion?)

Chuck Aurora
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.
_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: forwarding zone setup from a BIND slave (without recursion?)

Tony Finch
Chuck Aurora <[hidden email]> 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  <[hidden email]>  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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: forwarding zone setup from a BIND slave (without recursion?)

Mark Andrews


> On 8 Apr 2021, at 00:37, Tony Finch <[hidden email]> wrote:
>
> Chuck Aurora <[hidden email]> 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  <[hidden email]>  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
> [hidden email]
> 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: [hidden email]

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: forwarding zone setup from a BIND slave (without recursion?)

RK K
In reply to this post by RK K
Hello Marki, Matus,

Thank you for the insights on this topic.

Answering Marki's question about why the secondary-authoritative (slaves) are used for lookups is some-what history and there was no need to be recursive (until now) as all the  queries are authoritatively answered or refused. May be security is another reason.

Much appreciated your ideas

Thank you 
Kind Regards
RK

On Wed, Apr 7, 2021 at 8:01 AM <[hidden email]> wrote:
Send bind-users mailing list submissions to
        [hidden email]

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
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of bind-users digest..."


Today's Topics:

   1. forwarding zone setup from a BIND slave (without recursion?)
      (RK K)
   2. Re: forwarding zone setup from a BIND slave (without
      recursion?) (Matus UHLAR - fantomas)
   3. Re: forwarding zone setup from a BIND slave (without
      recursion?) (Marki)


----------------------------------------------------------------------

Message: 1
Date: Tue, 6 Apr 2021 22:47:23 -0400
From: RK K <[hidden email]>
To: [hidden email]
Subject: forwarding zone setup from a BIND slave (without recursion?)
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"

All,

We have a set of BIND primary servers (MASTERs) and a set of secondary
servers (slaves to the MASTERs).
The secondary BIND DNS servers disabled recursion ( with "*recursion no;" *)
in the global options.
All the applications/systems do use secondary DNS servers for name
resolution.

Now there is a need to configure a forwarding zone in the "secondary DNS
servers" to an external DNS server.

In this scenario, in-order for the secondary server to forward the DNS
query to an external DNS server, is it required to enable the recursion in
the global options on the secondary servers?
Based on reference material, I did not see such a requirement. But my
observation is the query is not getting forwarded ( tried to check using
the packet trace)
When recursion is enabled, the query is getting forwarded.

The BIND version I am using is 9.11.2.x.

Appreciate your ideas and help.

Thank you
Kind Regards,
Ravi Kota
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210406/15bb6cad/attachment-0001.htm>

------------------------------

Message: 2
Date: Wed, 7 Apr 2021 10:35:12 +0200
From: Matus UHLAR - fantomas <[hidden email]>
To: [hidden email]
Subject: Re: forwarding zone setup from a BIND slave (without
        recursion?)
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=us-ascii; format=flowed

On 06.04.21 22:47, RK K wrote:
>We have a set of BIND primary servers (MASTERs) and a set of secondary
>servers (slaves to the MASTERs).
>The secondary BIND DNS servers disabled recursion ( with "*recursion no;" *)
>in the global options.
>All the applications/systems do use secondary DNS servers for name
>resolution.
>
>Now there is a need to configure a forwarding zone in the "secondary DNS
>servers" to an external DNS server.
>
>In this scenario, in-order for the secondary server to forward the DNS
>query to an external DNS server, is it required to enable the recursion in
>the global options on the secondary servers?

yes.

>Based on reference material, I did not see such a requirement. But my
>observation is the query is not getting forwarded ( tried to check using
>the packet trace)
>When recursion is enabled, the query is getting forwarded.
>
>The BIND version I am using is 9.11.2.x.

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
It's now safe to throw off your computer.


------------------------------

Message: 3
Date: Wed, 7 Apr 2021 10:59:30 +0200
From: Marki <[hidden email]>
To: [hidden email]
Subject: Re: forwarding zone setup from a BIND slave (without
        recursion?)
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Hello,

On 4/7/2021 10:35 AM, Matus UHLAR - fantomas wrote:
> On 06.04.21 22:47, RK K wrote:
>> In this scenario, in-order for the secondary server to forward the DNS
>> query to an external DNS server, is it required to enable the
>> recursion in
>> the global options on the secondary servers?
>
> yes.

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.

What I've learned from this list is that you should split authoritative
and recursive service.

In other words, you need two types of servers:

1) A non-recursive one in the backend containing your authoritative
zones only. This can be a hidden master setup, somewhat like what you
are using now.

2) The one your users access has recursion enabled, and contains stubs
to the authoritative service. Obviously, it can also contain stubs (or
forwarders) to anywhere else. At the same time it is performing full
recursive service unless you take authority for the root zone.

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?

Bye,

Marki

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210407/b96c3543/attachment-0001.htm>

------------------------------

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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users


------------------------------

End of bind-users Digest, Vol 3678, Issue 1
*******************************************




_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: forwarding zone setup from a BIND slave (without recursion?)

RK K
In reply to this post by RK K
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 <[hidden email]> wrote:
Send bind-users mailing list submissions to
        [hidden email]

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
        [hidden email]

You can reach the person managing the list at
        [hidden email]

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 <[hidden email]>
To: [hidden email]
Subject: Re: forwarding zone setup from a BIND slave (without
        recursion?)
Message-ID: <[hidden email]>
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 <[hidden email]>
To: Chuck Aurora <[hidden email]>
Cc: [hidden email]
Subject: Re: forwarding zone setup from a BIND slave (without
        recursion?)
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=US-ASCII

Chuck Aurora <[hidden email]> 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  <[hidden email]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 <[hidden email]>
To: [hidden email]
Subject: Re: rndc stops listening
Message-ID: <[hidden email]>
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
[hidden email]
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? <[hidden email]>
To: John Thurston <[hidden email]>
Cc: [hidden email]
Subject: Re: rndc stops listening
Message-ID: <[hidden email]>
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 <[hidden email]> 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
> [hidden email]
> 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
> [hidden email]
> https://lists.isc.org/mailman/listinfo/bind-users



------------------------------

Message: 5
Date: Thu, 8 Apr 2021 09:25:21 +1000
From: Mark Andrews <[hidden email]>
To: Tony Finch <[hidden email]>
Cc: Chuck Aurora <[hidden email]>, [hidden email]
Subject: Re: forwarding zone setup from a BIND slave (without
        recursion?)
Message-ID: <[hidden email]>
Content-Type: text/plain;       charset=us-ascii



> On 8 Apr 2021, at 00:37, Tony Finch <[hidden email]> wrote:
>
> Chuck Aurora <[hidden email]> 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  <[hidden email]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
> [hidden email]
> 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: [hidden email]



------------------------------

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
[hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: forwarding zone setup from a BIND slave (without recursion?)

Tony Finch
In reply to this post by Mark Andrews
Mark Andrews <[hidden email]> wrote:
> > On 8 Apr 2021, at 00:37, Tony Finch <[hidden email]> wrote:
> >
> > 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.

I thought forwarding expected the target server to resolve CNAMEs? If so,
any out-of-zone CNAMEs in the target namespace would cause problems.

Tony.
--
f.anthony.n.finch  <[hidden email]>  https://dotat.at/
Cape Wrath to Rattray Head including Orkney: Southwesterly 6 to gale
8, occasionally 5 at first in east, then veering westerly or
northwesterly 7 to severe gale 9 later. Moderate or rough, becoming
very rough or high in north. Rain at times, squally snow showers
later. Moderate or good, occasionally very poor later.

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users