Josh Paetzel wrote:
On Monday 02 July 2007 16:48, Tim Daneliuk wrote:
I am (ever so) slowly moving my domain from FBSD 4.x to 6.2. I am now
at the point where I need to convert my Bind 8 configuration to Bind 9.
In so doing, I like to finally separate my internal (non-routable) hosts
so that their names never resolve outside the private network, and
expose only the public facing hosts to the world via DNS. I'd also
like to (finally) associate names with dhcpd-provided addresses
so both forwards & reverses work inside the private network.
Could some kind soul please point me to a good HOWTO on this migration and
reconfiguration? I am DAGSing as I write this, but so far have not
found what I want.
TIA,
The first part of what you want is easy.
In named.conf you'll have something like...
acl private-hosts { 192.168.1.0/24; 192.168.2.0/24; };
view "internal" {
match-clients { "private-hosts"; };
zone "example.org" {
type master;
file "master/db.internal.example.org";
};
};
view "external" {
match-clients { any; };
zone "example.org" {
type master;
file "master/db.example.org";
};
};
Now you have two separate zonefiles, one which is consulted when someone from
192.168.1.0/24 or 192.168.2.0/24 makes a query and one that is consulted when
anyone else makes a query.
HTH
OK - that works great ... but there is one efficiency I'd like to
achieve that I'm not quite sure how implement. At the moment,
both db.internal and db.external contain common public host information
because I want those hosts visible to both communities. This means I
have to make changes in two places when an public host entry is modified.
I tried removing the public information from the db.internal file with
the hope that an internal client requesting public host info would have
the request satisfied automatically from db.external - this didn't work,
the public hosts just disappeared from the internal view altogether.
This raises two questions:
1) Is there a way to configure BIND9 so that internal client requests
are first serviced out of db.internal, but if the lookup fails the
server will then go look at db.external?
2) Better still is there some sort of "include" mechanism where I could
keep a flat file of public host information for use by db.external,
but include it into db.internal.
Either of these would satisfy my desire to only have to edit a single file
of public host information.
TIA,
--
----------------------------------------------------------------------------
Tim Daneliuk [EMAIL PROTECTED]
PGP Key: http://www.tundraware.com/PGP/
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
