Re: Finally Converting From Bind 8 -> Bind 9
Tim Daneliuk wrote: Alex Zbyslaw wrote: Tim Daneliuk wrote: 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. I don't think there is, but let someone who uses bind more than I do give a definitive on that :-) What you *can* do, irrespective of bind version, is to have two files which you pre-process with m4, and have a third file which m4 includes on both the others. So you start with: internal.M4 which includes "shared" external.M4 which also includes "shared" shared which gets included in the other two. Then m4 internal.M4 > internal and m4 external.M4 -> external. Bind then loads internal and external. A reasonable and very Unix-ish solution, certainly. Though, I think the subsequent post on this thread regarding $INCLUDE is probably more elegant ;) Certainly, since bind supports it (it's even in my Bind 8 book, though I never noticed it before). Of course, you can do a heck of a lot more with m4, and it's not limited to bind, but in this case I would say that simplicity wins hands down ;-) --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Finally Converting From Bind 8 -> Bind 9
Josh Paetzel wrote: Sure, you can $INCLUDE a file in to a zonefile. :) Yup - that sure does it. However, it is still possible to do Very Stupid Things (tm). Anyone running bind should not that this combination of things causes great silliness: $ORIGIN mydomain.com. @ IN SOA .. ; Nameservers IN NSfoo.mydomain.com ; oops, missing trailing period Really dumb, and it had my wondering what was wrong with my $INCLUDE - nothing, of course. Thanks for the help. I now have a nice clean db.external with a corresponding view. db.internal merely $INCLUDES db.external as its first statement and has a corresponding view. Now when I modify *anything* - $TTL, a host definition ... whatever, it propagates into both views with a single edit. -- 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]"
Re: Finally Converting From Bind 8 -> Bind 9
Alex Zbyslaw wrote: Tim Daneliuk wrote: 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. I don't think there is, but let someone who uses bind more than I do give a definitive on that :-) What you *can* do, irrespective of bind version, is to have two files which you pre-process with m4, and have a third file which m4 includes on both the others. So you start with: internal.M4 which includes "shared" external.M4 which also includes "shared" shared which gets included in the other two. Then m4 internal.M4 > internal and m4 external.M4 -> external. Bind then loads internal and external. A reasonable and very Unix-ish solution, certainly. Though, I think the subsequent post on this thread regarding $INCLUDE is probably more elegant ;) Alternatively you could start with one M4 file which uses lots of ifdefs for the non-shared portions. The create internal and external by specifying different definitions to m4. e.g. m4 -D _TYPE=EXTERNAL or m4 -D _TYPE=INTERNAL. For a problem with small differences between two files, this is a better solution, but not what I'd do in this case. Me either - conditional content gets clumsy to maintain in a big hurry. Whole process can be easily controlled with a Makefile (including any restarts). --Alex -- 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]"
Re: Finally Converting From Bind 8 -> Bind 9
On Friday 13 July 2007, Tim Daneliuk wrote:
> 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,
Sure, you can $INCLUDE a file in to a zonefile. :)
--
Thanks,
Josh Paetzel
pgpLBopDKFtGx.pgp
Description: PGP signature
Re: Finally Converting From Bind 8 -> Bind 9
Tim Daneliuk wrote: 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. I don't think there is, but let someone who uses bind more than I do give a definitive on that :-) What you *can* do, irrespective of bind version, is to have two files which you pre-process with m4, and have a third file which m4 includes on both the others. So you start with: internal.M4 which includes "shared" external.M4 which also includes "shared" shared which gets included in the other two. Then m4 internal.M4 > internal and m4 external.M4 -> external. Bind then loads internal and external. Alternatively you could start with one M4 file which uses lots of ifdefs for the non-shared portions. The create internal and external by specifying different definitions to m4. e.g. m4 -D _TYPE=EXTERNAL or m4 -D _TYPE=INTERNAL. For a problem with small differences between two files, this is a better solution, but not what I'd do in this case. Whole process can be easily controlled with a Makefile (including any restarts). --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Finally Converting From Bind 8 -> Bind 9
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]"
Re: Finally Converting From Bind 8 -> Bind 9
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
That helped immensely and made this part of the problem trivial to implement.
Thanks!
Now I just have to learn how to have dhcpd update named with the latest
lease information...
--
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]"
Re: Finally Converting From Bind 8 -> Bind 9
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
--
Thanks,
Josh Paetzel
pgph7bvZtOHKl.pgp
Description: PGP signature
Finally Converting From Bind 8 -> Bind 9
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, -- 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]"
