Re: Multiple instances of BIND at startup
Well, BIND is up to 28 published security advisories: http://www.isc.org/sw/bind/bind-security.php#matrix ...which not only have included cache poisoning (2003-0914), but many of them allowed for arbitrary code execution, often as root. Ok, then I'll ask the obvious... For those who are, or have been network ops within an Internet Service Provider environment, what DNS server do you recommend for reliability, functionality, and most importantly, ease of use so the helpdesk can make slight changes to client domains when required (hopefully without having to su to root). The latter point is why I went from BIND to TinyDNS (VegaDNS) in the first place, but it's seriously lacking with IPv6 support. Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple instances of BIND at startup
The match-destination inspects the DNS address used by the client to query to determine which view to use. Would this suit your purpose? Well, yes, it would suit the purpose, but my fear was exactly that of what Matthew states below about 'leaking'. I believe that the problem is this: even if configured to be an authoritative server, BIND will respond to a query about zones outside what it has authoritative data for with data from its cache if that data is present. As there is only one cache per instance of BIND, enabling any sort of recursive capability on a server that is otherwise meant to be entirely authoritative can lead to data leaking between the authoritative and recursive parts. This opens up the possibility of tricking a server into caching false data and responding with it as if it was authoritative. In answer to the OPs original question -- yes you can start two instances of BIND given the obvious requirement that they have distinct network addresses and ports, pid files etc. You just have to copy the startup script to a new name and modify the variable prefix internally -- eg. This chunk at the beginning of the script: This is exactly what I'm after. Thank you for all the help! Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple instances of BIND at startup
Steve Bertrand wrote: I believe that the problem is this: even if configured to be an authoritative server, BIND will respond to a query about zones outside what it has authoritative data for with data from its cache if that data is present. As there is only one cache per instance of BIND, enabling any sort of recursive capability on a server that is otherwise meant to be entirely authoritative can lead to data leaking between the authoritative and recursive parts. This opens up the possibility of tricking a server into caching false data and responding with it as if it was authoritative. I cannot believe this, I want to research this myself (and the impact to my designs. Maybe it is the time to give unbound a try: [EMAIL PROTECTED]:/usr/ports/dns/unbound] # cat pkg-descr Unbound is designed as a set of modular components, so that also DNSSEC (secure DNS) validation and stub-resolvers (that do not run as a server, but are linked into an application) are easily possible. Goals: * A validating recursive DNS resolver. * Code diversity in the DNS resolver monoculture. * Drop-in replacement for BIND apart from config. * DNSSEC support. * Fully RFC compliant. * High performance o even with validation. * Used as o stub resolver. o full caching name server. o resolver library. * Elegant design of validator, resolver, cache modules. o provide the ability to pick and choose modules. * Robust. * In C, open source: The BSD license. * Smallest as possible component that does the job. * Stub-zones can be configured (local data or AS112 zones). Non-goals: * An authoritative name server. * Too many Features. WWW: http://unbound.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple instances of BIND at startup
On Thu, May 22, 2008 at 08:13:03AM -0400, Steve Bertrand wrote: The match-destination inspects the DNS address used by the client to query to determine which view to use. Would this suit your purpose? Well, yes, it would suit the purpose, but my fear was exactly that of what Matthew states below about 'leaking'. I believe that the problem is this: even if configured to be an authoritative server, BIND will respond to a query about zones outside what it has authoritative data for with data from its cache if that data is present. As there is only one cache per instance of BIND, enabling any sort of recursive capability on a server that is otherwise meant to be entirely authoritative can lead to data leaking between the authoritative and recursive parts. This opens up the possibility of tricking a server into caching false data and responding with it as if it was authoritative. If this were true, the view feature would be broken. I've just tried this with a client-based ACL, and there doesn't appear to any cache-leaking across views. Any counter-examples would be welcome. Cheers. -- Jonathan Chen [EMAIL PROTECTED] -- Experience is a hard teacher because she gives the test first, the lesson afterwards ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple instances of BIND at startup
Jonathan Chen wrote: If this were true, the view feature would be broken. I've just tried this with a client-based ACL, and there doesn't appear to any cache-leaking across views. Any counter-examples would be welcome. I did this tests too. No leaks found. ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.kransite.de. IN A Maybe this was a a bug in 4.x or 8x ? I cannot even find some hints about such a issue. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple instances of BIND at startup
On May 22, 2008, at 1:39 PM, Jonathan Chen wrote: [ ... ] If this were true, the view feature would be broken. I've just tried this with a client-based ACL, and there doesn't appear to any cache-leaking across views. Any counter-examples would be welcome. Well, BIND is up to 28 published security advisories: http://www.isc.org/sw/bind/bind-security.php#matrix ...which not only have included cache poisoning (2003-0914), but many of them allowed for arbitrary code execution, often as root. -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Multiple instances of BIND at startup
Hi everybody, I am attempting to configure a BIND 9 name server that will be authoritative for certain domains which will listen exclusively on IPv6. This same box will also be a caching server for a handful of networks (IPv6 and IPv4). The way I have it set up is that the authoritative and caching services each run a single instance of BIND on it's own IP address, with both instances each doing exactly what they are supposed to do. However, how can I make the FreeBSD (7.0) startup scripts load both instances of BIND, each with it's own configuration? I've read through the Administrators handbook for BIND and numerous newsgroup postings about 'views', but I don't think this is what I want. It seems 'views' are more for split-DNS, segregating internal access and external access to the same service. That is not what I am after. Any pointers much appreciated. Regards, Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple instances of BIND at startup
Steve Bertrand wrote: Hi everybody, I am attempting to configure a BIND 9 name server that will be authoritative for certain domains which will listen exclusively on IPv6. This same box will also be a caching server for a handful of networks (IPv6 and IPv4). The way I have it set up is that the authoritative and caching services each run a single instance of BIND on it's own IP address, with both instances each doing exactly what they are supposed to do. However, how can I make the FreeBSD (7.0) startup scripts load both instances of BIND, each with it's own configuration? I've read through the Administrators handbook for BIND and numerous newsgroup postings about 'views', but I don't think this is what I want. It seems 'views' are more for split-DNS, segregating internal access and external access to the same service. That is not what I am after. Any pointers much appreciated. I did something very similar. Run one of the bind instances in a jail -- especially with a little firewall rdr rules and similar trickery to redirect traffic into the appropriate instance (which gets you past the lack of IPv6 support in jail(8)). Works beautifully. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Multiple instances of BIND at startup
However, how can I make the FreeBSD (7.0) startup scripts load both instances of BIND, each with it's own configuration? I did something very similar. Run one of the bind instances in a jail -- especially with a little firewall rdr rules and similar trickery to redirect traffic into the appropriate instance (which gets you past the lack of IPv6 support in jail(8)). Works beautifully. Thanks Matthew for the response. In all honesty, I want to stay away from jails as much as possible. Once testing is complete, I'll have numerous DNS servers to roll this out to, and I want the least amount of complexity as possible. A few years ago I switched our entire infrastructure from BIND to DJBDNS (with VegaDNS as a web front-end), and now I'm looking to go back. Again, I'd rather do this without jails if possible, and at the same time, be able to use the built in FBSD startup scripts if possible. If not, heres another question: If I need to create my own custom script to do this sort of thing, where should it be loaded from? Some of my firewall rulesets rely on DNS to be up prior to them. Regards, Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple instances of BIND at startup
On Wed, May 21, 2008 at 06:52:36PM -0400, Steve Bertrand wrote: Again, I'd rather do this without jails if possible, and at the same time, be able to use the built in FBSD startup scripts if possible. Can you not make use of BIND 9's view features? Possibly each view using a match-destinations block to map to either the authoritative or the caching services. Cheers. -- Jonathan Chen [EMAIL PROTECTED] --- I love deadlines. I like the whooshing sound they make as they fly by - Douglas Adams ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple instances of BIND at startup
Jonathan Chen wrote: On Wed, May 21, 2008 at 06:52:36PM -0400, Steve Bertrand wrote: Again, I'd rather do this without jails if possible, and at the same time, be able to use the built in FBSD startup scripts if possible. Can you not make use of BIND 9's view features? Possibly each view using a match-destinations block to map to either the authoritative or the caching services. Well, from what I read (I can't remember where), if I use views to do this with only a single instance running, the problem arises that even though the 'external' (requests for authoritative answers) clients can and will get responses from the caching side of the server if the result they are after is already cached. I want the two services to be completely disparate, and more precise, I'd like to have the recursive instance to have to query the authoritative instance for a result from the same box. I have this setup already working fine. I just can't get it to start properly with both instances :) If I am missing something, and you have a config example, it would be appreciated. Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple instances of BIND at startup
On Wed, May 21, 2008 at 08:01:50PM -0400, Steve Bertrand wrote: Jonathan Chen wrote: On Wed, May 21, 2008 at 06:52:36PM -0400, Steve Bertrand wrote: Again, I'd rather do this without jails if possible, and at the same time, be able to use the built in FBSD startup scripts if possible. Can you not make use of BIND 9's view features? Possibly each view using a match-destinations block to map to either the authoritative or the caching services. Well, from what I read (I can't remember where), if I use views to do this with only a single instance running, the problem arises that even though the 'external' (requests for authoritative answers) clients can and will get responses from the caching side of the server if the result they are after is already cached. I didn't quite parse this, could you please elaborate? I want the two services to be completely disparate, and more precise, I'd like to have the recursive instance to have to query the authoritative instance for a result from the same box. The same result can be achieved by using the same master zone file in your caching and authoritative views. Not quite what you wanted, but the end result should be the same. Cheers. -- Jonathan Chen [EMAIL PROTECTED] -- A person should be able to do a small bit of everything, specialisation is for insects ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple instances of BIND at startup
Well, from what I read (I can't remember where), if I use views to do this with only a single instance running, the problem arises that even though the 'external' (requests for authoritative answers) clients can and will get responses from the caching side of the server if the result they are after is already cached. I didn't quite parse this, could you please elaborate? I want the two services to be completely disparate, and more precise, I'd like to have the recursive instance to have to query the authoritative instance for a result from the same box. The same result can be achieved by using the same master zone file in your caching and authoritative views. Not quite what you wanted, but the end result should be the same. I'm beginning to feel that I'm on a different page here. I understand 'views' as far as BIND is concerned as thus (I may be misguided): Internet | external clients looking for resolution | | | external view (accept from acl x.x.x.x) | BIND DNS Server | internal view (accept from acl x.x.x.x) | | | internal clients looking for resolution | A private LAN perhaps My authoritative name server (service, eventually cluster) will eventually house about 500 domains, which I want only recursive DNS servers that come from the root .tld down to see (no caching). The caching name server (service, and eventually cluster) will see tens of thousands of our clients requests (we are an ISP) to use as their DNS lookup, which will perform recursive lookups that we are not authoritative for. I'm sorry, I don't know how to put it into other words, other than I want complete separation from dns authoritative and dns caching services to be disparate. The same thing I get when I run tinydns and dnscache on two separate IP's via ucspi. Again, example configs are welcome. Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple instances of BIND at startup
On Wed, May 21, 2008 at 10:21:05PM -0400, Steve Bertrand wrote:
[...]
My authoritative name server (service, eventually cluster) will
eventually house about 500 domains, which I want only recursive DNS
servers that come from the root .tld down to see (no caching).
The caching name server (service, and eventually cluster) will see tens
of thousands of our clients requests (we are an ISP) to use as their DNS
lookup, which will perform recursive lookups that we are not
authoritative for.
I'm sorry, I don't know how to put it into other words, other than I
want complete separation from dns authoritative and dns caching services
to be disparate.
Let's say your authoritative server is listening on IP-A, and your
caching server is listening on IP-B; both ip-addresses are on the same
host. We can have a named instance listening on both addresses, with
multiple views like:
/*
Used by root .tld.
*/
view authoritative
{
match-destination
{
IP-A;
};
recursion no;
zone my.authoritative.org
{
type master;
...
};
}
/*
Use by our client requests.
*/
view caching
{
match-destination
{
IP-B;
};
recursion yes;
zone my.authoritative.org
{
type master;
...
};
}
The match-destination inspects the DNS address used by the client to
query to determine which view to use. Would this suit your purpose?
--
Jonathan Chen [EMAIL PROTECTED]
--
Nyuck, nyuck, nyuck - Curly
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple instances of BIND at startup
Jonathan Chen wrote:
On Wed, May 21, 2008 at 10:21:05PM -0400, Steve Bertrand wrote:
[...]
My authoritative name server (service, eventually cluster) will
eventually house about 500 domains, which I want only recursive DNS
servers that come from the root .tld down to see (no caching).
The caching name server (service, and eventually cluster) will see tens
of thousands of our clients requests (we are an ISP) to use as their DNS
lookup, which will perform recursive lookups that we are not
authoritative for.
I'm sorry, I don't know how to put it into other words, other than I
want complete separation from dns authoritative and dns caching services
to be disparate.
Let's say your authoritative server is listening on IP-A, and your
caching server is listening on IP-B; both ip-addresses are on the same
host. We can have a named instance listening on both addresses, with
multiple views like:
/*
Used by root .tld.
*/
view authoritative
{
match-destination
{
IP-A;
};
recursion no;
zone my.authoritative.org
{
type master;
...
};
}
/*
Use by our client requests.
*/
view caching
{
match-destination
{
IP-B;
};
recursion yes;
zone my.authoritative.org
{
type master;
...
};
}
The match-destination inspects the DNS address used by the client to
query to determine which view to use. Would this suit your purpose?
I believe that the problem is this: even if configured to be an
authoritative server, BIND will respond to a query about zones
outside what it has authoritative data for with data from its cache
if that data is present. As there is only one cache per instance of
BIND, enabling any sort of recursive capability on a server that is
otherwise meant to be entirely authoritative can lead to data leaking
between the authoritative and recursive parts. This opens up the
possibility of tricking a server into caching false data and responding
with it as if it was authoritative.
In answer to the OPs original question -- yes you can start two instances
of BIND given the obvious requirement that they have distinct network
addresses and ports, pid files etc. You just have to copy the startup
script to a new name and modify the variable prefix internally -- eg. This
chunk at the beginning of the script:
name=named
rcvar=named_enable
you'ld modify to say instead:
name=named1
rcvar=named1_enable
-- modifying all of the other instances of variable name prefixes in the
file from named to named1 similarly. Then you'ld put:
named1_enable=YES
named1_chroot=/var/named1
named1_pidfile=/var/run/named1/pid
etc. etc. into /etc/rc.conf. You can put your modified named1.sh rc script
into /etc/rc.d/ or /usr/local/etc/rc.d/ -- the latter is probably more
desirable as you won't get prompted to delete the file every time you run
mergemaster -- and the rcorder stuff will cause it to be started at much
the same stage in the boot process as the original named.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
signature.asc
Description: OpenPGP digital signature
