Blogs

We have nearly reached the end of the first year of the BIND 10 project. To celebrate this, we are releasing the first version of BIND 10.

This week at the ICANN meeting in Nairobi, a plan was announced by ICANN staff to create a "CERT" for DNS. That's a Community Emergency Response Team (CERT) for the global Domain Name System (DNS). There are all kinds of CERTs in the world today, both inside and outside the Internet industry. There isn't one for DNS, and that's basically my fault, and so I have been following the developments in Nairobi this week very closely.

The past few months, the BIND 10 developers have been using a test-driven development model. As classes and functions are coded, corresponding unit tests are also coded to help verify the routines do what is expected -- with good or bad input providing correct results. Sometimes the unit tests are written before the new code or the tests are written soon after.

Summary:

We have developed a patch to BIND 9 DNSSEC validator to address a recently reported problem that the validator can cause a massive number of DNSSEC related queries at a high rate when it's configured with a stale trust anchor.  This patch suppresses such queries by caching the trust anchor mismatch and temporarily caching other DNSSEC related responses toward the secure entry point, and should reduce the number of unnecessary queries by 1-2 orders of magnitude.  However, the validator periodically (and unsuccessfully) tries to check the validity of the trust anch

At the risk of having this blog begin to read like a FAQ, let me begin once again with the words, "folks have been asking me...".  So:

In the Fall of 2009, the organizations responsible for generating the root zone, ICANN, Verisign, and the US Department of Commerce, announced that they had come to a agreement on how to sign the root zone with DNSSEC (DNS Security Extensions) A website has been created by ICANN and Verisign to provide information about the change and a rollout timeline.

I was asked recently, "why is ISC a not-for-profit?" Apparently we walk
like a for-profit and we quack like a for-profit but we are in fact not
for-profit. Most companies with a strong brand like ours have share
holders. Why not ISC?

Primarily because the infrastructure we're responsible for -- BIND, F-root,
our network -- has to be kept in the public interest. If the current
staff and board got killed by a freak meteor shower, it's nice to know
that our successors couldn't take ISC's assets out of the public's service.

There is nothing more sensational than the unexpected, and when the NANOG (North American Network Operators Group) community was recently informed that an ASN collision had occurred it caused a lot of people to sit up and take notice. This event was also very interesting in that researching takes us back to a time before ARIN and RIPE existed, creating an interesting historical twist.