djbdns ist ein von Daniel J. Bernstein entwickelter DNS-Server. Ein Grund für die Entwicklung von djbdns waren die immer wieder auftretenden Sicherheitsprobleme innerhalb von BIND. Daniel Bernstein, ein Entwickler, dessen Hauptaugenmerk auf die Sicherheit seiner Applikationen gerichtet ist, hat 1000 US-Dollar an diejenige Person ausgeschrieben, die ein Sicherheitsproblem von djbdns findet und nachweisen kann. Dieser Preis wurde bisher erst einmal für ein sehr spezielles Problem ausgezahlt^[2], was Befürworter als Indiz für die Sicherheit werten. Kritiker hingegen verweisen auf die ebenfalls von Bernstein geschriebene Software qmail, bei der das Vorhandensein eventueller Bugs unter anderem von Bernstein harsch diskutiert wird.

Das Konzept von djbdns steht stark im Kontrast zu dem von BIND. Während BIND sämtliche Funktionalität vom DNS-Server bis zum Zonentransferdienst in einen Daemon packt, so ist dieser Funktionsumfang bei djbdns in mehrere Komponenten unterteilt (nicht alle Komponenten werden hier behandelt):

Die Komponente dnscache ist ein DNS-Resolver und DNS-Cache. Er beantwortet Anfragen über FQDN (fully qualified domain names), indem er den entsprechenden Domainnamen von der root-Zone (.) aus Stück für Stück auflöst. Die Ergebnisse werden danach vorgehalten, bis die eingestellte Cache-Size überschritten worden ist oder die TTL (time to live) des jeweiligen Domainnamens abgelaufen ist.

Die Komponente tinydns ist ein DNS-Server, der nur Anfragen über Domainnamen beantwortet, die in seiner eigenen Datenbank vorhanden sind, andere Anfragen werden ohne weitere Reaktion verworfen. Die Konfiguration von tinydns unterscheidet sich sehr stark von der von BIND. Während bei BIND eine Zone-Datei für jedes IP-Subnetz einzeln eingerichtet wird, ist bei tinydns diese Aufteilung nicht vorhanden. Eine einzige zentrale Konfigurationsdatei wird verwendet.

Spammails wurden/werden immer mehr zum Problem, weswegen Blacklistserver zur Verfügung gestellt wurden, die Open Relays und sonstige Spammer über deren IP-Adresse entlarven. Daniel Bernstein hat mit rbldns einen Daemon geschrieben und veröffentlicht, der solche Anfragen entgegennehmen kann und sie an die entsprechenden Blacklistserver weiterleitet und das Ergebnis zwischenspeichert.

Dieser Daemon ist für Antworten per TCP zuständig, die zum Beispiel nötig sind, wenn Antwortpakete für UDP zu lang (länger als 512 Byte) sind. Er bedient sich aus der gleichen Datenbank wie tinydns und kann als Ergänzung dessen angesehen werden. Weiterhin wird der Betrieb eines Daemons, der auf TCP lauscht, vom RFC 1035^[3] gefordert: “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).” Bernsteins Position dazu ist, dass man etwas falsch gemacht habe, wenn Anfragen per TCP beantwortet werden müssen.^[4] Zusätzlich unterstützt axfrdns Zonentransfers per AXFR, dies ist jedoch standardmäßig deaktiviert und sollte für jede Zone und Slave-IP einzeln freigeschaltet werden.

Seit dem 28. Dezember 2007 ist djbdns als Public Domain freigegeben^[5].

Davor wurde der Quellcode zwar öffentlich zur Verfügung gestellt, aber Bernstein erlaubte weder die Weitergabe veränderten Quellcodes, noch die Weitergabe der aus dem Quellcode kompilierten ausführbaren Dateien. Anpassungen konnten daher nur als Patch weitergegeben werden.

• djbdns: Domain Name System tools. cr.yp.to (englisch)

1. ↑ The djbdns Open Source Project on Open Hub: Languages Page. In: Open Hub. (abgerufen am 18. Juli 2018).
2. ↑ Dominic Hargreaves: djbdns<=1.05 lets AXFRed subdomains overwrite domains. In: Debian Bug report logs. 4. März 2009, abgerufen am 10. September 2023 (englisch). 
3. ↑ RFC: 1035 – Domain Names – Implementation and Specification. November 1987 (englisch).
4. ↑ How to answer TCP queries. Cr.yp.to, abgerufen am 12. Juli 2010 (englisch). 
5. ↑ Frequently asked questions from distributors. Cr.yp.to, abgerufen am 12. Juli 2010 (englisch).