Thank you all for sharing the ideas.. very much appreciated.
Send bind-users mailing list submissions to
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
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of bind-users digest..."
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
Subject: Re: forwarding zone setup from a BIND slave (without
recursion?)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Post by MarkiTo 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.
Post by MarkiWhat 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.
Post by MarkiMay 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
Subject: Re: forwarding zone setup from a BIND slave (without
recursion?)
Content-Type: text/plain; charset=US-ASCII
Post by MarkiA 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.
Post by MarkiPost by MarkiWhat 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.
--
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
Subject: Re: rndc stops listening
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
Department of Administration
State of Alaska
Post by MarkiRunning BIND 9.16.9 on CentOS 8
I have the following in my .conf
Post by Markicontrols {
? 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
Subject: Re: rndc stops listening
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.
Post by Marki?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?
Post by Marki--
Do things because you should, not just because you can.
John Thurston 907-465-8591
Department of Administration
State of Alaska
Post by MarkiRunning 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.
Post by MarkiPost by MarkiI 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.
Post by MarkiPost by MarkiAm 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
Post by MarkiISC funds the development of this software with paid support
subscriptions. Contact us at https://www.isc.org/contact/ for more
information.
Post by Markibind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
------------------------------
Message: 5
Date: Thu, 8 Apr 2021 09:25:21 +1000
Subject: Re: forwarding zone setup from a BIND slave (without
recursion?)
Content-Type: text/plain; charset=us-ascii
Post by MarkiPost by MarkiA 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
Post by Markirecursion 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.
Post by MarkiStub 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.
Post by MarkiWhat 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,
Post by Markithough it does slightly weird things to DNSSEC validation.
Tony.
--
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
Post by MarkiISC funds the development of this software with paid support
subscriptions. Contact us at https://www.isc.org/contact/ for more
information.
Post by Markibind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
------------------------------
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
https://lists.isc.org/mailman/listinfo/bind-users
------------------------------
End of bind-users Digest, Vol 3678, Issue 2
*******************************************