Providing DNS service in asia

[Kevin Darcy]

Phillip wrote:

> >I would like to set up a DNS service for the asia pacific region.
> >
> >I intend to provide Dynamic DNS, web updates, as well as local language
> >support (such as Chinese, Japanese, Korean, etc.)
> >
> >My domain names are:
> >
> >    SGDNS.com    - for Singapore and other asian countries
> >    OZDNS.com    - for Australian / New Zealand
> >
> >I am using Redhat Linux 6.2, and I am having trouble deciding whether to use
> >BIND 8.2.2P5, or should I go straight for BIND 9.
>
> Casey
>
> IMHO it is merely a matter of personal preference. I use both the ones
> you mention at various places (all of them small in terms of number of
> zones) and haven't had a problem with any. I'm also using 8.2.3-B5
> (or 6 - I can't check it at the moment) and its been very stable as well.
>
> While its not a problem for me, Bind 9 with many zones reputedly starts
> up more quickly that Bind 8, so you might like to try that. My only reservation
> is a possible vulnerability in Bind 9. I say "possible" because I have been
> unable to verify it but there is a comment in an article at Security Portal
> that states "Don't use beta or development versions of BIND on production
> servers, use 'stable releases'. e.g. avoid BIND 9.0.0 for now, it has already
> produced one root compromise." [ See
> http://www.securityportal.com/cover/coverstory20001002.html ] My reading
> of that was it was referring to the general release not the beta versions.

I don't read it that way at all. The "how to" part of the article says, flatly,
that BIND "is currently at V8", and the reference to V9 is only in the
"References" section, where it is labeled "BIND9 is under development" and says
little more than "An 'early release' 9.0.0 is available for the curious". There is
nothing about a root compromise in 9.0.0. Please don't start nasty rumors.


- Kevin

P.S. Actually, they don't even mention the root-compromise vulnerability of 8.2.1,
which I thought was rather odd. They mention three evils of an insecure DNS --
potential for proprietary information to be exposed, denial of service and loss of
data integrity -- but actually root compromise should (IMO, of course) be
emblazoned in big red letters ahead of all of these, since with root, all of the
other things are possible. Bit of a glaring omission, that...