Archiv verlassen und diese Seite im Standarddesign anzeigen : djbdns trotz vieler Quellen verstehen!
Hallo!
Möchte djbdns begreifen, hab aber defintiv Verständnisprobleme und hoffe Du hingegen ausreichend Erfahrung!
Besuchte seiten (und trotzdem noch nicht kapiert):
djbdns-home, eh klar! (eher unübersichtlich)
djbdns.org und deren Verzweigungen z.B. Felix von Leitner, etc.
qmail.org ...
Der Wunsch für mich und den Rest der armen DNS-Server da draussen:
Zwei Maschinen unter SuSE versch. Rel.;
BIND8 (geschädigt; nicht 100% einbandfrei konfiguriert - schliesse ich hier nicht aus!)
Erste Maschine:
Prim.-Server mit Apache, verwaltet ~xx Domains (derzeit standby - nicht zu verkaufen!)
Sec.-Server mit sendmail
umzustellen auf das Ziel:
djbdns auf
Maschine IP: 1.2.3.4 um damit aktive Apache-Sites (hoffentlich bald) betreiben zu können; als reg. ns.example.com gefunden werden zu können, bzw. Domains auf ihm;
Maschine IP: 5.6.7.8 um darauf qmail zu betreiben und als reg. ns1.example.com gefunden, bzw. seine Domains, zu werden.
Richtig oder Falsch Fragen:
1.) Was jetzt passieren sollte ist ein auf beiden Maschinen eingerichtetes tinyDNS, allerdings mit unterschiedlicher data.cdb (Warum: ns. und ns1.; Quelle: www.lifewithdjbdns.org, dort unter 5.1.2)?
2.) Wie bzw. wo bekomme ich alle, bei bind "named.conf" Daten unter, meine Domains werden wie - wo eingetragen? Möchte keinen Übertrag aus bestehender Installation vornehmen, sondern "nacktes System" konfigurieren! (Genug Utilities gefunden, sind aber aus vorrausgegangenen Gründen nicht einsetzbar!)
3.) Wie und wo kommt jetzt dnscache zum Einsatz, vor allem irritierend ist ein von Felix von Leitner geführtes FAQ das unter Punkt 4.,6.,7. mir unklar ist - dabei kommen mir seine Formulierungen sehr sauber vor - ich kapiers nicht.?
Mehr Details notwendig - bitte anführen(aufzählen), mein Kopf raucht und die Energie wird leider nicht ökologisch wiederverwertet im Moment!
Vielen Dank für Deine, Eure Hilfe!
Hab mir gerade das von einem propagierte HowTo (vlug.sourceforge.net/howto/djbdns) geholt!
Hierbei passiert wieder genau das, so ich es richtig interpretiere, dnscache und tinydns die gleiche ip-verpasst bekommen; das ist laut Felix von Leitner FAQ (http://www.fefe.de/djbdns/) Punkt 4 "Don't do this on production name servers!" - meine wären das aber, - oder nicht? Somit nicht oder nur modifiziert anwendbar.
für adresse, die nur intern gültig sind, brauchst du nichts zu ändern (tritt wahrscheinlich bei dir nicht auf, also kannst du dir die konfiguration von tinydns wie in meinem howto beschrieben sparen)
du brauchst wahrscheinlich nur einen tinydns, der an die externe adresse gebunden ist
zur performancesteigerung, bei abfragen der eigenen domains ist es sinnvoll, den tinydns server dnscache bekanntzumachen
echo public-ip > /var/dnscache/root/servers/domain bzw reverse-subnet.in-addr.arpa
die daten für tinydns stehen alle in data.cdb bzw im Makefile (das hinzufügen von einträgen geht ganz leicht mit add-host und add-alias, löschen mit beliebigem editor aus Makefile)
zu dnscache: dieser antwortet auf die anfragen lokaler programme, bzw von rechnern im lokalen netz
Danke für Deine Hilfe!
Schön langsam wird es, mit dem Kapieren!
Ich füge noch Richtig - Falsch? Fragen hinzu, ohne direkt auf Dein posting zu antworten - schon jetzt Danke für Deine Response!
Für mich hat sich folgendes herauskristallisiert:
Gebraucht wird auf meinen "Prim. und Sec." nur tinydns, da beide nur "extern" per Standleitung am Netz hängen und keine lokalen Maschinen direkt darauf zugreifen?
Gleich gehts weiter... diese Zeichen-Beschränkung nervt! (?)
tinydns benötigt auf beiden Maschinen die gleiche data.cdb die dann wie folgt aussehen sollte (Quelle: www.lifewithdjbdns.org - 5.1.2):
#define the authoritative nameserver
.example.com::ns.example.com
#mail exchanger
@example.com::mail.example.com
#IP for Prim., Sec.
=prim.example.com:1.2.3.4
=sec.example.com:5.6.7.8
#Prim. is also known as ns
+ns.example.com:1.2.3.4
#Sec. is also known as ns1
+ns1.example.com:5.6.7.8
#Sec. is our mailserver
+mail.example.com:5.6.7.8
#and our webserver
+www.example.com:1.2.3.4
stimmt das so??? (Richtig interpretiert?)
Wo kommen jetzt Domain abc.com, def.com, ghi.com, etc. unter? Wie werden diese richtig zugeordnet?
Wie ist das mit svc?
Wenn ich den Dienst tinydns oder aber auch dnscache per svc verwalten will...
zum Beispiel stoppen von dnscache, wäre folgende Befehlsreihenfolge richtig:
svc -t /service/dnscache
bei tinydns
svc -t /service/tinydns ?
...Modifikatione vornehmen und dann per
z.B.:
ln -s /etc/tinydns /service ...wieder starten?
1. data.cdb ist eine datenbank, die plain-text variante heißt "data"
2. am einfachsten gehen die änderungen über die add-*** skripte (nur bei den rpms von bruce guenter?)
nur das löschen von einträgen würde ich durch direktes editieren machen
3. dnscache brauchst du auch (für die abfragen der lokalen programme, wie qmail und apache), sinnvollerweise läuft dieser dann auf 127.0.0.1
4. svc -t sendet ein TERM signal an den service, danach wird er automatisch neu gestartet
supervise-scripts (svc-***) zum dauerhaften beenden/entfernen etc
5. wenn du mehrere domains hostet, musst du sowohl den nameserver als "authorative" für die domain eintragen(falls du das bist, das ist der nameserver der beim NIC eintrag drinsteht), als auch die ip's (wird ja immer die gleiche sein) und aliase der einzelnen (virtuellen) hosts
Wieder danke und in Ordnung was dnscache betrifft!
Zu deinem Punkt 5:
. wenn du mehrere domains hostet, musst du sowohl den nameserver als "authorative" für die domain eintragen(falls du das bist, das ist der nameserver der beim NIC eintrag drinsteht),
JA, bin ich.
als auch die ip's (wird ja immer die gleiche sein)
JA, ist klar.
und aliase der einzelnen (virtuellen) hosts
...könntest Du mir dazu ein Beispiel reintippen bzw. Dich zur oben angeführten data.cdb äussern.
Das wäre toll und Danke für Deine Geduld!
Wo finde ich die .rpms von diesem Guenter, laufen die auch in SuSE-Umgebung korrekt?
auf untroubled.org
wahrscheinlich gibts probleme mit den rpm install skripten, da das useradd bei suse nicht alle parameter des redhat useradd verträgt (zumindest bis zur 7.1 kann ich das bestätigen)
du musst also wahrscheinlich die src.rpms nehmen und die skripte ändern (bei qmail musst du das sowieso, also was solls)
diese schritte für jede domain (deine eigene domain sollte natürlich schon eingerichtet sein, inklusive der ip des nameservers):
./add-ns example.com ns1.hoster.de
./add-host www.example.com 1.2.3.4
./add-host mail.example.com 5.6.7.8
./add-alias ftp.example.com 1.2.3.4
...
./add-mx example.com mail.example.com
das dürfte praktisch mit deinem aufgeführten "data" file identisch sein
Muß gerade eine Maschine "hardwareseitig" bearbeiten, melde mich wieder mit Ergebnissen - bin zuversichtlich, alles viel klarer als noch zu Beginn, zu sehen. - Recht herzlichen Dank!
Hallo bin wieder da und habe folgende Schritte vollzogen:
Auf meiner ersten Maschine (Prim.) dnscache auf 127.0.0.1 eingerichtet; tinydns auf externe IP gestartet und wieder per Hand die data.cdb gestaltet; wobei ich jetzt glaube alles richtig verstanden zu haben - welcher Eintrag was aussagt und bewirkt.
Frage zu dnscache:
Der muss ja jetzt alle gehosteten Domains auflösen können, wie geh ich da jetzt vor, wo lass ich dnscache die notwendigen Daten holen?
Jetzt die große Frage an Dich - euch (bedingt durch zuwenig Praxis!):
Wie teste ich dann/jetzt auf die einbandfreie Konfiguration der Maschine - sodas ich keinen Müll ins Netz produziere(!)?
Danke!
Seit dem die Maschine am Netz hängt funktioniert ein nslookup auf 127.0.0.1 nicht mehr - Warum? Wo müsste ich einen Fehler gemacht haben?
1. nslookup ist ein ziemlich veraltetes tool, nimm host oder dig
2. zur lösung des problems (1. trägt dazu sicher nicht dazu bei, naja vielleicht doch):
/etc/resolv.conf muss "nameserver 127.0.0.1" enthalten
wenn dann "host 127.0.0.1" noch kein ergebnis liefern sollte:
touch /service/dnscache/root/ip/1.2.3.4
> Der muss ja jetzt alle gehosteten Domains auflösen können, wie geh ich da jetzt vor, wo lass ich dnscache die notwendigen Daten holen?
du könntest "echo 1.2.3.4 > /service/dnscache/root/servers/example.com" und "echo 1.2.3.4 > /service/dnscache/root/servers/4.3.2.1.in-addr.arpa" machen
dann hast du aber keine realen testbedingungen (abfrage geht nicht über root-ns und nic), ich würde das aber trotzdem so machen und zum abschluss von einem normalen rechner aus testen (wenn der server dann online ist)
wenn der rechner am netz hängt, solltest du die einträge wieder entfernen, da diese vorgehensweise eigentlich nur für lokale (private) domains gedacht ist (insbesondere die reverse lookups)
ad 1. Danke für den Hinweis, hab mich gleich damit auseinandergesetzt!
ad 2. In resolv.conf steht (sollte ja so sein):
domain example.com
nameserver 127.0.0.1
host 127.0.0.1 liefert jetzt:
1.00.127.IN-ADDR.ARPA domain name pointer localhost
host example.com liefert:
host not found, try again
Anwendung von (mit meinen IPs!):
echo 1.2.3.4 > /service/dnscache/root/servers/example.com
und
echo 1.2.3.4 > /service/dnscache/root/servers/4.3.2.1.in-addr.arpa
Über andere Maschine versucht zuzugreifen (pingen geht), leider kein Erfolg.
Lokal bringt jetzt auch host 127.0.0.1 nur mehr "host not found, try again.
Hab versucht per svc -t /service/dnscache einen Neustart des Dienstes gemacht, leider kein Erfolg.
Bitte um Vorschläge, Danke für Antwort!
> host 127.0.0.1 liefert jetzt:
>
> 1.00.127.IN-ADDR.ARPA domain name pointer localhost
>
> host example.com liefert:
host not found, try again
ist doch ok!
host example.com kann ja kein ergebnis liefern, ist ja kein host
"host ns" oder "host ns.example.com" sollte dagegen funktionieren
Du hast recht, klar - was ganz interessantes - und für mich jetzt nicht ganz klar!
Wenn Du meinen letzten Eintrag liest... hab ich doch geschrieben und so war es gestern auch nach Eingabe deines Vorschlages in per echo >... umzuleiten bekam ich auf der Maschine nur (bei Eingabe von "host 127.0.0.1" bzw. host ns.example.com") host not found try again. Die Maschine war zwecks Übersiedlung ins Rack heruntergefahren, jetzt frisch eingeschaltet --->
wie Du schreibst, einbandfrei! Jetzt funktionierts ganz sauber, wie es sollte und host liefert in beiden Fällen korrekte Angaben!
Ist der echo... Befehl also nur temporär und durch Neustart des Dienstes erledigt???
Oder wo sind die Einträge (in welchem File?) die ich wieder entfernen muß?- Hab ich da vielleicht noch eine Fehlerquelle?
Hab per Eintrag in die "run-Skripte" bei dnscache & tinydns jeweils ./main ersetzt durch ./var/log/dnscache bzw. tinydns (Verzeichnis wurde durch "User" dnscache/tinydns angelegt und existiert, ist aber noch (?) leer) , um die log-Ausgabe umzuleiten - kann sich ein weitreichender Fehler sonstiger Natur eingeschlichen haben???
Vielen Dank für die tolle und hilfreiche Konversation!!!
Jetzt kann ich auch auflösen von der Testmaschine her, die ich drangehängt habe - bin ganz glücklich und strahle!!!
Was sollte aber nicht übersehen werden, wo und wie sollte ich nochmal "cross-checking" betreiben?
Jetzt wird es kryptisch!!!
Habe Domains der data (editiert, anschl. make) hinzugefügt. Von der Testmaschine wurden Änderungen korrekt, sprich durch Einsatz von z.B. host mail.istjatoll.com korrekt beantwortet/aufgelöst.
Lokal am Server ausgeführtes z.B. "host ns" bringt schon wieder "host not found, try again" - Die einfache Frage, was hat es da jetzt?
Hab "svc -t /services/tinydns" durchgeführt, keine Wirkung - entfernte Testmaschine löst immer noch richtig auf - lokal nichts.
Mache einen reboot der Maschine und probiers nochmal.
1. Schritt über Testmaschine per host, Auflösung testen; - OK!
2.Schritt lokal per "host 127.0.0.1" bzw. "host ns" beides liefert die richten Antworten; - OK!
Warum dieser Hänger auf lokal nach ändern der data.cdb??? - Grosses Fragezeichen? (Abstand zur erneuten Abfrage zuvor bei lokal sicher >1 min., falls Zeit eine Rolle spielt.)
Wird immer interessanter...
Während ich diesen Beitrag geschrieben habe sind vielleicht 3-5 min. vergangen, an der ich auf der lokalen Maschine nicht abgefragt habe.
Dann wieder über Testrechner - wunderbar funktioniert ja; beim lokalen Abfragen "host ns" schon wieder host not found... - da hat es was gröberes! - Nur was???
Habe jetzt diese von mir gänderten run-Skripte wieder auf Original umgebaut; ein svc -t /services/dnscache und /tinydns durchgeführt; host ns passt jetzt wieder - probiers wieder in 5 min. - bin gespannt!
Scheinbar war es das mit den log-Daten in ein anderes Verzeichnis umlegen - den Vorgang hab ich anscheinend seitens "Lifewithdjbdns.org) falsch interpretiert ausgeführt.
Den jetzt sind sofort, vorher nicht, die log-files im "Standard-Verzeichnis zu finden.
Lokal kann er jetzt auflösen:
- host 127.0.0.1
- host ns
- host ns1
- host ns.example.com
- host ns1.example.com
- host www.example.com
- host mail.example.com
sonst nichts (stimmt so, oder?)
beim entfernten Testrechner, funktioniert die gesamte Auflösung aller eingetragenen Domains.
Sollte somit alles in Ordnung sein? Freue mich über ein bestätigendes JA + Antworten zu letzten Beiträgen, wenn es Deine, (ich glaube auch daran) eure Zeit erlaubt!
DANKE!!!
was du da an den start skripten umgebaut hast, kann ich von meiner seite aus nicht nachvollziehen
nach abgeschlossenem lokalen test solltest du auf alle fälle von einem anderen rechner (über anderen isp) aus testen
ansonsten halte ich die konfiguration für ok (soweit ich das von hier überblicken kann)
Wollte (per Anleitung in www.lifewithdjbdns.org) die log-files in jew. Verzeichnis /var/log/dnscache bzw. tinydns umleiten; um so eine übersichtlichere Struktur aufzubauen. Dabei hab ich defintiv was falsch gemacht.
Was solls, das Wichtigste ist, das es läuft - einbandfrei!
Über anderen ISP kann ich im Moment nicht testen, folgt aber bald.
Recht herzlichen Dank an rbla für die großartige Unterstützung und die Betreiber der linuxforen.de!!!
Der nächste Schritt, wie sollte es anders sein; einrichten von qmail.
Da kanns passieren, das ich ein neues Thema anfange - seh mir aber nach erfolgter Installation die Unterstützung durch WebMin-Modul an und schau was dabei rauskommt. Bis bald.
Ich muss nochmal nachhaken weil mir nichts mehr einfällt! Ich komm einfach nicht drauf.
Mein Sec. hat den gleichen Installationsablauf erfahren, wie die Maschine (Prim. + gleicher data.cdb) bei der wir zum Erfolg gekommen sind.
So es funktioniert einbandfrei:
- host 127.0.0.1
- host ns
- host ns1
- host ns.example.com
- host ns1.example.com
- host www.example.com
- host mail.example.com
was geht vom entfernten Testrechner ist pingen - Verbindung steht;
was nicht geht vom entfernten Testrechner, er löst nicht auf???
Liegen muss es damit an tinydns, aber was kann jetzt wieder sein... :confused: :confused: :confused:
Bitte nochmal um Deine/eure Hilfe - Vielen Dank!:(
bitte die ausgaben von
auf server:
netstat -tanup
auf testrechner
cat /etc/resolv.conf
von Server per netstat -tanup:
Hab da kurz ein Problem...
Bin wieder da!
Folgende Angaben wurden nur betr. IP modifiziert (Prim.-IP 1.2.3.4; Sec.-IP 5.6.7.8); vorherschendes Problem betrifft Maschine mit Sec.-IP 5.6.7.8
Ausgabe von netstat -tanup:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
PID/Program name
tcp 0 0 0.0.0.0:515 0.0.0.0:* LISTEN
600/lpd Waiting
tcp 0 0 0.0.0.0:45222 0.0.0.0:* LISTEN
972/perl
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
447/portmap
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
970/httpd
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN
852/X
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
996/dnscache
tcp 0 0 0.0.0.0:7741 0.0.0.0:* LISTEN
779/lisa
tcp 0 0 127.0.0.1:956 127.0.0.1:111 TIME_WAIT
-
tcp 0 0 127.0.0.1:924 127.0.0.1:111 TIME_WAIT
-
tcp 0 0 127.0.0.1:925 127.0.0.1:111 TIME_WAIT
-
tcp 0 0 127.0.0.1:922 127.0.0.1:111 TIME_WAIT
-
tcp 0 0 127.0.0.1:923 127.0.0.1:111 TIME_WAIT
-
tcp 0 0 :::113 :::* LISTEN
532/in.identd
tcp 0 0 :::22 :::* LISTEN
380/sshd
udp 0 0 0.0.0.0:10000 0.0.0.0:*
972/perl
udp 0 0 127.0.0.1:53 0.0.0.0:*
996/dnscache
udp 0 0 5.6.7.8:53 0.0.0.0:*
994/tinydns
udp 0 0 0.0.0.0:7741 0.0.0.0:*
779/lisa
udp 0 0 0.0.0.0:111 0.0.0.0:*
447/portmap
vom Testrechner (Modifikation IP s. oben):
cat /etc/resolv.conf:
domain local
nameserver 1.2.3.4
Entschuldigung :D
Hätte halt beim Testrechner den nameserver-Eintrag setzen sollen! Bitte nicht ärgern weil ich Dich da jetzt umsonst nochmal bemüht habe!
Danke für Deine Antwort!
Da Du jetzt nochmal reinschaust um mir behilflich zu sein.
Eine Kleinigkeit ist eigenartig, die Trägheit bei der Abfrage - wie erklärt sich die? Antwort benötigt gute 1-2 sec.; bei Maschine 1.2.3.4 ist sie im Msec.-Bereich.
Hab mir weiters alles nochmal durchgelesen und möchte nochmals kurz daraufzurückkommen, das auf den beiden Server lokale Abfragen z.B. www.example4.com nicht funktionieren; sprich alle anderen Domains werden lokal nicht aufglöst!
Ist das so in Ordnung was die Funktionalität betrifft für später qmail, Apache?
Bzw. welche nameserver-Einträge setze ich am geschicktesten bei meinen Server, die des ISP's plus jeweils die des anderen (=Prim-IP 1.2.3.4 erhält ns.ISP, ns1.ISP + 5.6.7.8 - und umgekehrt)???
Momentan steht ja nur (oder darf nur?) 127.0.0.1 drinnen. Vielleicht denk ich auch schon wieder nur um "gerade Ecken"...?
in der resolv.conf steht nur 127.0.0.1 drin (das bleibt auch so)
zur namensauflösung der eigenen domains kannst du zwei wege gehen
1. über dnscache -> root-ns-> nic -> tinydns (bei dir)
dazu brauchst du gar nichts weiter einstellen (die einträge die beim nic vorgenommen wurden, müssen natrülich auf deine rechner zeigen)
nachteil: änderungen können einige zeit dauern und bei ausfall der leitung kannst du lokal deine domains nicht auflösen
2. dnscache -> tinydns
dazu musst die domains in /service/dnscache/root/server/ eintragen
(habe ich dir weiter oben schon mal beispielhaft gezeigt, bzw steht auch in meinem howto)
nachteil: du siehst vom server aus nicht, ob es irgendwo probleme gibt (nic)
außerdem ist der änderungsaufwand größer
(kopieren der dateien "example.com")
ronny
Wieder ein grosses DANKE an Dich!
Ver.2 gefällt mir ganz gut, da ja mein System dann ja quasi autark läuft (-so man das so sagen kann).
Das bedeutet dann
filename: example.com file-Inhalt 1.2.3.4
example1.com 1.2.3.4
example2.com 1.2.3.4
usw. ... ...
Gegen die Mehrarbeit ist nichts einzuwenden und betr. deinem Verweis "früher", momentan sitz ich nur vor "Kisten" da raucht der Kopf und das Hirn kriegt (noch größere) Löcher:D
Dazu dann aber gleich die Frage wie halt ich, (als interessierter und lernender Admin) - mit welchen Tools, die Übersicht darüber, wenn es beim nic mal nicht läuft, bzw. von dort die "Probleme kommen"?
in dem du so zugreifst wie ein "normaler" besucher der sites
über einen x-beliebigen provider testen (sprich von außerhalb)
Hallo! ;)
Also djbdns läuft jetzt einbandfrei (außer ich hätte noch irgendwo einen Fehler eingebaut - glaub nicht!) und ich muß sagen - danach, es ist wirklich gut und (mit Vorsicht) leicht einzurichten. Dein Tip betreffend der lokalen Namen-Auflösung funktioniert einbandfrei, schön wenn die Kisten tun was man will!
Wieder ein großes Danke an Dich Ronny!
Erlaube mir die Fragen (2 Stück): Möchte/Muß noch folgende Themen behandeln (wie schon erwähnt, zuwenig allgemein Erfahrung):
1.) qmail einrichten
Dazu gleich meine wichtigste Frage habe herumexperimentiert, es eingerichtet (kompiliert und installiert) per Anleitung "lifewithqmail" und die Übersicht verloren! Wie kann ich, hoffentlich ohne Neuinstallation, das "Experiment" möglichst gründlich entfernen - um dann ein frisches qmail-System aufzusetzen?
Wenn Du keine Zeit, Lust hast mir darauf zu antworten - ich weiß - diese Dinge gehören zu den Grundlagen; Wo finde ich am ehesten Unterstützung? - Vielen Dank!
2.) Ich denke, so ich WebMin einsetze und dort die "Running process"-Liste bzw. "Bootup and Shutdown" durchsehe; Welche Dienste haben auf einem "production-server" nichts zu suchen und sollten der Sicherheit halber vom Start-weg deaktiviert sein?
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.