|
DNS Client und Server mit Debian
Hi,
ich gebe auf, weiß nicht mehr wo ich suchen soll - folgendes Problem: Einmal ein DHCP und DNS Server fürs interne Netzwerk, und dazu 2 Clients mit Dualbootsystem WinXP und Debian. Wenn ich Win boote dann geht ping Rechnername, boote ich Debian geht es nicht. Auf dem Server hab ich alles nach WCM-Familienserver Anleitung gemacht. Der DHCP-Server funktioniert anstandslos, aber wenn ich in /var/lib/dhcp-dns schaue dann finde ich dort keine aktuellen Einträge. dns.last ist überhaupt leer Der Client hat in seiner resolv.conf den Server als Nameserver eingetragen. Außerdem habe in der dhclient.conf eine Zeile mit send host-name eingetragen. Ich studiere jetzt schon den ganzen Tag die config-Files und weiß nicht mehr ob ich auf dem Client oder auf dem Server nach dem Fehler suchen soll. Ich bin bald so weit einfach die Namen in der hosts einzutragen - aber eigentlich will ich das nicht - das muß doch so auch gehen.... Bin dankbar für jeden Tip!! Gruß brigh |
Was steht beim Client in /etc/network/interfaces?
> ping Rechnername von welchem Rechner zu welchem Rechner? mfg c. |
Hi,
die /etc/network/interfaces auf dem Client sieht so aus: # The loopback interface auto lo iface lo inet loopback # The first network card - this entry was created during the Debian installation auto eth0 iface eth0 inet dhcp ping Rechnername geht nur von Client zu Server weil ich den Server in /etc/ hosts eingetragen habe. Der Server kann sich auch selbst pingen. Sonst geht gar keiner (also Client zu Client oder Server zu Client). sg brigh |
Ich hab einen Fehler gefunden, aber er versteckt sich noch vor mir. Ich brauch doch nochmal eure Hilfe.
Beim starten des named bekomme ich folgene Fehlermeldung: dns_rdata_fromtext: /etc/bind/db.192.168.123:4: near eol: unexpected end of input. Ich habe meine db.192.168.123 jetzt Buchstabe für Buchstabe durchforstet und sehe den Fehler nicht, sieht ihn von euch jemand? ; $TTL 3h 123.168.192.in-addr.arpa. IN SOA prometheus.double-action. root.localhost. ( 2003031301 ; Serial 3h ; Refresh 1h ; Retry 1w ; Expire 1h ; minimum ) ; Nameserver: 123.168.192.in-addr.arpa. IN NS prometheus.double-action. ; ;Normale Adressen: 1.123.168.192.in-addr.arpa. IN PTR prometheus.double-action. Danke schonmal brigh |
du brauchst bei den normalen adressen eigentlich nur
1 IN PTR ...... schreiben, der rest wird eh erweitert... das is aber nicht der fehler... Code:
$TTL 3h |
Danke valo, ich hab das ausgebessert.
Nach dem Fehler fahnde ich noch immer... Da gibt es noch was komisches: Ich bekomme keine logs wenn ich dhcp oder named neu starte - nur bei einem reboot schreibt er was raus. Heißt das das er den Neustart gar nicht gemacht hat? Stopping DHCP Server: usw. schreibt er allerdings schon. Ich habe aber dann nur überall die Meldungen von der Firewall und das obwohl ich in /etc/init.d/klogd KLOGD="-c 1" eingetragen habe (wie hier in einem anderen Beitrag erklärt). Wirklich mysteriös das Ganze.... |
Ich geb' nicht auf - und hab schon wieder eine Frage:
mein db192.168.123 sieht jetzt so aus wie von valo vorgeschlagen Der Fehler von vorhin ist beseitigt, es hatte irgendwas komisches, in hex sah es merkwürdig aus, Punkt nicht gleich Punkt und so. Drum hab ich es neu getippt und somit eine neue Fehlermeldung wenn ich named starte..... dns_master_load: /etc/bind/db.192.168.123:13: 123.168.192.in-addr.arpa.12.168.192.in-addr.arpa: not at top of zone Aber 192.168.123.1 ist doch top of zone - oder ist da ganz was anderees gemeint? Hilfe :heul: |
Zitat:
steht in /var/log/syslog und /var/log/daemon.log nichts drin?!? |
Zitat:
lg, paul. |
Zitat:
ja genauso ist es leider! Wenn ich /etc/init.d/bind9 restart eingebe dann schreibt er in der Konsole zwar raus Stopping domain name service: named. Starting domain name service: named. Stopping DHCP server usw. schreibt er auch, in beiden Fällen ist aber in daemon.log oder syslog nichts zu finden. Dort sehe ich nur bei einem Neustart was (das ist lästig bei der Fehlersuche....). Zu sehen bei Neustart ist folgendes zu sehen: Mar 14 16:33:04 prometheus named[206]: couldn't add command channel 127.0.0.1#953: address in use Mar 14 16:33:04 prometheus named[206]: zone 0.in-addr.arpa/IN: loaded serial 1 Mar 14 16:33:04 prometheus named[206]: zone 127.in-addr.arpa/IN: loaded serial 1 Mar 14 16:33:04 prometheus named[206]: dns_master_load: /etc/bind/db.192.168.123:4: 123.168.192.in-addr.arpa.123.168.192.in-addr.arpa: not at top of zone Mar 14 16:33:04 prometheus named[206]: zone 123.168.192.in-addr.arpa/IN: loading master file /etc/bind/db.192.168.123: not at top of zone Mar 14 16:33:04 prometheus named[206]: zone 255.in-addr.arpa/IN: loaded serial 1 Mar 14 16:33:04 prometheus named[206]: zone double-action/IN: loaded serial 2003031301 Mar 14 16:33:04 prometheus named[206]: zone localhost/IN: loaded serial 1 Mar 14 16:33:04 prometheus named[206]: running Mar 14 16:33:04 prometheus argus[221]: started Wenn ich nur named neu starte schaut es so aus: daemon.log: Mar 14 16:43:37 prometheus lwresd[212]: shutting down: flushing changes Mar 14 16:43:37 prometheus lwresd[212]: stopping command channel on 127.0.0.1#953 Mar 14 16:43:37 prometheus lwresd[210]: exiting syslog: Mar 14 16:43:37 prometheus lwresd[212]: shutting down: flushing changes Mar 14 16:43:37 prometheus lwresd[212]: stopping command channel on 127.0.0.1#953 Mar 14 16:43:37 prometheus lwresd[210]: exiting Mar 14 16:43:40 prometheus kernel: fp=UDP:2 a=DROP IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:05:9b:c5:af:38:08:00 SRC=213.33.117.33 DST=255.255.255.255 LEN=338 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP SPT=67 DPT=68 LEN=318 lwresd meldet sich vor den Start von named auch schon mal mit loading configuration from /etc/bind/lwresd.conf dieses File gibt es aber bei mir nicht.... Das ist alles was ich im Moment so an Informationen zusammenkratzen kann. db.192.168.123 hab ich mir mit vi auch nochmal genau angeschaut - ich finde kein verstecktes Zeichen mehr, irgendeinen Grund muß es aber doch geben. Freue mich über jeden Tip!! Gruß brigh |
Zitat:
|
Hier ist es - einzige Veränderung ist, dass ich txt drangehängt habe zum hochladen.
Vielen Dank! |
Zitat:
ausserdem muss es nur "PTR", nicht "IN PTR" heissen soweit ich weiss... auch nicht IN NS, sondern "@ IN NS ...." bitte versuch die beiden changes mal... lg, paul |
:) bin einen großen Schritt weiter, Danke für deine Hilfe!
Ich hab die Änderungen gemacht und (auch die Serial, klar - wobei schon sein kann, dass ich die zwischendurch auch schon mal vergessen hab...) schon war die Fehlermeldung ein bisschen anders: dns_master_load: /etc/bind/db.192.168.123:4: 123.168.192.in-addr.arpa.123.168.192.in-addr.arpa: not at top of zone Die 4 hab ich als Zeile 4 interpretiert, weiß nicht ob das so ist oder mir der Zufall geholfen hat, in Zeile 4 hat der Punkt nach in-addr.arpa. gefehlt... Jetzt lädt er die Zone!! Es sieht also jetzt so aus als ob er einwandfrei laufen würde. Irgendwas passt ihm aber leider immer noch nicht, es gibt nämlich gar keine leases in /var/lib/dhcp-dns obwohl in /var/lib/dhcp alles da ist. Das muß aber auch noch zu finden sein - ich werde mir jetzt der Reihe nach die config Datein nochmal anschauen.... Schönen Gruss brigh |
Ich hab doch noch was gefunden:
named-checkzone double-action /etc/bind/db.192.168.123 bringt folgendes Ergebnis: dns_master_load: /etc/bind/db.192.168.123:4: ignoring out-of-zone data (123.168.192.in-addr.arpa) zone double-action/IN: could not find NS and/or SOA records zone double-action/IN: has 0 SOA records obwohl er sie laut log geladen hat. |
schreib vor dem "IN SOA" ein "@" hin, das steht für den namen der zone
also es sollte so ausschaun @ IN SOA ...... "IN PTR" stimmt ich weiss nicht obs mit nur "PTR" auch funktioniert... ich hab in meinen zonen für den "NS" eintrag aber nicht "IN NS" sondern nur "NS" und das funzt einwandfrei... |
Dankeschön valo!
Mit dem @ klappt es jetzt, ich bekomme ein OK mit named checkzone. Den Rest hab ich erstmal so gelassen wie es war, also nur PTR und IN NS und das hat funktioniert. Ein bisschen kramen muß ich noch, er löst jetzt nur auf wenn ich den Domainnamen auch mitgebe. Das ist noch nicht perfekt, aber es heißt wenigstens dass er läuft! Die Einstellungen auf den Clients muß ich mir auch noch anschauen... Aber das soll jetzt hoffentlich kein Problem mehr sein. Danke euch nochmal! Gruss brigh |
Zitat:
lg, paul. |
Das IN vor PTR hab ich weggetan, das Ding schaut jetzt so aus:
$TTL 3h @ IN SOA prometheus.double-action. root.localhost. ( 2003031504 ; Serial 3h ; Refresh 1h ; Retry 1w ; Expire 1h ; minimum ) ; Nameserver @ IN NS prometheus.double-action. ; ; normale Adressen 1 PTR prometheus.double-action. und ich krieg jetzt keine Fehlermeldungen mehr. Das IN vor dem NS hab ich gelassen, weil der Fehler schon weg war nachdem ich @ vor IN SOA geschrieben habe. Aber nachdem er's immer noch nicht so ganz tut, werde ich das jetzt auch noch entfernen! Gruss brigh |
Jetzt steht noch ein IN weniger drin, ich hab das vor NS auch gelöscht.
Nach wie vor keine Fehlermeldungen, aber nach wie vor funktioniert er nicht ganz normal. dig prometheus.double-action liefert auf dem Client und auf dem Server das richtige Ergebnis. Ohne domain-namen geht es nicht. Naja, morgen mit neuem Mut weitersuchen, immerhin müßte die Zone jetzt wirklich richtig angelegt sein! Schönen Abend brigh |
Zitat:
|
Ja, das mach ich, aber nur beim Client.
Ich habe am Server auch schon die resolv.config verändert --> 127.0.0.1 als Nameserver eingetragen. Das ist aber nach einem Neustart dann wieder weg - muß das in die named.config rein, oder weiß er dass er Nameserver ist? (Meiner weiß es nicht....) Wenn ich das richtig verstanden habe, dann sollte /var/lib/dhcp/dhcpd.leases nach vergeben IPs durchsucht werden. Die ist bei mir immer aktuell - nur die Namen werden scheinbar nirgens eingetragen... Das einzige was ich dazu finde sind diese Zeilen im log Mar 16 02:50:01 prometheus /USR/SBIN/CRON[486]: (root) CMD (/usr/sbin/ddns.cron.pl) Mar 16 02:50:54 prometheus lwresd[216]: shutting down: flushing changes Mar 16 02:50:54 prometheus lwresd[216]: stopping command channel on 127.0.0.1#953 Mar 16 02:50:54 prometheus lwresd[214]: exiting ..ich fürchte heute komm ich nicht mehr drauf! Gruss brigh |
Zitat:
search domain1 domain1 wenn du automatisch rechnernamen ohne domain in domain1 oder domain2 suchen moechtest. abhaengig von deiner distri kann es sein, dass einstellungen verloren gehen (suse). dann musst du diese settings in der rc.config vornehmen... oder eine sinnvolle distri nehmen! lg, paul. |
search meinedomain
hab ich eingetragen - am Client. nslookup geht auch ohne dass ich den domainnamen mitgebe, dig braucht ihn: liefert aber mt dig @IPvomNS namevomNS.meinedomain eine richtige Antwort. Das heißt doch dass er läuft, oder? In der resolv.config vom Server stehen die Nameserver von meinem Provider drin, die in der named.conf eingetragen sind. Bei search steht nichts. Wenn ich da meinedomain eintrage und auch nameserver 127.0.0.1 dazuschreibe, dann sind diese Änderungen nach einem Neustart wieder weg. (Ist aber kein Suse, ist Debian.) Ich hab jetzt auch wieder einen Fehler gefunden: named-checkconf -t /etc/bind/ named.conf named.conf:9: change directory to '/var/cache/bind' failed: file not found named.conf:9: parsing failed /var/cache/bind gibt es schon, aber es ist leer sg brigh |
Zitat:
und: in der resolv.conf den eigenen nameserver eintragen! |
Zitat:
Ich glaube schon dass er da hin darf /var/cache/bind gehört root hatte 755 als Berechhtigungen. Die hab ich jetzt auf 777 geändert, das hat aber auch nicht geholfen. Kann es noch andere Gründe geben, dass er nicht in das Verzeichnis darf? Langsam macht sich Verzweiflung breit.... Aber ohne euch hätte ich schon längst aufgegeben, vielen Dank für eure Geduld! Schönen Gruss brigh |
in die /etc/resolv.conf sollte folgendes drinstehn
search double-action nameserver $DIE_IP_DES_SERVERS aber nicht 127.0.0.1 verwenden, sondern die die du im lan vergibst... in der named.conf sollte unter den general options eingetragen sein: forwarders { $providerdns1; $providerdns2; }; dann tragst du auf allen clients den internen dns server als zu verwendenden dns server ein... wieso er in das verzeichnis nicht darf, hm, muss mal schaun welche berechtigungen bei auf meinem server vergeben sind.... bin halt grad ned zaus, werd noch berichten dein problem werden wir schon noch lösen, dauert halt vielleicht ein bissl... ;) |
Die /etc/resolv.config auf denClients schaut genauso aus.
Am Server kann ich ändern was ich will, nach einem Neustart steht da wieder search nameserver ip_vom_provider1 nameserver ip_vom_provider2 Eben genau die IP's die in der /etc/named.config bei forwarders eingetragen sind. Ich hab die probeweise aus der resolv.config gelöscht und nur meine eigene reingeschrieben. Nach einem Neustart ist die wieder weg, dafür stehen die vom Provider drin. Die muß er dann ja aus der /etc/named.config haben... Ich nehme jetzt einfach mal an das ist richtig so und war sowieso so gemeint. Sonst muß ich mir einfach abgewöhnen den Server auszuschalten - wem fällt auch sowas dummes ein wie einen Server auszuschalten! Bei den ganzen Versuchen hab ich aber vorher mal einen Strichpunkt in der named.config vergessen - daraufhin ging gar nichts mehr. Sprich kein ping www.wcm.at vom Client - und ich dachte schon der Nameserver tut gar nichts. Offensichtlich interessien ihn nur die lokalen Adressen überhaupt nicht! Sich selbst löst er auch auf, die Clients kennen ihn. Sie hatten ihn bis heute in der /etc/hosts eingetragen, das hab ich probeweise gelöscht und siehe da: er wird aufgelöst. Mit eurer Hilfe werde ich wohl dieses komische Berechtigungsproblem auch noch hinkriegen. (Bin neugierig was dann auftaucht... :eek: ) Immerhin hab ich mch jetzt schon viel mehr mit dem Zeug beschäftigt als ich eigentlich vorhatte und es ist ja doch interessant. Gruss brigh |
Zitat:
lg, paul. |
Hi,
das mit den Zonen klappt schon, named-checkzone liefert mir nur mehr OK (da hat ein @ vor IN SOA geholfen....). Du meinst wahrscheinlich die Fehlermeldung: named-checkconf -t /etc/bind/ named.conf named.conf:9: change directory to '/var/cache/bind' failed: file not found named.conf:9: parsing failed ...und ich komme nicht drauf was ihn an dem Verzeichnis stört. Seit gestern steht in /var/chache/bind sogar was drin: ich habe mit verschiedenen rndc Kommandos herumprobiert und jetzt ist ein named_dump.db da, ich glaube rndc dumpdb ist dafür verantwortlich. Die Berechtigungen für /var/cache/bind habe ich auf 777 gesetzt, das hilft aber leider gar nichts. Aber noch geb ich nicht auf... Gruss brigh |
hi!
ich habe ziemlich ähnliche probleme, allerdings mit suse 7.3 interessant ist, das einige lösungsvorschläge im widerspruch zu diversen artikeln und auch zu meinem buch von m. kofler stehen, aber eine verbesserung bringen. ich werde halt auch versuchen, mit eueren tips weiter zu kommen. in suse gibt es eine option, um das überschreiben der resolv.config zu verhindern. ich habs jetzt nicht parat, aber ich kann's ja später posten. vielleicht gibt's das ja auch bei debian. WB |
also bei mir scheint jetzt alles zu funktionieren.
anscheinend darf man den verschiedenen veröffentlichungen nicht blind vertrauen. praktische erfahrung ist wohl besser. meinen dank an alle, die hier mitgearbeitet haben. nachtrag zur resolv.conf: bei internet via ppp muß die option usepeerdns aus der ppp-optionen-datei entfernt werden, sonst wird die resolv.conf beim verbindungsaufbau durch provider-spezifische daten überschrieben. bei suse gibt es in der rc.config die variable MODIFY_RESOLV_CONF_DYNAMICALLY wenn hier no eingetragen ist, wird eine veränderung der datei durch suse-scripts verhindert. quelle: linux, 6. auflage von michael kofler. vielleicht hilft das auch anwendern von anderen distributionen. mfg WB |
Hi,
das macht mir Mut - dann muß es ja hinzukriegen sein. Ich werde das schon Schritt für Schritt schaffen! Ob ich irgendwo eintragen kann, dass meine resolv.config in Ruhe gelassen wird, das muß ich mir anschauen. Vielleicht gibt es ja sowas ähnliches wie unter Suse. Sonst ist er jetzt etwas lebendiger, das Ergebnis davon sind Einträge, die er mittlerweile macht in /var/lib/dhcp-dns/nsupdate.data Was er genau tut und nicht tut muß ich mir aber erst näher anschaun! Gruss brigh |
DNS funktioniert!
Der widerspenstige DNS ist zum leben erwacht, was der Fehler war weiß ich leider trotzdem nicht...
Aber was ich gemacht habe kann ich euch erzählen! In meiner Verzweiflung hab' ich einfach neu aufgesetzt. Dann hab ich die Zonendateien, named.conf usw. wieder genau nach den Famielienserver - Anweisungen erstellt. Nur die db.192.168.123 die sieht so aus wie hier von paul und valo vorgeschlagen - das ist auch die einzige Version die bei mir funktioniert! Falls jemand ähnliche Probleme hat, so sieht sie aus: ; $TTL 3h @ IN SOA debian.private-net. root.localhost. ( 2003031909; Serial 3h ; Refresh 1h ; Retry 1w ; Expire 1h ; minimum ) ;Nameserver: @ NS debian.private-net. ;normale Adressen: 1 IN PTR debian.private-net. Geprüft habe ich meine Zonenfiles so: named-checkzone private-net /etc/bind/db.192.168.123 --> da sollte man dann ein OK kriegen.... named-checkconf /etc/bind/ named.conf wäre dazu da die named.conf zu prüfen. Das haut bei mir allerdings nicht hin. da bekomme ich immer noch den Fehler, den ich weiter oben beschrieben habe (file not found bei /var/cache/bind), der NS läuft aber. Ich habe also beschlossen, dass mir das jetzt egal ist. Ich hab dann zuerst mit Win-Clients probiert und das hat anstandslos funktioniert. Mit Linux Clients hatte ich aber nach wie vor Schwierigkeiten - drum hab ich mir die Clienteinstellungen gründlich angeschaut: Ich hatte in der /etc/dhclient.conf immer nur die Zeile send host-name .... für den DHCP-Server mitgegeben. Von den Win-Clients kriegt er aber meht Informationen, nämlich eine UID - die hat er von meinen Debian-Clients nicht bekommen. Also in /etc/dhclient.conf die Zeile send dhcp-client-identifier [Mac-Adresse mit 00 davor] eingetragen das war's - dann ging alles!! Drum hab ich jetzt auch die leise Vermutung, dass er vorher auch schon funktioniert hat und dass es nur die Einstellungen am Client waren. Am Server selbst dürfte das einzige Problem die Zonendatei gewesen sein. Das einzige was mir noch nicht so ganz gefällt, ist dass der Server selbst die internen Adressen nicht auflösen kann. Nur wenn ich seine resolv.conf bearbeite - und diese Änderung behält er nicht. Er bezieht selbst seine IP vom DHCP meines Providers und ich vermute dass der dafür verantwortlich ist, dass meine Änderungen nicht drin bleiben in der resolv.conf Wenn ich noch draufkomme wie ich das in den Griff kriege, dann bin ich restlos glücklich. Vielen, vielen Dank paul und valo, dass ihr mir hier so geduldig geholfen habt!! Schönen Gruss, brigh |
das er deine resolv.conf änderungen jedesmal "vergisst" hängt mit ziemlicher sicherheit damit zusammen, dass du die einstellungen von deinem provider per dhcp bekommst...
ich hab leider nicht wirklich eine ahnung mit dhcp unter linux, aber ich nehme mal an, dass das einrichten der ip/usw beim verbinden mit dem provider als root abläuft, also ein schreibgeschuetz fuer die resolv.conf nichts bringt.... gibts vielleicht die moeglichkeit zu konfigurieren, dass die dns server und die default domain nicht vom dhcp client eingetragen werden? das wuerde dir imho helfen.... |
geschafft - alle Probleme gelöst!
...du hast recht, es war (oder ist eigentlich immer noch) so, dass mir
mein Provider die resolv.conf überschreibt. Die Möglichkeit nicht blind alles zu übernehmen gibt's - wie nicht anders zu erwarten war.... in der /etc/dhclient.conf hab ich supersede domain-name "meinedomain"; prepend domain-name-servers 192.168.123.1; eingetragen. supersede heißt 'ignoriere das was du geliefert bekommst, nimm dafür das was da steht' und prepend heißt ' du darfst die Information akzeptieren die du bekommst, mußt aber das voranstellen was da steht' - oder so ähnlich. Funktionieren tut es auf alle Fälle! Ich stelle mir das so vor, dass meine resolv.conf nach wie vor immer wieder überschrieben wird, nur kennt der DHCP-Client jetzt ein paar private Einstellungen die er mit einträgt. :bier: Danke euch nochmal allen - ich geb' euch eine Runde aus!!! :bier: Schönen Gruß brigh |
du kannst auch die datei /etc/dhclient-script bearbeiten und einfach die einträge für dns mit "#" ausklammern.
|
| Alle Zeitangaben in WEZ +2. Es ist jetzt 11:04 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag