Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Reasons why BIND isn't being upgraded

  • From: Simon Waters
  • Date: Thu Feb 01 20:09:53 2001

Apologies for the delay - but I read the list in digest and this is my
first post.

I have done a slightly bigger survey of BIND version strings as of
16:00GMT Thursday February 1st, taking the nameservers for Keynote40
Business to Consumer sites and a selection of the domainnames from the
front page of

Of 440 DNS servers surveyed;
35% are reporting strings that clearly indicate use of 8.2.3 or better
(Hardly anyone is revealed to be using 9.0 or 9.1).
35% are reporting strings that strongly suggest they are susceptable to
known BIND bugs (Some are rather old versions of BIND are out there).

These figures charitably assume that;
 people who don't reveal version strings are not afflicted by BIND bugs.
 Bind variants that have source code modifications aren't affected -
they probably are, but I said we were being charitable.

So in answer to the question - are people too busy to upgrade BIND -
clearly 35% of admins found time to do it already. Those who had
upgraded to 8.2.2-P7 to avoid the previous DoS bugs should have had
nothing more to do than replace the binaries and test at 8.2.3, so I
think the time excuse is a bit thin.

Interestingly the sexsites were only marginally behind the Keynote40
sites, in terms of DNS versions. So perhaps your credit card number is
nearly as safe as your share portfolio.

Of the strings returned the most humorous was "SIN" from a sexsite. The
most constructive administrator entry was the admin e-mail address (But
since this is in the SOA resource record and RFC2142 (you do have all
the RFC2142 mail addresses don't you?!) I'm not awarding any prizes).

The ISC.ORG web site recommends leaving the BIND version string
unchanged to assist in troubleshooting. 

I remain unconvinced that showing the version string helps much.
Certainly any site with 7x24 hour technical support should consider
putting a relevant contact phone number IMHO - such that anyone trying
to diagnose a genuine problem can get help, whilst nosey crackers can
revert back to social engineering. (E-mail addresses may not be a good
choice if your DNS or their DNS is playing up?!).

Whilst you can add a "bind" zone of type Chaos and overwrite the default
behaviour, as given in an earlier post. Later versions of BIND let you
drop the version string in the options section, which is a lot less
typing, and a lot easier to understand. An extract of my BIND 9.1rc1
named.conf is given below, clearly my server is only listening to the
loopback address, but you'd be amazed how many times it has been queried
in the last couple of weeks whilst I got the scripts sorted.

options {
        directory "/etc/namedb";        // Working directory
        pid-file "";           // Put pid file in working dir
        listen-on {; };       // private server for
        listen-on-v6 { none; } ;        // No version 6 IP
        version "Contact +44(0)1395 232769";     // Don't release
version number

version ""; doesn't do what I expected at 9.1rc1.....

The survey mentioned above will form part of a bigger report, which was
inspired by the Microsoft debacle (Aren't those Akamai DNS servers
weird, oh and all Microsoft's e-mail relays have sequential IP addresses
- what planet are they on), so I will be checking which domains have all
their DNS servers (for which glue records exist) in the same network
(Based on 'NetName' - better ideas welcome from routing experts - can I
easily get IP to ASN?). If I have time I may include mail servers and
relays as well as DNS servers, of course if all your DNS servers are on
one network having off network mail relays won't help much when you muck
up the routing.



Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.