djbdns

Djbdns is a standard developed by Daniel J. Bernstein DNS server. One reason for the development of djbdns were the security problems that occur repeatedly within BIND. Daniel Bernstein, a developer whose main focus is on the security of its applications, has $ 1,000 tendered to the person who finds a security problem of djbdns and can prove. This price has been paid only once for a very specific problem, what priced proponents as an indication of safety. However, critics point to the also written by Bernstein software qmail, in the presence of any bugs will be discussed, among other harsh of amber.

Details

The concept of djbdns is strong in contrast to that of BIND. While BIND all the functionality of the DNS server packages to the zone transfer service in a daemon, so this functionality is in djbdns divided into several components (not all components are treated here ):

Dnscache

The component dnscache is a DNS resolver and DNS cache. He answered questions about FQDN ( fully qualified domain names) by resolving the corresponding domain name of the root zone (. ) Made piece by piece. The results are then maintained until the set cache size has been exceeded or the TTL ( time to live ) of the respective Domain Names has expired.

Tinydns

The component tinydns is a DNS server that answers requests only on domain names that are available in its own database, other requests will be rejected without further reaction. The configuration of tinydns is very different from that of BIND. While a BIND zone file for each IP subnet is individually decorated, with tinydns this division does not exist. A single main configuration file will be used.

Rbldns

Spam mails were / are a growing problem, so blacklist servers were made ​​available, the unmasking open relays and other spammers via their IP address. Daniel Bernstein has written a daemon with rbldns and published, which can accept such requests and forwards them to the appropriate blacklist servers and caches the result.

Axfrdns

This daemon is responsible for answers via TCP, which are necessary for example, when UDP response packets for too long (more than 512 bytes ) are. He makes use of the same database as tinydns and can be viewed as a complement thereof. Furthermore, the operation of a daemon that listens on TCP, required by RFC 1035: "The Internet supports name server access using TCP on server port 53 (decimal) as well as datagram access using UDP on UDP port 53 (decimal). " Bernstein position on this is that you did something wrong when requests via TCP must be answered. In addition, support axfrdns zone transfers via AXFR, this is disabled by default and should be enabled individually for each zone and slave IP.

License

Since December 28, 2007 djbdns has been released into the public domain.

Before that, the source code was indeed made ​​publicly available, but Bernstein allowed neither the passing modified source code, nor the disclosure of the compiled executable from the source code files. Adjustments could therefore only be passed as a patch.

Swell

242606
de