DJBDNS Howto Intranet/Internet

[nic0000]

Motivation:
Da ich mich mal wieder vor anderen Aufgaben drücke, werde ich etwas beschreiben was ich so halbwegs verstanden habe.

Über BJD:
DJBDNS von Daniel J. Bernstein gehört zu "sicheren" Alternativen zu Bind. Er wird häufig aufgezählt als "besser", "schneller" und viel "einfacher" zu konfigurieren. Allerdings schweigen sich die selben Personen auch sofort aus wenn es darum geht mal zu erklären wieso DJBDNS so einfach und gut ist oder wie genau die Installation/Konfiguration denn aussieht bzw. aussehen sollte.

Bernstein mag ein fähiger Programmierer sein, aber er ist dennoch ziemlich schwierig, ja ich würde sogar sagen "Zickig". Deshalb ist DJBDNS, als Abbild seines Schöpfers nicht ganz so einfach wie immer dargestellt zu verstehen. Ich kann aber durchaus sagen das DJBDNS und seine Konzepte mich überzeugt haben und ich Bernstein für diese Leistung bewundere.

Probleme:
Berstein legt zwar die Sourcen offen, erlaubt aber nicht die Änderung dieser. Das führt dazu das es Paches von dritter Seite nicht ohne Zustimmung von Bernstein Eingang in DJBDNS finden. Das erschwert den Authoren der Patches die Pflege der selben. Desweiteren darf seine Software, bis auf bestimmte Ausnahmen nicht Vorkompilliert vertrieben/verteilt werden.
Bei Gentoo ist weder das eine noch das andere ein großes Problem. Portage sei dank

Portage und USE:
Ich erkläre nicht so viel, da ich Teilweise nicht ganz verstehe was ich da mache.
Keine Ahnung ob alle diese Patches nötig sind:

+aliaschain
+cnamefix
+roundrobin
+semanticfix
-ipv6
-multipleip

Einige der USE bzw. Patches sind zu einander inkompatibel. Ich setze z.B. auf keinen Server ipv6 ein, daher lasse ich das weg und nehme andere dafür rein.

Code: Select all

echo "net-dns/djbdns aliaschain cnamefix roundrobin semanticfix -ipv6 -multipleip">>/etc/portage/package.use

Code: Select all

emerge djbdns -pv

Will folgendes auf unseren Server spühlen:

[ebuild N ] sys-process/daemontools-0.76-r5 -doc (-selinux) -static 36 kB
[ebuild N ] sys-apps/ucspi-tcp-0.88-r10 -doc -ipv6 (-selinux) +ssl 56 kB
[ebuild N ] net-dns/djbdns-1.05-r14 +aliaschain +cnamefix -doc -fwdzone -ipv6 -multipleip +roundrobin (-selinux) +semanticfix -static 101 kB

Anmerkung: Das sind alles Programme von Berstein. Sie gelten alle als sehr sicher, stellen aber teilweise das UNIX/Linux Konzept in Frage und sind als "besserer" Alternative zu bestehenden Lösungen angelegt ohne diese zu stören/beinträchtigen.

Theorie:
Was macht ein DNS Server?
Er setzt IP Adressen in DNS Namen um.

123.456.78.9 zu www.domain.com

sowie

www.domain.com zu 123.456.78.9

Die Client-Server Struktur des DNS Dienstes gibt dabei zwei Rollen vor:
Der "verwaltende" (Authorative) Server der sich um eine/mehrere Domänen kümmert, sowie ein Client (Resolver) welcher diese "verwaltende" Server befragt.

Der DNS Server beantwortet nur die Fragen zu den vom ihn verwalteten Domänen.
Der DNS Resolver beantwortet die Fragen zu allen Domänen.

Bei Bind sind beide Tätigkeiten verwischt und werden vom selben Programm erledigt.
DJBDNS hingegen unterscheidet strickt zwischen DNS Server und DNS Resolver.
Der "verwaltende" (Authorative) Server heißt "tinydns"
Der DNS Resolver heißt "dnscache"

Ich vertiefe jetzt nicht unnötig die Erklärung zu der Funktionsweise des DNS Dienstes, es soll nur einsteigern den Umgang mit DJBDNS erleichtern.

Wichtigste Regel im Umgang mit DJBDNS ist daß, tinydns und cachedns nie auf der selben IP laufen.
Das stellt aber kein Problem dar, denn ein Netzwerkfähiger Rechner (und nur solch einer braucht DNS überhaupt) hat mindestens Zwei IP Adressen.
Die "interne" loopback (127.x.x.x) sowie eine "externe" Adresse.

Erster Anwendungsfall:
============== Der Intranet Server ==============

Ein kleiner lokaler Server welcher eine "lokale" Domain hosten soll.
Ebenso soll der Server für das lokaler Netzwerk als DNS Resolver tätig sein.

Bei diesen Aufbau ergibt sich folgendes Schema:
Das "dnscache" muss für die anderen Rechner im Netzwerk erreichbar sein. Es lauscht auf der externen Adresse des Servers.
Der "tinydns" wird intern gehalten und beantwortet Anfragen über "dnscache" als Umweg.

Einrichtung:

-------------------------------------- Vorraussetzungen ---------------------
#Domain:

alpha.loc

#IP des Servers:

192.168.11.254

#IP des Workstation 1

192.168.11.1

#IP des Workstation 2

192.168.11.2

#IP des Workstation 3

192.168.11.3

Tinydns intern
Dnscache extern

-------------------------------------- Protokoll --------------------

#Den Richtigen "resolver" auf dem Server eintragen. In diesem Fall sind wir es selbst, aber über die externe Adresse!

Code: Select all

echo "search alpha.loc" 		> /etc/resolv.conf
echo "nameserver 192.168.11.254" 	>> /etc/resolv.conf

#svscan starten und überprüfen:

Code: Select all

/etc/init.d/svscan start
/etc/init.d/svscan status

#tindns anlegen (loopback):

Code: Select all

tinydns-conf tinydns dnslog /var/tinydns 127.0.0.1

#mit Daten füllen:

Code: Select all

cd /var/tinydns/root/

# Welche Domain soll verwaltet werden:

Code: Select all

./add-ns alpha.loc 127.0.0.1

# Das selbe für die "reverse" Auflösung:

Code: Select all

./add-ns 11.168.192.in-addr.arpa 127.0.0.1

!Wichtig ist hierbei die umgekehrte Schreibweise der IP!

# Unter diesen Namen soll der Server laufen:

Code: Select all

./add-host server.alpha.loc 192.168.11.254

# Unter diesen Namen sollen die Workstation laufen:

Code: Select all

./add-host eins.alpha.loc 192.168.11.1
./add-host zwei.alpha.loc 192.168.11.2
./add-host drei.alpha.loc 192.168.11.3

!Die "add-host" Direktive kann pro IP nur einmal vergeben werden!

# Der Server soll aber noch mehr Namen bekommen. Dazu wird die "add-alias" Direktive benutzt.

Code: Select all

./add-alias news.alpha.loc 192.168.11.254
./add-alias mail.alpha.loc 192.168.11.254
./add-alias www.alpha.loc 192.168.11.254

# Zu letzt soll der Domain auch ein Mailserver zugewisen werden. (Für die meisten wohl uninteressant)

Code: Select all

./add-mx alpha.loc 192.168.11.254

#Dieser Befehl liest die Daten in tinydns ein:

Code: Select all

make

#tindns starten:

Code: Select all

ln -s /var/tinydns /service/
ls -la /service/

# Es wird einfach eine verknüpfung in den /service Ordner gelegt. Der "svscan" den wir schon vorher gestartet haben wird dann sofort den Dienst versuchen zu starten und dafür Sorge tragen das er immer wieder angestartet wird, wenn er ausgehen sollte.
#start überprüfen:

Code: Select all

svstat /service/*

# Das sollte ein paar mal hintereinander aufgerufen werden. Hier sollte dann die Zahl der Sekunden immer größer werden. Wenn sie klein bleibt, dann ist etwas nicht in Ordnung.

Jetzt kommt das dnscache
#dnscache anlegen:

Code: Select all

dnscache-conf dnscache dnslog /var/dnscache 192.168.11.254

#zugriff lokales netzwerk erlauben

Code: Select all

touch /var/dnscache/root/ip/192.168.11

# Hierbei sollte die Netmask beachtet werden.
#delegation von Domänen an zuständige NS Server:

Code: Select all

echo 127.0.0.1> /var/dnscache/root/servers/alpha.loc
echo 127.0.0.1> /var/dnscache/root/servers/11.168.192.in-addr.arpa

# Damit sagen wir: Wenn du eine Anfrage über diese Domäne bekommst, dann leite sie an den tinydns weiter. Alles andere suche selbst.
#dnscache starten:

Code: Select all

ln -s /var/dnscache /service

#Erfolg überprüfen:
#lokal

Code: Select all

dnsip localhost
dnsip poseidon.alpha.loc
dnsname 192.168.11.1
dnsmx alpha.loc

#extern

Code: Select all

dnsip www.bettercom.de
dnsmx bettercom.de
dnsname 156.56.247.195

#Jetzt sollte bei den Workstations im Netzwerk als DNS Server unserer eingetragen werden.

Code: Select all

echo "search alpha.loc" 		> /etc/resolv.conf
echo "nameserver 192.168.11.254" 	>> /etc/resolv.conf

Jetzt erweitern wir den Server um andere Domänen (zu z.B. Entwicklungszwecken).
Dies geht ganz einfach, ich beschreibe jetzt eine extra Domain. Bei mehr ist entsprächendes zu wiederholen

#zusätzliche Domain:
beta.loc

##dnscache

Code: Select all

echo 127.0.0.1> /var/dnscache/root/servers/beta.loc

#Delegation der Dmäne an den zuständigen DNS Server:
#Das war es auch schon
##tinydns
#NS Server einpflegen (uns selbst)

Code: Select all

./add-ns  beta.loc 127.0.0.1

#Server und Rechner einpflegen. Das geht nur über Alias aus den weiter oben genannten Gründen:

Code: Select all

./add-alias server.beta.loc 192.168.11.254
./add-alias news.beta.loc 192.168.11.254
./add-alias mail.beta.loc 192.168.11.254
./add-alias www.beta.loc 192.168.11.254
./add-alias test.beta.loc 192.168.11.254

Code: Select all

./add-alias eins.beta.loc 192.168.11.1
./add-alias zwei.beta.loc 192.168.11.2
./add-alias drei.beta.loc 192.168.11.3

Jetzt kommt der zweite Anwendungsfall:

============== Der Internet Server ==============

###################################### Aufgabenstellung:

Es soll ersteinmal eine Domain "authorativ" im Internet verwaltet werden.

In diesem Szenario beantwortet der Server externe Anfragen nur zu "seinen" Domains. Alle anderen externen Anfragen werden abgewiesen.
Seine eigenen Anfragen beantwortet der Server sich selbst.

Ein kleiner Internet Server welcher eine "reale" Domain hosten soll.
Ebenso soll der Server für sich selbst als DNS Resolver tätig sein um nicht anfällig für "DNS cache poisioning" Attacken zu sein.

Bei diesen Aufbau ergibt sich folgendes Schema:
Der "tinydns" wird extern gehalten und beantwortet alle Anfragen zu seinen Domains direkt.
Das "dnscache" muss nicht für die anderen Rechner im Netzwerk erreichbar sein. Es lauscht daher auf der "loopback" Adresse des Servers.

Theorie:
Weil das natürlich viel zu einfach ist, kommt erschwerend hinzu das einige Vergabestellen (z.B. DENIC) auf einen 2ten DNS Server bestehen.
Einige Domainhoster (z.B. 1und1) setzen vorraus das es min. 2 DNS Server gibt auch bei anderen Top-Level-Domian wie .com/.net/.org/.biz/.info etc.

Aus diesem Grund schreibe ich die Einrichtung mit einem 2ten DNS Server. Erst in einem weiteren Teil werde ich die Synchronisation der beiden Server beschreiben (Ja, die Server müssen Synchron sein).

Dabei Teile ich schon Dienste auf die einzelnen Server auf. Dies kann natürlich anders gehandhabt werden.

Einrichtung:

-------------------------------------- Vorraussetzungen ---------------------
#Domain:

test-domain.org

#IP des ersten NS Servers:

99.88.77.66

#IP des zweiten NS Servers:

66.77.88.99

#Den Richtigen "resolver" auf dem Server eintragen. In diesem Fall sind wir es selbst, aber über die interne Adresse!

Code: Select all

echo "search test-domain.org" 	> /etc/resolv.conf
echo "nameserver 127.0.0.1" 	>> /etc/resolv.conf

#svscan starten und überprüfen:

Code: Select all

/etc/init.d/svscan start
/etc/init.d/svscan status

#dnscache anlegen (intern):

Code: Select all

dnscache-conf dnscache dnslog /var/dnscache 127.0.0.1

#Zugriff über loobback erlauben

Code: Select all

touch /var/dnscache/root/ip/127

# Hierbei sollte die Netmask beachtet werden. (Hier 255.0.0.0)

#delegation von Domänen an zuständige NS Server:

Code: Select all

echo 99.88.77.66> /var/dnscache/root/servers/test-domain.org

# Damit sagen wir: Wenn du eine Anfrage über diese Domäne bekommst, dann leite sie an den tinydns weiter. Alles andere suche selbst.

#dnscache starten:

Code: Select all

ln -s /var/dnscache /service

#tindns anlegen (loopback):

Code: Select all

tinydns-conf tinydns dnslog /var/tinydns 99.88.77.66

#mit Daten füllen:

Code: Select all

cd /var/tinydns/root/

# Welche Domain soll verwaltet werden und welche Server sind dafür zuständig:

Code: Select all

./add-ns test-domain.org 99.88.77.66
./add-ns test-domain.org 66.77.88.99

# Unter diesen Namen soll der erste Server laufen (IP 99.88.77.66):

Code: Select all

./add-host ernie.test-domain.org 99.88.77.66

# Unter diesen Namen soll der zweite Server laufen (IP 66.77.88.99):

Code: Select all

./add-host bernd-server.test-domain.org 66.77.88.99

!Die "add-host" Direktive kann pro IP einmal vergeben werden!

# Der Server soll aber noch mehr Namen bekommen. Dazu wird die "add-alias" Direktive benutzt.

Code: Select all

./add-alias ns1.test-domain.org 99.88.77.66
./add-alias www.test-domain.org 99.88.77.66
./add-alias server-a.test-domain.org 99.88.77.66

# Der Zweite Server soll auch mehr Namen bekommen.

Code: Select all

./add-alias ns2.test-domain.org 66.77.88.99
./add-alias news.test-domain.org 66.77.88.99
./add-alias mail.test-domain.org 66.77.88.99
./add-alias server-b.test-domain.org 66.77.88.99

!Natürlich dürfen keine Namen doppelt vorkommen und auf verschiedene IPs (Server) zeigen!

# Der Domain muß auch ein Mailserver zugewiesen werden (In unseren Fall soll der 2te Server zuständig dafür sein)

Code: Select all

./add-mx test-domain.org 66.77.88.99

#Dieser Befehl liest die Daten in tinydns ein:

Code: Select all

make

#tindns starten:

Code: Select all

ln -s /var/tinydns /service/
ls -la /service/

# Es wird einfach eine verknüpfung in den /service Ordner gelegt. Der "svscan" den wir schon vorher gestartet haben wird dann sofort den Dienst versuchen zu starten und dafür Sorge tragen das er immer wieder angestartet wird, wenn er ausgehen sollte.

#start überprüfen:

Code: Select all

svstat /service/*

# Das sollte ein paar mal hintereinander aufgerufen werden. Hier sollte dann die Zahl der Sekunden immer größer werden. Wenn sie klein bleibt, dann ist etwas nicht in Ordnung.

#Jetzt sollten bei dem Domainverwalter unsere NS Server als "zuständig" eingetragen werden. Wie das Funktioniert hängt von euren Verwalter ab.
Ich kenne nur 1und1 und dopoly.

Wenn jemand das interessiert könnte ich das beschreiben.
(Es hat zwar keinen interessiert aber trotzdem:
UPDATE: 03.07.2006 :
Wir setzen DJBDNS ein und benötigen dafür einen besonderen Aufbau der Records sowie fahren auch eine andere Startegie als BIND.

Der DJBDNS legt für jeden Namerver immer folgenden Eintrag an:

a.ns.domain.tld
b.ns.domain.tld
c.ns.domain.tld

BIND erwartet das hier:

ns1.domain.tld
ns2.domain.tld
ns3.domain.tld

DJBDNS sieht am liebsten jede Domain unter ihrer eigenen Verwaltung, während BIND immer auf eine andere Domain delegieren möchte.

DJBDNS

domain.tld = a.ns.domain.tld

BIND

domain.tld = ns1.domain-vom-provider.tld

Da BIND schon ewig existiert hat dieses Verhalten einzug in die Internet-NS-Richtlinien der meisten Vergabestellen gefunden. Über den Sinn oder Unsinn lässt sich streiten, fakt ist aber das Bernstein nicht unrecht hat mit seiner Argumentation welche hier nachgelesen werden kann:
http://cr.yp.to/djbdns/notes.html Speziell: Gluelessness

Um sich das leben mit DJBDN noch süßer zu machen muss aber Arbeit reingestekt werden, denn die Welt läuft ja nun mal auf Microsoft ..ääh.. BIND.

Kleiner Auszug in die Welt der Vergabstellen:
Ein NS Record kann nicht eine IP enthalten sondern muss ein FQDN sein. Was ist wenn die Domain sich selbst verwalten soll, also ausserhalb kein NS Server sich zuständig fühlen soll? Es gibt die Möglichkeit einen so gennten "Glue Record" anzulegen welche genau das umgeht. Also die IP des NS Servers ethält (anklebt)

Deshalb muss beim Registrator oder Domainreseller unserer Wahl ein Glue Record erzeugt werden.

Leider haben wir das Problem das jeder Registrator ja ein eigenes System unterhält. Ich kenne mich nur mit dopoly.de aus. (Wenn jemand andere Registartoren kennt, so soll er bitte mich ansprechen und den Vorgang beschreiben, ich werde diesen dann hier hinzufügen.)

Einen gluerecord anlegen bei dopoly.de:

Ich benutze dazu das API

Einloggen -> TOOLS -> ACCESS-CONSOLE

command = AddNameserver
nameserver = a.ns.domain.tld
ipaddress0 = 99.88.77.66

command = AddNameserver
nameserver = b.ns.domain.tld
ipaddress0 = 66.77.88.99

...

Dann kann auch beim anlegen der Einträge auf dem Server einfach ./add-ns benutzt werden.

/UPDATE:


FAQ:

Q:
Was ist ein primärer NS Server?
A:
Damit wird der Name Server bezeichnet auf dem die NS Einträge eingepflegt werden.

Q:
Was ist ein sekundärer NS Server?
A:
Damit wird ein oder mehrere Name Server bezeichnet auf dem die NS Einträge nicht eingepflegt sondern von dem primären NS Server kopiert werden.

Q:
Kann es mehrere primärer NS Server geben?
A:
Nein, es sollte nur einen geben. Das ist kein technisches sondern wird schnell zu einem managment Problem.

Q:
Was ist ein "hidden primary"?
A:
Das ist ein primärer NS Server, auf welchen die Daten eingepflegt werden um von sekundären NS Servern kopiert zu werden. Der "hidden primary" beantwortet selbst keine Anfragen und ist auch nirgends als NS Server eingetragen. Das ist Sinnvoll bei sehr großen Anforderungen, bei denen der Primäre Server mit beiden Aufgaben überfordert währe.

Q:
Muß der primäre NS Server als solcher gekennzeichnet werden?
A:
Nein. Es ist egal in welcher Reihenfolge die NS Server aufgelistet werden oder ähnliches. Der Primäre ist immer der auf dem die Datensätze verändert werden. Die Sekundären sind immer die welche die Daten sich kopieren. Nach außen müssen sie alle gleiche Informationen liefern! Deshalb sollte die Synchronisation (Replikation) beachtet werden.

Links:
Intranet:
http://www.better-com.de/de/dnshowto
Internet:
http://archiv.debianhowto.de/de/djbdns/ ... intro.html


Als nächstes kommt die Synchronisation von mehreren NS Servern
UPDATE: 03.07.2006 Nachtrag:
##################################### Kommunikation mit Bind:

#Leider soll hier der Secondary ein BIND werden. Aus diesem Grund wird noch ein axfrdns aufsetzen müssen, damit der BIND seine Informationen abholen kann.

axfrdns-conf tinydns dnslog /var/axfrdns /var/tinydns 99.88.77.66

Hier die Regeln um zwei NS-Servern die Replikation zu gestatten

1) 1und1 (212.227.123.29) mit den Domänen:

aaa-test.tld
bbb-test.tld
ccc-test.tld
ddd-test.tld

sowie

2) fikitiven (99.11.88.22) mit
aaa-hallo.tld
bbb-hallo.tld
ccc-hallo.tld

cat /var/axfrdns/tcp
# sample line: 1.2.3.4:allow,AXFR="heaven.af.mil/3.2.1.in-addr.arpa"
212.227.123.29:allow,AXFR="aaa-test.tld/bbb-test.tld/ccc-test.tld/ddd-test.tld"
99.11.88.22:allow,AXFR="aaa-hallo.tld/bbb-hallo.tld/ccc-hallo.tld"

axfrdns starten

ln -s /var/axfrdns /service

Den Start kontrollieren

svstat /service/*

/UPDATE:

@All
Bitte helft mir die ganzen Fehler zu beseitigen, die ich bestimmt gemacht habe

[chilla]

Danke für das Howto!

Was mcih aber nur wundert sind die ganzen Befehle. Wo werden die gespeichert? Gibt es nicht irgendwo eine konfigurationsdatei, wo man diese Sachen auch plaintext reinschreiben kann? Wenn die Befehle einmal abgesetzt wurden ist der zwar konfiguriert, aber irgendwo muss er die Konfiguration doch speichern, sonst is nach einem restart doch alles hinüber, oder?

[nic0000]

Gibt es nicht irgendwo eine konfigurationsdatei, wo man diese Sachen auch plaintext reinschreiben kann?

Ja so eine Datei existiert. Sie liegt im selben Verzeichnis und heißt

data

Sie kann per Hand editiert werden und kennt auch die "#" als Kommentarzeichen an.
Die Datei ist schon fast selbstklärend, kein Vergleich zu den Kofigurations-Albtraum von BIND!

Durch den make Aufruf wird sofort die Konfiguration ohne die Notwendigkeit tinydns neu zu starten aktiv.
Make generiert aus der "data" die "data.cdb" welche im selben Verzeichnis zu finden ist und diese Datei wertet tinydns dann auch aus.

[Fibbs]

Der Vollständigkeit halber sollte hier das kleine Webinterface "vegadns", welches auf http://vegadns.org/ zu finden ist, erwähnt werden.

Vorteile:
[*]Mehrbenutzerfähigkeit
[*]Templates (Neue Domain erhält automatisch x Einstellungen wie SOAs oder MXe)
[*]Simple Oberfläche

Die Daten werden per Cronjob in die djbdns-Datei umgewandelt und somit in tinydns eingespielt.

Gruß

Fibbs

[nic0000]

Der Vollständigkeit halber sollte hier das kleine Webinterface "vegadns", welches auf http://vegadns.org/ zu finden ist, erwähnt werden.

Davon habe ich auch mal gelesen. Du könntest ruhig etwas zu der Installation/Einrichtung erzählen.

[slick]

@ nic0000

Ich sage einfach mal im Namen der Community, für diese sicherlich nicht so nebenbei geschriebene, umfangreiche HowTo: Danke!

[nic0000]

Ich sage einfach mal im Namen der Community, für diese sicherlich nicht so nebenbei geschriebene, umfangreiche HowTo: Danke!

Vielen Dank Slick für die Blumen aber ich würde mich mehr darüber freuen wenn ein paar "Freaks" mal helfen würden die Fehler aus diesem Howto rauszubügeln.
Zum Thema Aufwand: Das basiert alles auf meinen Arbeits-Aufzeichnungen, denn ich bin so vergesslich, daß ich das brauche sonst weiß ich nach 3 Wochen nicht mehr das ich es überhaupt mal gemacht habe.
Wo wir doch beim Thema Vergesslichkeit sind:
Erinnere mich daran die Synchronisation zwischen DJBDNS<->DJBDNS sowie DJBDNS->Bind mal zu beschreiben.
Heute bin ich zu müde....

[nic0000]

*bump*
Habe im ersten Post etwas hinzugefügt zum Thema: Registration und Einträge beim Registrator/Reseller
Zu finden ab
UPDATE: 03.07.2006

EDIT2
Habe noch endlich etwas zu "axfrdns" geschrieben
Zu finden ab
UPDATE: 03.07.2006 Nachtrag: