Context Navigation

Introduction

This page contains some ideas for people wishing to use the Google Summer of Code 2011 to participate in the BIND 10 project.

BIND 10 is written using Python and C++ - there is room in the project for people who are either skilled in either of these languages or who have a working knowledge and want to learn more by using them.

For students who are more interested in the operational side, we also have testing and integration work that needs to be done.

BIND 10 is currently a DNS-oriented project, so people interested in DNS will find the most applicable work. However, there are still many aspects of a modern Internet server that this project uses which require no knowledge of DNS at all. Also, the project will be expanding to cover DHCP starting in April 2011, and may be extended to provide other protocols in the future (for example TFTP). Anyone interested in any server protocol may find something useful.

Here are some possible ideas for BIND 10.

Additional Data Source back-ends

BIND 10 uses an abstract model to provide answers to DNS queries, when acting as an authoritative server.

The first back-end was SQLite, chosen because SQL was one of the most-requested features for BIND, and because SQLite is a very easy SQL to implement from an application point of view. It was not chosen because it is efficient or scalable or particularly useful.

The second back-end is an in-memory data structure designed based on the BIND 9 in-memory data structures. It was chosen because it has known properties and could be implemented with a very high guarantee of success.

BIND 10 has the goal of it being easy to add additional back-ends in a straightforward manner. So, implementing back-ends for popular open source database might be done, either as separate projects or as a single project. High-priority targets:

BDB (Berkeley Database - it was NoSQL before NoSQL was cool)

MySQL

PostgreSQL

Generic Data Source back-ends

BIND 10 also hopes to be useful for users who have information about their network in existing SQL databases, and do not want to duplicate this data in an external database for DNS. For example, people who use an in-house custom software & database when sales agents provision hosts for customers may prefer that their DNS queries are answered directly from that database.

This requires support for "generic" SQL back-ends, where we cannot define any particular schema. This means we cannot optimize the schema, and that we have to be careful about caching, but many (most?) corporate users will not care about those issues, or at least care less than the reduced cost of maintaining separate systems.

Work on DNS Recursive Resolver Testing

Interoperability Testing

BIND 10 is new, and needs to work with other, existing implementations. We need to make sure that it works well with them. This involves learning about a number of other DNS implementations as well as BIND 10, and defining both a testing framework and test cases to check for differences between the various versions, performing the tests, and reporting on the results. Ideally fixes (or proposed fixes) will also be done.

DNSSEC Key Management

DNS zones are secured by cryptographic keys, the public part of which is published in the zone in the form of a DNSKEY record. In addition, a related piece of information - the DS record - is published in the parent zone. Some form of management is required for these keys: depending on a organisation's policy, they may:

use one key to secure all their zones or have each zone secured by separate keys.

store the keys in disk files, hardware security modules (HSM), or offline on smart cards and the like.

replace the keys on a regular basis or only on exceptional circumstances - on HSM replacement or suspected security compromise.

Replacement of keys in a zone requires careful sequencing of events to ensure that name resolution is unaffected during the process. (Some of the issues involved can be found ​here.) For this reason, the scope of the management software includes the addition and removal of keys from the zone as well as communication with the BIND10 signing component with regards to what keys should be used to sign the zone.

Windows Port

BIND 9 supports Windows, but it is very much a Unix application forced to run in a Windows environment. We would like for BIND 10 to consider Windows a "first-class citizen". However, none of the current sponsors use Windows, and our developers all use Unix on their own systems, so it has not been a high priority. We would prefer that a free - at least as in beer - compiler was used for the port, so that people could hack on BIND 10 without having to pay a lot of money for a compiler.

Involved in this project would be:

Updating the build system to work in a Windows-friendly way

Figuring out the best model for concurrency and reliability (the Unix system uses multiple processes)