- By Adib Behjat on June 1, 2012
ISC has always been supportive of Internet infrastructure development in Africa. In addition to being the first root-server operator to offer anycast instances in Africa, we have long provided Secondary Name Services (SNS) to a number of African ccTLDs as part of our public benefit mission. We have also sent our staff to AfNOG meetings to help in training on our FOSS (BIND and DHCP).
I was fortunate to attend the most recent Af*’s (AfNOG, AfriNIC, AfREN, AfPIF, AfGWG, etc) meeting in the Gambia which has been rebranded as the African Internet Summit. This rebranding reflects the maturity of the organizations involved in Internet coordination and the growing diversity of stakeholders who participate in Internet governance in the region. The conference was also graced by a fantastic speech by the Vice President of the Gambia Aja Dr. Isatou Njie-Saidy who seems to understand the importance of the Internet for African development. The African Governmental Working Group meetings continue to serve as a working model of Enhanced Cooperation in Internet Governance amongst many others who get much more international media attention.
Several ISC staff have roles in various RIRs and NOGs. I attended to finish my term as co-chair of the AfriNIC Policy Development Working Group. In addition to my volunteer role inside the RIR system, I was able to talk to a large number of folks about putting F-root servers in various locations (in addition to the existing nodes of Nairobi, Dar Es Salaam, Lagos, J’Burg and Cairo), offered SNS to ccTLDs and made plans to set up more BIND/DNSSEC/IPv6 training courses in Africa and other parts of the developing world with other like-minded Internet infrastructure organizations. African networks often use FOSS and BIND is widely deployed, so when I explained to people that I recently started working for ISC, the response was almost always “I use BIND”. I even saw some of our “layer-9″ t-shirts at the conference, which always brings a smile to my face.
ISC looks forward to continuing to provide operational, policy and technical expertise to the Internet eco-system community as part of our public-benefit mission. We plan to continue to work with our supporters and customers in the developing world to help spread the edge of the network and the benefits that internetworking bring.
- By Adib Behjat on May 21, 2012
At ISC we have recently received several inquiries from customers who are using the binary packages of BIND that we distribute for Microsoft Windows. They have expressed concerns about security vulnerabilities present in older versions of OpenSSL. BIND uses OpenSSL for securing communications between dynamic nameservers and clients and between master servers and slave servers. To support this functionality, ISC uses functionality from the OpenSSL libraries and ships libraries from the OpenSSL package with binary distributions of BIND. However, BIND only uses a small fraction of the features OpenSSL supports.[Note: this article applies only to customers who are using the Windows binary distributions of BIND provided by ISC. If you are compiling your own version of BIND from source or if you are using a binary package of BIND provided by someone other than ISC, this article does not apply.]
ISC monitors the security announcements for OpenSSL and has determined that none of the security defects disclosed in OpenSSL 1.0.0c (used by previous binary distributions of BIND) or OpenSSL 1.0.0i (used by the newest BIND binary distributions released today — BIND 9.9.1, BIND 9.8.3, BIND 9.7.6, and BIND 9.6-ESV-R7) affect functionality used by BIND code. Consequently, to the best of our knowledge, we believe the OpenSSL libraries we are distributing with the BIND binaries are safe for use with BIND only. We have not tested, nor do we recommend them, for use with other software.
If you have another package that requires OpenSSL libraries we ask that you remember that the versions we distribute with our package are only screened for vulnerabilities affecting the features BIND uses. For any other non-BIND uses we strongly recommend that you obtain copies directly from the OpenSSL project after consulting their bug fix and security announcement page at http://www.openssl.org/news.
- By Adib Behjat on March 2, 2012
BIND 9.9 is a new release of the gold standard for DNS servers on the Internet. It builds on a tried and trusted platform that has been evolving and maturing over more than 10 years and has kept adding new powerful and useful features with each new release.
In BIND 9.9 we have introduce several new features that can make a difference to how you operate your DNS service, no matter what size of an installation you have. Here is a brief rundown of why you should care about this new version:
BIND 9.9 improves performance in two main areas:
Re/Start speed. If you have lots of zones, you will see speedups in start/reconfig/reload times between 3x-20x.
Better I/O. When using a multithreaded build of BIND9.9 on a multicore machine, the work we have done on I/O optimisation will get you better performance for DNS query handling. You get this improvement automatically if you are using threads. To find out if you are, and a few more details about what is behind this, have a look at ISC’s knowledgebase article at https://kb.isc.org/article/AA-00629/109/Performance%3A-Multi-threaded-I-…
Trying to do DNSSEC but want to minimise changes?
If you have been thinking about deploying DNSSEC in your authoritative server but found it would change your established workflow too much, we have good news. BIND 9.9 introduces a feature called inline signing. This allows you to drop a BIND9.9 nameserver at any place in your DNS publication workflow to get your zones signed without having to change things that are already in place. It works by having BIND transfer in and unsigned copy of your DNS zones, handle the signing in a single spot, and make available a signed copy of the zone out the other end. If you drop this between your zone generation process and your current nameservers, it allows for transparent signing by just inserting this one additional step, rather than modifying what you already have. You can look at a few useful examples in ISC’s knowledgebase at https://kb.isc.org/article/AA-00626/0/Inline-Signing-in-ISC-BIND-9.9.0-E…
Redirection of non-existing names
With the pressure on revenue that everyone is seeing these days, ISPs have been resorting to the use of redirection of DNS queries that return non-existent domains to some ISP-defined user help information. While we understand the desire for this feature, ISC also firmly believes in the need for DNSSEC as a way to provide users with protection online. In that spirit our NXDOMAIN redirection implementation allows ISPs to implement their business models but preservers the integrity of DNSSEC-enabled users by disabling NXDOMAIN redirection if the user requests DNSSEC validation for DNSSEC-signed data.
- By Adib Behjat on January 26, 2012
I was so honored to participate in the TechWomen mentoring program in the summer of 2011. Meeting and working with my mentee, Sanae Baatti from Morocco, was a life changing experience. I wrote some about the TechWomen experience last summer. I was deeply honored as well, to travel to Morocco last fall with a state department sponsored TechWomen mentor and mentee delegation. I would encourage any technical woman in the San Francisco Bay Area to apply to be a TechWomen Technical or Cultural mentor this year. Supporting other women in realizing their dreams is one of the greatest gifts we can give – paying it forward – but the real gift is in what we get back.
Reprinted from – http://techwomenmena.wordpress.com/
Thank You TechWomen Mentors Posted on January 26, 2012
Today, as a part of National Mentoring Month, we would like to offer a warm and heartfelt thank you to our TechWomen Mentors. These women were an integral part of the program as they guided and encouraged Mentees from across the Middle East and North Africa in their cultural immersion and professional growth.
Here are just a few quotes from our Mentors about their experience with TechWomen:
- The Mentees were clearly deeply inspired by their time in the states, and we Mentors learned more than we expected, by a lot! I am left feeling passionate about new issues, reinvigorated in my own work, and looking forward to next year.
- This was a terrific initiative that really made a difference to the lives of participants. I know that as a Mentor I gained a lot of knowledge from it. Also am glad to expand my technical network both in the Valley and now in the MENA countries.
- The TechWomen experience was truly fulfilling, rewarding, and inspiring for me particularly because we all got an opportunity to contribute and learn from each other. This program has not only opened our minds to world but also out hearts. We have formed lasting relationships with the Mentors and Mentees in the program.
- This has been a life changing event for me — absolutely wonderful having such a large group of women Mentors and Mentees moving in the same direction with aligned goals. It was enlarging and invigorating. The women Mentees made me look at technology, Silicon Valley, the USA, learning, NGOs, etc. with a fresh and perhaps more appreciative perspective.
We invite you to visit our website to learn more about the TechWomen program and becoming a Mentor. Applications are now available.
- By Adib Behjat on November 21, 2011
Today, ISC is publishing a new beta release of BIND 9.9.0. As several new features have been added since the feature preview I posted on the occasion of the first alpha release, it would seem to be a good time for an update.
The new ‘inline-signing’ option, in combination with the ‘auto-dnssec’ option that was introduced in BIND 9.7, allows named to sign zones completely transparently. Before now, automatic zone signing only worked on master zones that were configured to be dynamic; now, it works on any master or slave zone.
In a master zone with inline signing, the zone is loaded from disk as usual, and a second copy of the zone is created to hold the signed version. The original zone file is not touched; all comments remain intact. When you edit the zone file and reload, named detects the incremental changes that have been made to the raw version of the zone, and applies those changes to the signed version, adding signatures as needed.
A slave zone with inline signing works similarly, except that instead of loading the zone from disk and then signing it, the slave transfers the zone from a master server and then signs it. This enables “bump in the wire” signing: a dedicated signing server acting as an intermediary between a hidden master server (which provides the raw zone data) and a set of publicly accessible slave servers (which only serve the signed data).
Note: A known bug in this release can cause master zones that use inline-signing to lose synchronization between the signed and unsigned versions. This will be addressed in a future release; in the meantime, this feature should be considered experimental. The problem has not been seen when using inline-signing with slave zones.
Other DNSSEC improvements
The new ‘rndc signing’ command provides greater visibility and control of the automatic DNSSEC signing process. When a zone is being signed, records are inserted into the zone indicating which keys are currently in the process of signing and which have finished (this enables named to resume the process correctly if there is a crash before the zone is fully signed). That state information is now visible:
- ‘rndc signing -list <zone>’ shows the current state of signing operations.
- ‘rndc signing -clear <key> <zone>’ or ‘rndc signing -clear all <zone>’ can be used to remove the records that say a key has finished signing. (If a key is still in the process of signing, then its record cannot be removed.)
- ‘rndc signing -nsec3param <parameters> <zone>’ or ‘rndc signing -nsec3param none <zone>’ can be used to set or remove the NSEC3 parameters for a zone. If this is used on a zone that has not yet been signed, then the specified parameters will be stored for use when the zone is signed.
Also, the new ‘dig +rrcomments’ option now provides more information about DNSKEY records, including each key’s ID, algorithm, and function within a zone (key-signing key or zone-signing key), in order to help with troubleshooting of DNSSEC problems.
- Locking performance has been improved, particularly with regard to recursive cilents; this allows better scaling with large numbers of threads.
- Slave zones are now saved in raw format by default. This can significantly reduce restart time on servers with large numbers of slave zones.
Security fixAs 9.9.0b1 is vulnerable to a recently discovered security flaw, anyone beta-testing 9.9.0 should switch to 9.9.0b2.