I'd like to reinforce what Chris said, and recommend the use of an
internal root zone for networks/enterprises which have no public
Internet connectivity, or whose connectivity to the Internet is
exclusively through application-level proxies. Don't make Internet names
resolvable on your internal network if that resolution isn't necessary
-- this provides a level of security in addition to your other levels
(see "Defense in Depth"), since many worms and malware can't recover
from DNS resolution failure of whatever Internet name they're trying to
resolve. It also allows you to better control your own DNS destiny,
including "blackholing" of various domains, if that should become
necessary in an emergency. Another optional benefit is it allows you to
centrally control your mail routing, if you have MTAs that use the
standard MX-record method of routing SMTP mail.
A lot of people seem to be scared by the prospect of setting up their
own root zone. It's really not much different than any other zone,
except that
-- there is no delegation from any parent zone (obviously), and
-- all of your other nameservers need to slave, stub, forward or have
"hints" files referring to your own internal root-zone infrastructure,
rather than the Internet root-zone infrastructure. This means you can't
use the compiled-in defaults for the root zone, but those are useless to
you anyway if you don't have direct connectivity to those nameservers.
- Kevin
On 4/19/2011 4:37 AM, Chris Buxton wrote:
You're getting a bit confused, because your configuration is complex. Some of
your observations are in contradiction with your disabling of recursion, so I
believe you are partially mistaken.
- You're mixing authoritative and recursive service in one config. This often
leads to confusion.
- Your recursion algorithm must be able to track down a particular domain while
not being able to resolve from the Internet root.
Rather than turning off recursion, why not just set up your own root zone (type
master)? That way, your server can recurse to sub.example.com based on the
delegation, while returning immediate negative answers for anything unknown.
Just make sure you delegate example.com (and all other zones) from your private
root zone.
A forwarders list in example.com or a zone of type forward named
sub.example.com will not have any effect so long as recursion is disabled.
Forwarding is a configuration aspect of the recursion algorithm.
Regards,
Chris Buxton
BlueCat Networks
On Apr 18, 2011, at 11:57 PM, Olivier Cherrier wrote:
Hi,
I am experiencing problems to get a working forwarding configuration.
I am using BIND 9.3.6-P1 and the server has the global recursion parameter
on. The server is not on a public network (not on Internet -- no access
to root servers).
I have a zone called "example.com" for which the server is master.
A delegation called "sub.example.com" is in place and is working well.
I want to change the recursion parameter from 'yes' to 'no' in order to
get rid of the timeouts we get when we query something that is not
defined in our DNS server (like www.google.com).
Doing this breaks the delegation "sub.example.com", meaning the server
doesn't do the research anymore for the subzone.
So I deleted the delegation and configured a forward zone to the right
IP addresses. The problem is named doesn't even try to query those
forwarders and directly reply: "No answer"
While it works for some other forwarded zones (reverse and non-reverse),
I fail to understand why it doesn't work for that particular zone.
The only difference I see is that this forwarded zone is a subzone of
"example.com" for which the server is master.
So my question: Is there any limitation to forward a subzone while we
are master for the parent zone?
Thanks a lot!
Best regards.
--
Olivier Cherrier - Symacx.com
mailto:o...@symacx.com
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
