Adlerauge für Zonendatei gesucht
Tach Leute. Habe hier immer noch ein Problem mit der Namensauflösung, und vom Raufen meiner Haare sehe ich nur deswegen ab, weil ich vermute, daß das auch nichts bringt. Also: Ich hab nen named am Laufen, den ich via dhcp bekannt mache. Windows-Clients können nun die Adressen der Domäne schaible.local. problemlos auflösen, und auch ein reverse lookup geht problemlos. Ebenso ist es mit Linux-Kisten: dig bringt für beide Richtungen einwandfreie Ergebnisse. Nur die Mac-9.2-Clients kriegen die Auflösung nicht hin. Sie können zB mailsrv.schaible.local. nicht in 192.168.0.201 verwandeln. Gebe ich etwa im Mailprogramm als smtp-Server mailsrv.schaible.local an, dann kommt die Meldung: "Error involving domain name system". Die Macs können aber ein reverse lookup auf 192.168.0.201 machen (auch auf alle anderen 192.168.0.x-Adressen), und kriegen sofort den zugehörigen Namen raus. Woran könnte das nur liegen? Ich hatte schon die Vermutung, daß ein falscher Nameserver befragt wird. Aber das ist nicht der Fall. Erstens zeigen das TCP-IP-Kontrollfeld und mein Ping-Tool den richtigen NS an, und zweitens würde ja ein reverse lookup scheitern, wenn der falsche NS befragt würde. Hier meine Zonen-Dateien: Forward: $TTL 2D @ IN SOA mailsrv.schaible.local. af.schaible.net. ( 2003092304 ; serial 1D ; refresh 2H ; retry 1W ; expiry 2D ) ; minimum NS mailsrv.schaible.local. mailsrv A 192.168.0.201 teamsrv A 192.168.0.202 [...] Reverse: $TTL 2D @ IN SOA mailsrv.schaible.local. af.schaible.net. ( 2003092304 ; serial 1D ; refresh 2H ; retry 1W ; expiry 2D ) ; minimum NS mailsrv.schaible.local. 201 PTR mailsrv.schaible.local. 202 PTR teamsrv.schaible.local. [...] Weiß jemand Rat? -- Andreas Feile www.feile.net
Andreas Feile schrieb:
Tach Leute.
Habe hier immer noch ein Problem mit der Namensauflösung, und vom Raufen meiner Haare sehe ich nur deswegen ab, weil ich vermute, daß das auch nichts bringt.
Also: Ich hab nen named am Laufen, den ich via dhcp bekannt mache. Windows-Clients können nun die Adressen der Domäne schaible.local. problemlos auflösen, und auch ein reverse lookup geht problemlos. Ebenso ist es mit Linux-Kisten: dig bringt für beide Richtungen einwandfreie Ergebnisse.
Nur die Mac-9.2-Clients kriegen die Auflösung nicht hin. Sie können zB mailsrv.schaible.local. nicht in 192.168.0.201 verwandeln. Gebe ich etwa im Mailprogramm als smtp-Server mailsrv.schaible.local an, dann kommt die Meldung: "Error involving domain name system". Die Macs können aber ein reverse lookup auf 192.168.0.201 machen (auch auf alle anderen 192.168.0.x-Adressen), und kriegen sofort den zugehörigen Namen raus. Woran könnte das nur liegen? Ich hatte schon die Vermutung, daß ein falscher Nameserver befragt wird. Aber das ist nicht der Fall. Erstens zeigen das TCP-IP-Kontrollfeld und mein Ping-Tool den richtigen NS an, und zweitens würde ja ein reverse lookup scheitern, wenn der falsche NS befragt würde.
Hier meine Zonen-Dateien:
Forward: $TTL 2D @ IN SOA mailsrv.schaible.local. af.schaible.net. ( 2003092304 ; serial 1D ; refresh 2H ; retry 1W ; expiry 2D ) ; minimum
NS mailsrv.schaible.local.
mailsrv A 192.168.0.201 teamsrv A 192.168.0.202 [...]
Das muss so heissen mailsrv IN A 192.168.0.201
Reverse: $TTL 2D @ IN SOA mailsrv.schaible.local. af.schaible.net. ( 2003092304 ; serial 1D ; refresh 2H ; retry 1W ; expiry 2D ) ; minimum
NS mailsrv.schaible.local.
201 PTR mailsrv.schaible.local. 202 PTR teamsrv.schaible.local.
..und hier: 201 IN PTR mailsrv.schaible.local.
[...]
Weiß jemand Rat?
-- Andreas Feile www.feile.net
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
Sven Geier, Dienstag, 23. September 2003 20:54:
Das muss so heissen mailsrv IN A 192.168.0.201
Muß? Ich habe hier [1] abgeschrieben, und da stehts anders. Ich meine, Deine Schreibweise schadet nicht. Aber sie hilft auch nicht.
..und hier: 201 IN PTR mailsrv.schaible.local.
Dito. Hilft nix, schadet auch nicht. BTW: wofür steht eigentlich IN und A? Gruß. Andy [1] http://www.tldp.org/HOWTO/DNS-HOWTO-5.html#ss5.2 -- Andreas Feile www.feile.net
Andreas Feile am Dienstag, 23. September 2003 21:32:
Sven Geier, Dienstag, 23. September 2003 20:54:
Das muss so heissen mailsrv IN A 192.168.0.201
Muß? Ich habe hier [1] abgeschrieben, und da stehts anders. Ich meine, Deine Schreibweise schadet nicht. Aber sie hilft auch nicht.
..und hier: 201 IN PTR mailsrv.schaible.local.
Dito. Hilft nix, schadet auch nicht.
Hm, ich kenne es auch nur mit. Hab es noch nie ohne probiert. Aber vielleicht ist es wirklich nur ein Füllwort, ähnlich wie in der .fetchmailrc
BTW: wofür steht eigentlich IN und A?
In address (bzw. IN PTR: in pointer) - AFAIK -- Gruß MaxX 8-)
Matthias Houdek, Dienstag, 23. September 2003 22:04:
Hm, ich kenne es auch nur mit. Hab es noch nie ohne probiert. Aber vielleicht ist es wirklich nur ein Füllwort, ähnlich wie in der .fetchmailrc
Nein, ist kein Füllwort. Sehen wir uns zB den Auswurf von dig an: ;; QUERY SECTION: ;; feile.net, type = A, class = IN Es ist eine Klasse. Wenn sie angegeben wird, ists recht. Wenn nicht, dann wird sie von oben übernommen, von dort, wo IN SOA steht. -- Andreas Feile www.feile.net
Andreas Feile wrote:
Matthias Houdek, Dienstag, 23. September 2003 22:04:
Hm, ich kenne es auch nur mit. Hab es noch nie ohne probiert. Aber vielleicht ist es wirklich nur ein Füllwort, ähnlich wie in der .fetchmailrc
Nein, ist kein Füllwort. Sehen wir uns zB den Auswurf von dig an:
;; QUERY SECTION: ;; feile.net, type = A, class = IN
Es ist eine Klasse. Wenn sie angegeben wird, ists recht. Wenn nicht, dann wird sie von oben übernommen, von dort, wo IN SOA steht.
Weisst Du, ob die MACs ausser der Fehlermeldung die Du gepostet hast, noch einen 2ten Teil dazu lieferen, der eine genauere Beschreibung des Fehlers beinhaltet? Gruss Werner
Werner Merz, Mittwoch, 24. September 2003 09:36:
Weisst Du, ob die MACs ausser der Fehlermeldung die Du gepostet hast, noch einen 2ten Teil dazu lieferen, der eine genauere Beschreibung des Fehlers beinhaltet?
Naja, wenn ich eine genauere Beschreibung hätte, hätte ich sie nicht verheimlicht. Hast Du eine Ahnung, wo ich suchen könnte? Ich meine, sowas wie log-Dateien gibts ja auf dem Mac so gut wie nicht. Aber vielleicht gibts was, das ich nicht kenne? Gruß. Andy -- Andreas Feile www.feile.net
Andreas Feile wrote:
Werner Merz, Mittwoch, 24. September 2003 09:36:
Weisst Du, ob die MACs ausser der Fehlermeldung die Du gepostet hast, noch einen 2ten Teil dazu lieferen, der eine genauere Beschreibung des Fehlers beinhaltet?
Naja, wenn ich eine genauere Beschreibung hätte, hätte ich sie nicht verheimlicht. Hast Du eine Ahnung, wo ich suchen könnte? Ich meine, sowas wie log-Dateien gibts ja auf dem Mac so gut wie nicht. Aber vielleicht gibts was, das ich nicht kenne?
Gruß. Andy
Nein leider weiss ich auch nicht wo Du noch suchen könntest. Das mit dem 2ten Teil der Fehlermeldung habe ich nur gefragt, weil ich beim Googeln viele Hits hatte, bei denen die User tolle 2te Teile der Fehlermeldung hatten, die den Fehler ziemlich genau einschrännkten. Ich dachte halt, dass Du die die Fehlermeldung von einem User mitgeteilt wurde und Du sie nicht selbst gesehen hast. Eigentlich habe ich schon gedacht, dass Du das schon gechecked hast. War halt ein Schuss ins Blaue. Habe noch eine zusätzliche Frage: Kann nur das Mailprogramm die Rechner-IPs nicht auflösen, oder auch Tools wie Ping (Wenns das auf dem MAC gibt) Gruss Werner
Werner Merz, Mittwoch, 24. September 2003 17:19:
Ich dachte halt, dass Du die die Fehlermeldung von einem User mitgeteilt wurde und Du sie nicht selbst gesehen hast.
Nee, ich saß selbst davor und habe rumprobiert. Leider gibts da nicht mehr zu sehen, und es ist mir noch nicht mal klar, ob es das OS war, das die Meldung ausgibt, oder ob das ein Fenster der Anwendung (in meinem Falle Eudora) ist.
Habe noch eine zusätzliche Frage: Kann nur das Mailprogramm die Rechner-IPs nicht auflösen, oder auch Tools wie Ping (Wenns das auf dem MAC gibt)
Ping gibts unter OS 9.2 nicht von Haus aus, aber es gibt Tools, die das können. So eines habe ich, aber damit gehts auch nicht, ich kann also nur IPs pingen, aber keinen Rechner innerhalb schaible.local. Ein Ping nach außerhalb zB auf www.suse.de geht. Dieses Tool kann auch gleich lookups machen. Und damit funktioniert wie gesagt ein reverse lookup, aber vorwärts gehts nicht. Gruß. Andy PS: bitte keine PM, ich lese hier mit. -- Andreas Feile www.feile.net
Moin, Am Mi, 2003-09-24 um 17.38 schrieb Andreas Feile:
Ping gibts unter OS 9.2 nicht von Haus aus, aber es gibt Tools, die das können. So eines habe ich, aber damit gehts auch nicht, ich kann also nur IPs pingen, aber keinen Rechner innerhalb schaible.local. Ein Ping nach außerhalb zB auf www.suse.de geht. Dieses Tool kann auch gleich lookups machen. Und damit funktioniert wie gesagt ein reverse lookup, aber vorwärts gehts nicht.
Kann es sein, daß die "anderen" IPv6 machen, derweil der Mac nur v4 kann und in der Firewall hängen bleibt? Hast du es schonmal ohne fw versucht? Gruß, Ratti -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Joerg Rossdeutscher, Mittwoch, 24. September 2003 19:49:
Kann es sein, daß die "anderen" IPv6 machen, derweil der Mac nur v4 kann und in der Firewall hängen bleibt? Hast du es schonmal ohne fw versucht?
Ich habe zwischen den Macs und dem DNS-Server keine Firewall hängen. Das ist alles innerhalb eines Netzwerksegmentes. Firewalls habe ich nur nach außen hängen, aber die dürften ja insoweit keine Rolle spielen. Heute werde ich ein wenig mit den Tips experimentieren, die ich in den letzten Tagen gekriegt habe. Vielleicht finde ich was raus. -- Andreas Feile www.feile.net
Andreas Feile wrote:
Dito. Hilft nix, schadet auch nicht.
Genau. Ebenso wie die erste Spalte kann man auch Spalte 2 und 3 auslassen, oder Spalte 3 halt mit der Klasse fuellen.
BTW: wofür steht eigentlich IN und A?
IN ist Class IN == Internet A ist Record Type A == adress Ausser IN gibt's eigentlich keine gebraeuchlichen Klassen mehr, Bind benutzt CHAOS um seine Versionsnummer in die Welt zu posaunen und sonst stolpert man im Manual eigentlich nur noch ueber HESOID. Als Resource-Records gibt's noch einige. Die gebraeuchlichsten duerften PTR, MX, CNAME, AAAA und NS sein. PTR == reverse Pointer CNAME == canonical Name AAAA == IPv6 Adresse NS == Nameserver -- Have fun, Peter
Sven Geier wrote:
Andreas Feile schrieb:
Tach Leute.
Habe hier immer noch ein Problem mit der Namensauflösung, und vom Raufen meiner Haare sehe ich nur deswegen ab, weil ich vermute, daß das auch nichts bringt.
Also: Ich hab nen named am Laufen, den ich via dhcp bekannt mache. Windows-Clients können nun die Adressen der Domäne schaible.local. problemlos auflösen, und auch ein reverse lookup geht problemlos. Ebenso ist es mit Linux-Kisten: dig bringt für beide Richtungen einwandfreie Ergebnisse.
Nur die Mac-9.2-Clients kriegen die Auflösung nicht hin. Sie können zB mailsrv.schaible.local. nicht in 192.168.0.201 verwandeln. Gebe ich etwa im Mailprogramm als smtp-Server mailsrv.schaible.local an, dann kommt die Meldung: "Error involving domain name system". Die Macs können aber ein reverse lookup auf 192.168.0.201 machen (auch auf alle anderen 192.168.0.x-Adressen), und kriegen sofort den zugehörigen Namen raus. Woran könnte das nur liegen? Ich hatte schon die Vermutung, daß ein falscher Nameserver befragt wird. Aber das ist nicht der Fall. Erstens zeigen das TCP-IP-Kontrollfeld und mein Ping-Tool den richtigen NS an, und zweitens würde ja ein reverse lookup scheitern, wenn der falsche NS befragt würde.
Hier meine Zonen-Dateien:
Forward: $TTL 2D @ IN SOA mailsrv.schaible.local. af.schaible.net. ( 2003092304 ; serial 1D ; refresh 2H ; retry 1W ; expiry 2D ) ; minimum
NS mailsrv.schaible.local.
mailsrv A 192.168.0.201 teamsrv A 192.168.0.202 [...]
Das muss so heissen mailsrv IN A 192.168.0.201
Reverse: $TTL 2D @ IN SOA mailsrv.schaible.local. af.schaible.net. ( 2003092304 ; serial 1D ; refresh 2H ; retry 1W ; expiry 2D ) ; minimum
NS mailsrv.schaible.local.
201 PTR mailsrv.schaible.local. 202 PTR teamsrv.schaible.local.
..und hier: 201 IN PTR mailsrv.schaible.local.
[...]
Weiß jemand Rat?
-- Andreas Feile www.feile.net
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
moin moin, vielleciht hab ich ja eine msg im thread ueberlesen, aber anscheinend hat keiner mitbekommen das er dem mac ein smtp konfigurieren will und dafuer muss in der zonen datei ein gueltiger mx record fuer diese domaine eingetragen sein, weil ihn eine schlichte auflösung des rechnernames gar nicht interessiert und deshalb auch nicht macht, vielmehr such er den mx eintrag fuer die domain *.schaible.local also schreib mal unter den NS eintrag folgende zeile IN MX 10 mailsrv.schaible.local. wenn der mac diesen eintrag findet, dann und erst dann macht er einen lookup auf mailsrv.schaible.local HTH mfg -- ---------------------------------------- Markus Heinze Internet: http://www.existand.de E-Mail : M.Heinze@existand.de Telephon: 03464/569787 Fax : 03464/569786 ----------------------------------------
Markus Heinze, Mittwoch, 24. September 2003 09:39:
vielleciht hab ich ja eine msg im thread ueberlesen, aber anscheinend hat keiner mitbekommen das er dem mac ein smtp konfigurieren will und dafuer muss in der zonen datei ein gueltiger mx record fuer diese domaine eingetragen sein, weil ihn eine schlichte auflösung des rechnernames gar nicht interessiert und deshalb auch nicht macht, vielmehr such er den mx eintrag fuer die domain *.schaible.local also schreib mal unter den NS eintrag folgende zeile
IN MX 10 mailsrv.schaible.local.
wenn der mac diesen eintrag findet, dann und erst dann macht er einen lookup auf mailsrv.schaible.local
Hmm, das ist schonmal eine gute Idee! Ich will zwar mehr als einen mx haben, aber den immerhin auch. Und wenn die Suchreihenfolge so ist, daß er erst nach einem mx sucht, bevor er den lookup auf mailsrv.schaible.local macht, dann wäre das vielleicht eine Erklärung. Aber: wieso kann ich mailsrv.schaible.local nicht pingen? Das braucht doch keinen mx. Und: teamsrv (also die 192.168.0.202) ist ein Teamserver für die TeamAgenda. Die Agenda-Clients weigern sich allerdings ebenso wie das Mailprogramm, teamsrv(.schaible.local[.]) aufzulösen, mit und ohne Punkt am Ende. Und hier wird mir der mx-Eintrag auch nix helfen, oder? Oder guckt der Mac am Ende immer nach mx-Einträgen, bevor er was anderes tut? Morgen komm ich wohl wieder ein wenig zum Testen, da probiere ich das alles mal aus. -- Andreas Feile www.feile.net
Moin, Am Mi, 2003-09-24 um 09.39 schrieb Markus Heinze:
vielleciht hab ich ja eine msg im thread ueberlesen, aber anscheinend hat keiner mitbekommen das er dem mac ein smtp konfigurieren will und dafuer muss in der zonen datei ein gueltiger mx record fuer diese domaine eingetragen sein, weil ihn eine schlichte auflösung des rechnernames gar nicht interessiert und deshalb auch nicht macht, vielmehr such er den mx eintrag fuer die domain *.schaible.local also schreib mal unter den NS eintrag folgende zeile
IN MX 10 mailsrv.schaible.local.
Meines Wissens ist ein MX Record vorrangig, aber optional. Wen kein MX vorhanden ist, wird die "normale" Auflösung genommen. Sicher bin ich mir nicht, ich glaub's aber. GRuß, Ratti -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
N'abend! Andreas Feile schrieb:
Hier meine Zonen-Dateien:
Forward: $TTL 2D @ IN SOA mailsrv.schaible.local. af.schaible.net. ( 2003092304 ; serial 1D ; refresh 2H ; retry 1W ; expiry 2D ) ; minimum
NS mailsrv.schaible.local.
mailsrv A 192.168.0.201 teamsrv A 192.168.0.202 [...]
Müsste heisen IN A... aber wichtiger: Der Server heist laut dieser Konfiguration: mailsrv.mailsrv.schaible.local , da mailsrv (ohne Punkt) durch die SOA ergänzt wird (mailsrv.schaible.local). Gruß, Uli
Reverse: $TTL 2D @ IN SOA mailsrv.schaible.local. af.schaible.net. ( 2003092304 ; serial 1D ; refresh 2H ; retry 1W ; expiry 2D ) ; minimum
NS mailsrv.schaible.local.
201 PTR mailsrv.schaible.local. 202 PTR teamsrv.schaible.local. [...]
Weiß jemand Rat?
Hallo Ulrich! Ulrich Klenk, Dienstag, 23. September 2003 21:49:
mailsrv A 192.168.0.201 teamsrv A 192.168.0.202 [...]
Müsste heisen IN A...
Kann, muß aber mE nicht, siehe mein voriges Posting.
aber wichtiger: Der Server heist laut dieser Konfiguration: mailsrv.mailsrv.schaible.local , da mailsrv (ohne Punkt) durch die SOA ergänzt wird (mailsrv.schaible.local).
Das verstehe ich nicht. Sehen wir uns nochmal die config an: $TTL 2D @ IN SOA mailsrv.schaible.local. af.schaible.net. ( [...] NS mailsrv.schaible.local. mailsrv A 192.168.0.201 [...] Das, was nach SOA kommt, ist doch der Name des zuständigen Nameservers. Der Name der Domäne, die verwaltet werden soll, wird durch das @ repräsentiert. Dieses wiederum ergibt sich aus der named.conf, in der u.a. steht: zone "schaible.local" in { type master; file "schaible.zone"; notify no; } Also wird mailsrv (da nicht abgeschlossen) zu mailsrv.schaible.local., und das ist doch korrekt so. -- Andreas Feile www.feile.net
HI! Andreas Feile schrieb:
aber wichtiger: Der Server heisst laut dieser Konfiguration: mailsrv.mailsrv.schaible.local , da mailsrv (ohne Punkt) durch die SOA ergänzt wird (mailsrv.schaible.local).
Das verstehe ich nicht. Sehen wir uns nochmal die config an:
$TTL 2D @ IN SOA mailsrv.schaible.local. af.schaible.net. ( [...] NS mailsrv.schaible.local. mailsrv A 192.168.0.201 [...]
Das, was nach SOA kommt, ist doch der Name des zuständigen Nameservers. Der Name der Domäne, die verwaltet werden soll, wird durch das @ repräsentiert. Dieses wiederum ergibt sich aus der named.conf, in der u.a. steht:
zone "schaible.local" in { type master; file "schaible.zone"; notify no; }
Also wird mailsrv (da nicht abgeschlossen) zu mailsrv.schaible.local., und das ist doch korrekt so.
Fast, denn wenn Du es so machst, muss noch ein zweites @ nach SOA kommen so läuft das bei mir: @ 1D IN SOA @ root (..... oder klassisch (Dein Ansatz): @ IN SOA dachwg.lo. root.dachwg.lo. Gruß, Uli
Andreas Feile wrote:
Nur die Mac-9.2-Clients kriegen die Auflösung nicht hin. Sie können zB mailsrv.schaible.local. nicht in 192.168.0.201 verwandeln. Gebe ich etwa im Mailprogramm als smtp-Server mailsrv.schaible.local an, dann kommt die Meldung: "Error involving domain name system".
Deine Macs fuegen immer die default-Domain an. Probier mal "mailsrv" zu verwenden. (Oder mailsrv.schaible.local. verwenden)
Hier meine Zonen-Dateien:
Forward:
Zonefiles sehen beide sauber aus. Noch die Config-Ausschnitte und syslog-Meldungen von 'rcbind restart'. -- Have fun, Peter
Peter Wiersig, Dienstag, 23. September 2003 22:12:
Deine Macs fuegen immer die default-Domain an. Probier mal "mailsrv" zu verwenden. (Oder mailsrv.schaible.local. verwenden)
Alles schon probiert, hilft nix. Kurioserweise dauert es mindestens fünf Sekunden, bis mir der Mac sagt, er könne den Namen nicht auflösen. Hingegen funktioniert das reverse lookup sofort.
Zonefiles sehen beide sauber aus. Noch die Config-Ausschnitte und syslog-Meldungen von 'rcbind restart'.
Config: [...] # Name => Adresse fuer Zone schaible.local zone "schaible.local" in { type master; file "schaible.zone"; notify no; }; # Adresse => Name fuer Zone schaible.local zone "0.168.192.in-addr.arpa" in { type master; file "schaible.enoz"; notify no; }; Und: mailsrv:~ # rcnamed restart Sep 23 22:25:20 mailsrv named[479]: named shutting down Sep 23 22:25:20 mailsrv named[479]: USAGE 1064348720 1064295445\ CPU=0.42u/0.52s CHILDCPU=0u/0s Sep 23 22:25:20 mailsrv named[479]: NSTATS 1064348720 1064295445 A=347\ CNAME=1 PTR=82 AAAA=688 Sep 23 22:25:20 mailsrv named[479]: XSTATS 1064348720 1064295445 RR=5\ RNXD=4 RFwdR=4 RDupR=0 RFail=0 RFErr=0 RErr=0 RAXFR=0 RLame=0 ROpts=0\ SSysQ=1 SAns=1118 SFwdQ=4 SDupQ=45 SErr=1 RQ=1118 RIQ=0 RFwdQ=4\ RDupQ=0 RTCP=0 SFwdR=4 SFail=0 SFErr=0 SNaAns=67 SNXD=346 RUQ=0\ RURQ=0 RUXFR=0 RUUpd=0 Sep 23 22:25:21 mailsrv named[4456]: starting (/etc/named.conf). named\ 8.2.4-REL Thu Sep 20 04:20:40 GMT 2001\ root@knox:/usr/src/packages/BUILD/bind8-8.2.4/bin/named Sep 23 22:25:22 mailsrv named[4456]: master zone "localhost" (IN)\ loaded (serial 42) Sep 23 22:25:22 mailsrv named[4456]: master zone "0.0.127.in-addr.arpa"\ (IN) loaded (serial 42) Sep 23 22:25:22 mailsrv named[4456]: hint zone "" (IN) loaded (serial 0) Sep 23 22:25:22 mailsrv named[4456]: master zone "schaible.local" (IN)\ loaded (serial 2003092304) Sep 23 22:25:22 mailsrv named[4456]: master zone\ "0.168.192.in-addr.arpa" (IN) loaded (serial 2003092304) Sep 23 22:25:22 mailsrv named[4456]: listening on [127.0.0.1].53 (lo) Sep 23 22:25:22 mailsrv named[4456]: listening on [192.168.0.201].53\ (eth0) Sep 23 22:25:22 mailsrv named[4456]: Forwarding source address is\ [0.0.0.0].1066 Sep 23 22:25:22 mailsrv named[4457]: group = named Sep 23 22:25:22 mailsrv named[4457]: user = named Sep 23 22:25:22 mailsrv named[4457]: Ready to answer queries. Sep 23 22:25:22 mailsrv named[4457]: check_hints: A records for J.ROOT-SERVERS.NET class 1 do not match hint records Hoffe, daß meine "Glättung" den Syslog lesbar macht... -- Andreas Feile www.feile.net
Andreas Feile wrote:
Kurioserweise dauert es mindestens fünf Sekunden, bis mir der Mac sagt, er könne den Namen nicht auflösen. Hingegen funktioniert das reverse lookup sofort.
Auf den Macs hast du leider kein dig, oder? Alternativ waere der Output von tcpdump hilfreich, wenn ein Mac ne Aufloesung macht. Die dekodierten NS-Queries sollten dann etwas Licht ins Dunkel bringen.
Config:
[...] # Name => Adresse fuer Zone schaible.local zone "schaible.local" in {
Vielleicht "IN {" noetig, vermute aberm das es keinen Unterschied macht.
Und: mailsrv:~ # rcnamed restart (...)
Alles fein.
Sep 23 22:25:22 mailsrv named[4457]: check_hints: A records for J.ROOT-SERVERS.NET class 1 do not match hint records
Ist nur ein Schoenheitsfehler. Dem Marcel hab ich vor nem paar Tagen gemailt, wie man die root-Zone holt, damit wuerde diese Meldung rausfliegen.
Hoffe, daß meine "Glättung" den Syslog lesbar macht...
Ja, fand ich gut. -- Have fun, Peter
Peter Wiersig, Dienstag, 23. September 2003 22:56:
Auf den Macs hast du leider kein dig, oder?
Nee, gibts sowas überhaupt? Es ist ja nur OS 9.2, kein OS X. Ich könnte natürlich mal irgendwas wie tucows durchsuchen. Allerdings...
Alternativ waere der Output von tcpdump hilfreich, wenn ein Mac ne Aufloesung macht. Die dekodierten NS-Queries sollten dann etwas Licht ins Dunkel bringen.
...hab ich im Moment eh keinen Zugriff auf einen der Macs. Stehen alle in der Firma, und ich komm da remote nicht drauf. Ich werd mal sehen, daß ich in den nächsten Tagen den Auswurf von tcpdump herbeischaffe, und hier nochmal posten.
Vielleicht "IN {" noetig, vermute aberm das es keinen Unterschied macht.
Käme auf einen Versuch an. Probier ich auch die nächsten Tage. Danke einstweilen für die Hilfe. Hab so irgendwie das Gefühl, daß mir die Macs eine gehörige Extrawurst braten wollen, und mein Pinguin eigentlich richtig arbeitet. Nun, tcpdump wirds zeigen. Gruß. Andy -- Andreas Feile www.feile.net
Hi Andreas, Andreas Feile wrote:
Peter Wiersig, Dienstag, 23. September 2003 22:12:
Deine Macs fuegen immer die default-Domain an. Probier mal "mailsrv" zu verwenden. (Oder mailsrv.schaible.local. verwenden)
Alles schon probiert, hilft nix. Kurioserweise dauert es mindestens fünf Sekunden, bis mir der Mac sagt, er könne den Namen nicht auflösen. Hingegen funktioniert das reverse lookup sofort.
Zonefiles sehen beide sauber aus. Noch die Config-Ausschnitte und syslog-Meldungen von 'rcbind restart'.
Config:
[...] # Name => Adresse fuer Zone schaible.local zone "schaible.local" in { type master; file "schaible.zone"; notify no; }; # Adresse => Name fuer Zone schaible.local zone "0.168.192.in-addr.arpa" in { type master; file "schaible.enoz"; notify no; };
Und:
mailsrv:~ # rcnamed restart Sep 23 22:25:20 mailsrv named[479]: named shutting down [...]
Das einzige was ich sehe, das auf einen "Fehler" hindeuten kann ist:
Sep 23 22:25:22 mailsrv named[4457]: check_hints: A records for J.ROOT-SERVERS.NET class 1 do not match hint records
Deine root.hint Datei scheint veraltet zu sein. Lade doch die neuste von: ftp://ftp.rs.internic.net/domain/named.root und kopiere sie nach /var/named/root.hint. Starte named doch mal im Vordergrund und schaue, was er so meldet, wenn der MAC den Hostnamen auflösen will. Dies kannst Du mit: named -g -d1 -u named -g run named in the foreground and force all logging to stderr. -d1 Debug Level ziemlich tief. Höhere Zahlen -> mehr Output -u Starte named als User named Siehe auch man named, für eine genauere erklärung der Parameter. Gruss Werner
Werner Merz, Dienstag, 23. September 2003 23:17:
Das einzige was ich sehe, das auf einen "Fehler" hindeuten kann ist:
Sep 23 22:25:22 mailsrv named[4457]: check_hints: A records for J.ROOT-SERVERS.NET class 1 do not match hint records
Deine root.hint Datei scheint veraltet zu sein.
Jo, ist sie wohl in der Tat. Aber das dürfte eigentlich doch nicht dazu führen, daß die Auflösung in einer Zone scheitert, die es ohnehin nur lokal gibt, und die mit Root-Servern nix zu tun hat.
Starte named doch mal im Vordergrund und schaue, was er so meldet, wenn der MAC den Hostnamen auflösen will.
Dies kannst Du mit:
named -g -d1 -u named
Das ist ein guter Tip. Ich werde das tun, sobald ich wieder direkt vor der Kiste sitze. Ich habe da wie gesagt im Moment keinen remote-Zugriff. Ich hab allerdings den Verdacht, daß sich der Mac gar nicht mit meinem named unterhält, denn dann müßte die Meldung, daß irgendwas nicht aufgelöst werden kann, viel schneller kommen. Kommt aber erst nach fünf Sekunden oder so. In diesem Falle aber würde mir der Auswurf von named nichts bringen. Naja, ich werde sehen. Einstweilen vielen Dank! -- Andreas Feile www.feile.net
Am Di, 2003-09-23 um 23.21 schrieb Andreas Feile:
Ich hab allerdings den Verdacht, daß sich der Mac gar nicht mit meinem named unterhält, denn dann müßte die Meldung, daß irgendwas nicht aufgelöst werden kann, viel schneller kommen. Kommt aber erst nach fünf Sekunden oder so. In diesem Falle aber würde mir der Auswurf von named nichts bringen.
In die Richtung denke ich auch. Wohlmöglich kann gar keiner deiner Clients vorwärts auflösen und die Nicht-Mac-Kisten werden anderweitig fündig (Root-DNS oder so). Ich würde mal sagen: Guck doch mal weniger in die Zonendatei, sondern lieber in die named.conf, ob sie überhaupt richtig eingebunden wird. Gruß, Ratti -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Joerg Rossdeutscher, Mittwoch, 24. September 2003 00:52:
In die Richtung denke ich auch. Wohlmöglich kann gar keiner deiner Clients vorwärts auflösen und die Nicht-Mac-Kisten werden anderweitig fündig (Root-DNS oder so). Ich würde mal sagen: Guck doch mal weniger in die Zonendatei, sondern lieber in die named.conf, ob sie überhaupt richtig eingebunden wird.
Für die Vorwärtszone habe ich: zone "schaible.local" in { type master; file "schaible.zone"; notify no; }; Und das Logfile ergibt u.a. beim Start des named: Sep 23 22:25:22 mailsrv named[4456]: master zone "schaible.local" (IN)\ loaded (serial 2003092304) Ich denke, daß die Zonendatei schon richtig eingebunden wird. Die Nicht-Mac-Kisten können auch eigentlich nicht anderweitig fündig werden. Denn einmal geht der lookup auf schaible.local viel schneller, als einer der Root-Server reagieren könnte (nämlich 2 msec). Und zum anderen wird der Root-Server schaible.local nicht auflösen können. Zum Dritten habe ich schon allerlei Fantasieeinträge in die forward-zone gepackt, die die Nicht-Macs alle immer sofort auflösen konnten, bzw. es nicht mehr konnten, sobald ich den Eintrag rausgenommen habe. Komisch ist auch, daß sich mindestens fünf Macs weigern, vorwärts aufzulösen. An einer einzelnen (Fehl-)Konfiguration kann es also nicht liegen. Andererseits können mindestens ebenso viele Nicht-Macs auflösen, darunter eine absolut cleane Linux-Testinstallation, die außer den SuSE-CDs und dem, was der dhcp anliefert, nichts gehört hatten vom Rest der Welt. Also bevor ich weiter diese Liste belaste, werde ich mich mit tcpdump spielen, und dann wieder posten. -- Andreas Feile www.feile.net
Hallo Andreas, Am Mittwoch, 24. September 2003 07:47 schrieb Andreas Feile:
Joerg Rossdeutscher, Mittwoch, 24. September 2003 00:52:
In die Richtung denke ich auch. Wohlmöglich kann gar keiner deiner Clients vorwärts auflösen und die Nicht-Mac-Kisten werden anderweitig fündig (Root-DNS oder so). Ich
Sep 23 22:25:22 mailsrv named[4456]: master zone "schaible.local" (IN)\ loaded (serial 2003092304)
ich habe den Thread nur so überflogen, dabei ist mir aufgefallen, daß deine serial immer die selbe _ (serial 2003092304)_ ist! Kann aber auch Zufall sein. Gruß Werner -- Werner Scharinger Geschäftsführender Gesellschafter der soft & hard Computerservice GmbH * Am Erlenbach 8 * 94032 Passau Tel. +49 851 33025 * Fax. +49 851 31725 * www.shcs.de Fördermitglied der Wirtschaftsjunioren Passau Mitglied der Strategiekommission der Wirtschaftsjunioren Deutschland c/o IHK für Niederbayern in Passau * Nibelungenstr. 15 * 94032 Passau
Hi, Werner Scharinger schrieb:
Hallo Andreas,
Am Mittwoch, 24. September 2003 07:47 schrieb Andreas Feile:
Joerg Rossdeutscher, Mittwoch, 24. September 2003 00:52:
In die Richtung denke ich auch. Wohlmöglich kann gar keiner deiner Clients vorwärts auflösen und die Nicht-Mac-Kisten werden anderweitig fündig (Root-DNS oder so). Ich
Sep 23 22:25:22 mailsrv named[4456]: master zone "schaible.local" (IN)\ loaded (serial 2003092304)
ich habe den Thread nur so überflogen, dabei ist mir aufgefallen, daß deine serial immer die selbe _ (serial 2003092304)_ ist! Kann aber auch Zufall sein.
Gruß Werner
Hab auch nur überflogen... Bist du denn sicher, das die Namens-Auflösung vom Windows-Client aus funzt? Hast du das mit ping _und_ mit nslookup probiert? Ich habe festgestellt, das Windows mit den NetBIOS-Namen "arbeitet", wenn kein DNS auflösen konnte: Bei mir lief ein DHCP-DNS-Samba-PDC ohne Probleme, bis ein Linux-Client dazu kam, der meckerte immer, der Server wäre nicht erreichbar....die Windows-Clients konnten den Namen aber auflösen...naja, hatte den Tippfehler dann auch gleich gefunden ;-) Gruß Detlef
Detlef Reichelt, Mittwoch, 24. September 2003 23:01:
Bist du denn sicher, das die Namens-Auflösung vom Windows-Client aus funzt? Hast du das mit ping _und_ mit nslookup probiert?
Gibts denn nslookup unter Windows? Also ich hab halt immer gepingt, und das geht. Daß hier netbios-Namen im Spiel waren kann nicht sein. Denn ich habe testhalber in den Zonendateien Fantasieeinträge gemacht, die dann auch promt angepingt werden konnten. Die gabs aber keinesfalls irgendwo anders als netbios-Name. Außerdem habe ich mit dig von Linux-Kisten aus gearbeitet. Das, was ich hier als Antwort bekomme, entspricht genau dem, was ich laut DNS-Howto zu erwarten habe. -- Andreas Feile www.feile.net
Andreas Feile wrote:
Detlef Reichelt, Mittwoch, 24. September 2003 23:01:
Bist du denn sicher, das die Namens-Auflösung vom Windows-Client aus funzt? Hast du das mit ping _und_ mit nslookup probiert?
Gibts denn nslookup unter Windows? Also ich hab halt immer gepingt, und das geht. Daß hier netbios-Namen im Spiel waren kann nicht sein. Denn ich habe testhalber in den Zonendateien Fantasieeinträge gemacht, die dann auch promt angepingt werden konnten. Die gabs aber keinesfalls irgendwo anders als netbios-Name. Außerdem habe ich mit dig von Linux-Kisten aus gearbeitet. Das, was ich hier als Antwort bekomme, entspricht genau dem, was ich laut DNS-Howto zu erwarten habe.
moin moin, kannst du den mac vom windows aus anpingen ?? mir scheints als sei das eher ein netzwerk-problem, probier das mal mit dem nslookup bei den win-kisten aus, um zu prüfen ob der nameserver genutzt wird. kenn mich mit mac leider so gar nich aus vielleicht gibs da ja auch sowas wie ein traceroute, da koenntest du ja mal verfolgen wo er 'langgeht' mfg -- ---------------------------------------- Markus Heinze Internet: http://www.existand.de E-Mail : M.Heinze@existand.de Telephon: 03464/569787 Fax : 03464/569786 ----------------------------------------
Markus Heinze, Donnerstag, 25. September 2003 10:01:
kannst du den mac vom windows aus anpingen ??
Das geht nicht, ist aber ein Mac-Spezifikum. Da wird nämlich das tcp-ip-Protokoll nur bei Bedarf geladen. Wenns grad geladen ist, ist die Kiste pingbar, wenn nicht, dann nicht. Ein Netzwerkproblem liegt ziemlich sicher nicht vor. Denn auf den Macs gibts zahlreiche Anwendungen (Datenbank, Teamverwaltung, Drucken übers Netz usw.), die alle tadellos funktionieren, und alle über tcp/ip.
das eher ein netzwerk-problem, probier das mal mit dem nslookup bei den win-kisten aus,
Wo findet man denn nslookup unter Windows? Gruß. Andy -- Andreas Feile www.feile.net
Moin, Am Do, den 25.09.2003 schrieb Andreas Feile um 14:24:
Markus Heinze, Donnerstag, 25. September 2003 10:01:
kannst du den mac vom windows aus anpingen ??
Das geht nicht, ist aber ein Mac-Spezifikum. Da wird nämlich das tcp-ip-Protokoll nur bei Bedarf geladen. Wenns grad geladen ist, ist die Kiste pingbar, wenn nicht, dann nicht.
??? 1. Es gibt im TCP/IP-Kontrollfeld einen Button "TCP/IP nur bei Bedarf laden". Evtl. ist das nur im Usermodus "Admin" sichtbar. 2. Ich habe noch nie erlebt, daß ein Mac nicht ping-bar gewesen wäre. Ich weiss zwar nicht genau, was die obige Option wirklich tut, aber bei einem Mac mit Ethernetkarte und normalen Netzwerkeinstellungen scheint der "bei Bedarf" immer vorzuliegen.
Ein Netzwerkproblem liegt ziemlich sicher nicht vor. Denn auf den Macs gibts zahlreiche Anwendungen (Datenbank, Teamverwaltung, Drucken übers Netz usw.), die alle tadellos funktionieren, und alle über tcp/ip.
Das könnte auch ein Fallback auf plain Appletalk sein, also nicht afpovertcp.
das eher ein netzwerk-problem, probier das mal mit dem nslookup bei den win-kisten aus,
Wo findet man denn nslookup unter Windows?
Schuss ins blaue (hehe), da das bei "netstat" so ist: An der Kommandozeile eintippen? Gruß, Ratti -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Joerg Rossdeutscher, Donnerstag, 25. September 2003 16:54:
1. Es gibt im TCP/IP-Kontrollfeld einen Button "TCP/IP nur bei Bedarf laden". Evtl. ist das nur im Usermodus "Admin" sichtbar.
Jo, weiß ich.
2. Ich habe noch nie erlebt, daß ein Mac nicht ping-bar gewesen wäre. Ich weiss zwar nicht genau, was die obige Option wirklich tut, aber bei einem Mac mit Ethernetkarte und normalen Netzwerkeinstellungen scheint der "bei Bedarf" immer vorzuliegen.
Nein, das ist nicht so. Start mal einen Mac so, daß kein Server gemountet wird, und auch sonst nichts auf das Netz zugreift, und auch die Adresse nicht per dhcp verteilt wird, sondern fix vergeben ist. Dann ist da nix mit pingen.
Ein Netzwerkproblem liegt ziemlich sicher nicht vor. Denn auf den Macs gibts zahlreiche Anwendungen (Datenbank, Teamverwaltung, Drucken übers Netz usw.), die alle tadellos funktionieren, und alle über tcp/ip.
Das könnte auch ein Fallback auf plain Appletalk sein, also nicht afpovertcp.
Noi. Teamverwaltung, Datenbank und Drucker sprechen von vornherein nur tcp/ip. Allenfalls bei dem einen Fileserver könnte appletalk genutzt werden. Der andere ist ein netatalk, und da wird wohl auch tcp ins Spiel kommen ;) Gruß. Andy -- Andreas Feile www.feile.net
Guten Abend. Ich wollte für die, die mir so viele gute Tips gegeben haben, nur eben berichten, was ich mittlerweile herausgefunden habe. Das Problem, daß der Mac meine Adressen nicht auflösen kann, scheint nicht auf der Linux-Seite zu liegen. Es hat sich gezeigt, daß die Windows-Kisten im Netz meinen named für lookups und reverse lookups benutzen. Ebenso machen es die Linux-Kisten. Und ebenso macht es, wie ich herausgefunden habe, die Mac OS X Kiste, die ich eigens aufgesetzt habe. Dies alles kann ich an den logs sehen. Macht ein OS 9.2.2 Client einen reverse lookup, dann wird ebenfalls der DNS-Server befragt. So sagen es jedenfalls die logs. Nur ein normaler lookup scheitert am Mac daran, daß mein named nicht befragt wird. Die logs zeigen einfach keine Anfrage, und das, obwohl das Kontrollfeld den richtigen DNS-Server ausweist. Aber der Mac will sich für (forward) lookups einfach nicht mit meinem named unterhalten. Warum das so ist konnte ich nicht herausfinden, es ist einfach so. Eine Lösung konnte ich nicht finden. Da ich aber annehme, daß es sich um ein Mac-seitiges Problem handelt, ist dafür die Liste mE OT. Vielen Dank nochmal für all die Beiträge, aus denen ich viel gelernt habe. Andy -- Andreas Feile www.feile.net
Moin, Am Fr, den 03.10.2003 schrieb Andreas Feile um 00:47:
Macht ein OS 9.2.2 Client einen reverse lookup, dann wird ebenfalls der DNS-Server befragt. So sagen es jedenfalls die logs. Nur ein normaler lookup scheitert am Mac daran, daß mein named nicht befragt wird. Die logs zeigen einfach keine Anfrage, und das, obwohl das Kontrollfeld den richtigen DNS-Server ausweist. Aber der Mac will sich für (forward) lookups einfach nicht mit meinem named unterhalten.
Machst du DHCP für die Macs? Seit ich auf DHCP umgesattelt habe, steht im TCP/IP-Kontrollfeld _nichts_ für DNS und Default-Domain, trotzdem sind ganz offensichtlich die Angaben aktiv, die ich am Server per DHCP rausgebe. Es kann also sein, daß du einen anderen DNS nutzt, als du glaubst. Das würde auch erklären, warum die Revers-Anfragen funktionieren: Der andere DNS kann nicht beantworten, wer "192.168.0.1" ist. Die Anfrage schlägt fehl, und erst dann wird dein DNS befragt... und die DOSen finden vieleicht aufgrund eines anderen Suchalgorithmus deinen DHCP vor dem anderen und bekommen daher den richtigen DNS mitgeteilt. Probier mal a) eine fixe IP für den Mac b) Guck mal im Netz, ob da ein unerwünschter DHCP rennt Gruß, Ratti P.S.: In diesem Fall wäre es auch wieder ein Linux-Thema. :-) -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
participants (10)
-
Andreas Feile -
Detlef Reichelt -
Joerg Rossdeutscher -
Markus Heinze -
Matthias Houdek -
Peter Wiersig -
Sven Geier -
Ulrich Klenk -
Werner Merz -
Werner Scharinger