DNS recommendations

we're looking to have a cache & forward DNS server that will host all of our
internal DNS and forward/cache any requests beyond what it serves up.

Bind looks like it will do all we need, but we've heard a number of security
concerns with bind.

Any recommendations on something that can handle a large scale (1,000+ zone
files) deployment that is also fairly secure?

Thanks!

/dev/null wrote:
> we're looking to have a cache & forward DNS server that will host all of our
> internal DNS and forward/cache any requests beyond what it serves up.
>
> Bind looks like it will do all we need, but we've heard a number of security
> concerns with bind.
>
> Any recommendations on something that can handle a large scale (1,000+ zone
> files) deployment that is also fairly secure?
>
> Thanks!
>
>
bluecatnetworks.com has a good appliance
but I would just as soon implement a bind in a DMZ in this split-mode
style you refer to, and harden the dns host as well as be prudent with
the dns rules on the fw

--
"Never have so many understood so little about so much."
-- James Burke

"/dev/null" <dev.null@BeginThread.com> writes:

> Bind looks like it will do all we need, but we've heard a number of security
> concerns with bind.

Ancient history. There may have been one security-related upgrade in the
last year or so, with Bind, at least bind-9.x which is what counts, anyway.

> Any recommendations on something that can handle a large scale (1,000+ zone
> files) deployment that is also fairly secure?

Bind will do the first part; chances are other things will. The latter is
up to you - there's a vast arsenal of things you can do to make a service
more secure:

a) specific user (-u)
b) chroot jail (-t)
c) CFLAGS="-fstack-protector" (and other random optimization things that
are unlikely to appear in a standard packaged version)
d) a good stateful iptables firewall allowing TCP access only to known
secondary NSes
d) GRSecurity kernel patch to lock-down behaviour within chroot and stop it
from making outgoing client socket connections at all
e) check for updates EVERY DAMN DAY.
f) run the whole thing with libsafe or electricfence
g) IDS and nIDS
h) hide the version-string
i) restrict zone-xfers to secondary NSen only
j) good backup strategy

See. Plenty you can do, that makes the choice of daemon pretty much
irrelevant.

~Tim
--
18:37:08 up 114 days, 3:17, 0 users, load average: 0.11, 0.07, 0.01
piglet@stirfried.vegetable.org.uk |The light of the world keeps shining,
http://spodzone.org.uk/cesspit/ |Bright in the primal glow

/dev/null wrote:

> we're looking to have a cache & forward DNS server that will host all of
> our internal DNS and forward/cache any requests beyond what it serves up.
>
> Bind looks like it will do all we need, but we've heard a number of
> security concerns with bind.
>
> Any recommendations on something that can handle a large scale (1,000+
> zone files) deployment that is also fairly secure?
>
> Thanks!

Bind 9 is pretty good. I think you are talking about version 8 and 4. There
are many thing to do to lock it down. Just do a search on BIND 9. I would
also optimize my server for network throughput. I have no idea what OS you
use. I use FreeBSD with Bind 9. I have not had any problems. I occasionally
get someone trying to probe the version. You can lock that down to.

-- Michael

[Cross-post eliminated in follow-ups.]

In comp.os.linux.security /dev/null <dev.null@beginthread.com> wrote:
> we're looking to have a cache & forward DNS server that will host all of our
> internal DNS and forward/cache any requests beyond what it serves up.

So, just to clarify, you need (1) caching forwarder nameservice, and (2)
authoritative nameservice. Those are logically separate needs, and some
would recommend running different best-of-breed daemons for each.

> Bind looks like it will do all we need, but we've heard a number of security
> concerns with bind.

As others have noted, take care not to confuse the security problems of
BIND4 / BIND8 with the entirely separate existence of BIND9, which was a
from-scratch rewrite to the protocol and configuration/zonefile specs.

> Any recommendations on something that can handle a large scale (1,000+ zone
> files) deployment that is also fairly secure?

Please have a look at my (I hope) complete list of DNS nameserver
options for Linux: "DNS Servers" on http://linuxmafia.com/kb/Network_Other .
Warning: You will very definitely need to run a pilot project prior to
full deployment. Please do not just trust my page's descriptions: I am
going in almost all cases by the contents of sundry descriptive Web
pages, which may be inaccurate or omit crucial data.

--
Cheers, Chag orim same'ach.
Rick Moen (Happy festival of lights.)
rick@linuxmafia.com

/dev/null, jue20041209@18:37:48(CET):
>
> Bind looks like it will do all we need, but we've heard a number of security
> concerns with bind.

Bind can run as user within a chroot jail with no problems. Adding some
kernel patch like grsecurity to limit what processes can do under chroot
will give you a fairly good setup to begin with.


--
David Serrano

You could try using djbdns ( http://cr.yp.to/djbdns.html ). It was written
by D. J. Bernstein, who wrote qmail among other things, but he's really
into security. I think he's offering $500.00 US to the first person who
can find a security hole in it, the software's been around for almost 5
years and nobody's collected the reward yet...


Stu

/dev/null wrote:

> we're looking to have a cache & forward DNS server that will host all of
> our internal DNS and forward/cache any requests beyond what it serves up.
>
> Bind looks like it will do all we need, but we've heard a number of
> security concerns with bind.
>
> Any recommendations on something that can handle a large scale (1,000+
> zone files) deployment that is also fairly secure?
>
> Thanks!

[Followups trimmed.]

In comp.os.linux.security Huge <huge@ukmisc.org.uk> wrote:

[djbdns:]

> Providing you can tolerate the author's attitude, that is.

Not liking an author is a poor criterion for choosing software, in my
view. Not liking the proprietary djbdns package's design and
implementation, on the other hand, is a fine one.

http://linuxmafia.com/~rick/faq/inde...page=warez#djb

--
Cheers, "By reading this sentence, you agree to be bound by the
Rick Moen terms of the Internet Protocol, version 4, or, at your
rick@linuxmafia.com option, any later version." -- Seth David Schoen

>> Bind looks like it will do all we need, but we've heard a number of
>> security concerns with bind.
>
> Bind can run as user within a chroot jail with no problems. Adding
> some kernel patch like grsecurity to limit what processes can do under
> chroot will give you a fairly good setup to begin with.

While BIND can be locked down to some degree, I am still very suspicious of
the software. I mean, how many remote root holes do you find in software
before you just write it off as poorly designed, broken, hopeless? I don't
know about recent versions, but past versions used tons of resources.

Serving DNS queries is a simple task - it doesn't require local
authentication or privileges. It really amazes me how this DNS server,
BIND, has been such a network security problem historically.

I have tried djbdns in the past, and think it's a well written piece of
software. However, its installation style didn't agree with me at all. But
if I really had to set up a DNS server, I would still go with djbdns over
BIND. At the moment I only serve DNS for spam block list queries, which is
much easier than full fledged DNS.

--
Jem Berkes
Windows, UNIX software and system design
http://www.pc-tools.net/

Jem Berkes <jb@users.pc9.org> writes:

>>> Bind looks like it will do all we need, but we've heard a number of
>>> security concerns with bind.
>>
>> Bind can run as user within a chroot jail with no problems. Adding
>> some kernel patch like grsecurity to limit what processes can do under
>> chroot will give you a fairly good setup to begin with.
>
> While BIND can be locked down to some degree, I am still very suspicious
> of the software. I mean, how many remote root holes do you find in
> software before you just write it off as poorly designed, broken,
> hopeless? I don't know about recent versions, but past versions used tons
> of resources.

"Past performance is no indicator of future", as they say when advertising
stock-market scams... to some extent, it's probably true. I think the
answer is you review it for yourself and see how many cockups you can find
before writing it off.

Someone recently described bind-9 as a total rewrite; while I'm hazy about
that, I'm pretty sure I don't remember that many security-related updates
with it. So maybe people should distinguish based on `bind9' rather than
just `bind'.

> Serving DNS queries is a simple task - it doesn't require local
> authentication or privileges. It really amazes me how this DNS server,
> BIND, has been such a network security problem historically.
>
> I have tried djbdns in the past, and think it's a well written piece of
> software. However, its installation style didn't agree with me at all.
> But if I really had to set up a DNS server, I would still go with djbdns
> over BIND. At the moment I only serve DNS for spam block list queries,
> which is much easier than full fledged DNS.

One can get used to things. The OP can have a good play around for
themselves :)

~Tim
--
Remember, fish are FOOD not FRIENDS! |piglet@stirfried.vegetable.org.uk
|http://pig.sty.nu/Pictures/gallery/