named 'tracen' ? - War: verschiedener DNS? - openSUSE Users (Deutsch)

named 'tracen' ? - War: verschiedener DNS?

Jäger Marco

22 Nov 2006 22 Nov '06

14:18

Folgende Situation: Bind soll die direktabfrage "ersetzen", da dort mehr möglichkeiten gegeben sind als wenn das direkt laufen würde (und 'ne IP ruhig mal 2 Std gecached werden sollte - für alle Anwendungen - und nicht nur für den Browser) Leider musste ich feststellen, das einer der rund 30 DNS falsch läuft (ev auch mehrere?) -> bei einer bestimmten dynamischen IP (mehr kenn ich immo ned) wird mal die Antwort von server x genommen, und alles ist ok - nur wenn die Antwort von Server Y kommt, gibts 'ne uralt-IP named / Bind ist soweit konfiguriert, das er cachen sollte - aber manchmal habe ich den Eindruck, er tut nix, bzw wird gar nicht erst befragt ?¿? -> mal bekomm ich ne alte IP, 10 min später dir richtige, 10 weitere Minuten wieder die veraltete ich würd also gerne rausbekommen ob A) named auch genutzt wird (theoretisch gehts nicht anders - unter dns+hostnamen ist nur die lokale ip eingetragen) - jedoch unter dns server (/etc/forwarders.conf) und in /etc/named.conf sind die mir bekannten DNS eingetragen B) Welcher der Server nun die falschen daten hat (um diesen dann aus der liste zu nemen) kann mir da jemand helfen, bzw tipps geben? - irgenwie werd ich aus den man-pages dazu ned wirklich schlau, wie ich das prüfen könnte Gruß, Marco -- ICQ: 51735624 Gadu-Gadu: 4520146 AIM / Yahoo: LinuxCobra MSN: LinuxCobra@gmx.de Jabber: LinuxCobra@jabber.ccc.de http://www.linuxcobra.de PGP-Keyserver:http://wwwkeys.de.pgp.net

Attachments:

attachment.sig (application/pgp-signature — 189 bytes)

Show replies by date

Peter Wiersig

22 Nov 22 Nov

19:09

On Wed, Nov 22, 2006 at 03:18:58PM +0100, Jäger Marco wrote:

...

kann mir da jemand helfen, bzw tipps geben? - irgenwie werd ich aus den man-pages dazu ned wirklich schlau, wie ich das prüfen könnte

Womit fragst du? "dig" hat IMO den bestlesbaren Output. Ausserdem gut lesbar: tcpdump / ethereal Peter -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Jäger Marco

21:03

Am Mittwoch, 22. November 2006 20:09 schrieb Peter Wiersig:

...

On Wed, Nov 22, 2006 at 03:18:58PM +0100, Jäger Marco wrote:

...
kann mir da jemand helfen, bzw tipps geben? - irgenwie werd ich aus den man-pages dazu ned wirklich schlau, wie ich das prüfen könnte

Womit fragst du? "dig" hat IMO den bestlesbaren Output.

Ausserdem gut lesbar: tcpdump / ethereal

Peter

Hmmm ok ich gestehe - ich hab vor allem die manpages von named und bind durchgekaut dig war mir ned wirklich n begriff ;-) dachte da eher an nen debugmode für named, der die info in nen file schreibt, das ich dann erst durchforsten muss :-/ (so nach dem Motto "DNS Lookup for www.xxx.homebox.net from 192.1.1.1 was 111.222.111.222 at 22-11-2006 14:15:15" "DNS Lookup for www.xxx.homebox.net from 212.5.22.1 was failed at 22-11-2006 14:17:15" "DNS Lookup for www.xxx.homebox.net from 212.1.22.1 was 123.123.123.123 at 22-11-2006 14:19:15") dann wüsste ich wann welcher server die falsche antwort rausrückte bzw nebenbei, ob der ein oder andere dns eintrag für die katz ist, weil er nicht antwortet (wie gesagt, ich hab ca 30 eingetragen, das problem dabei ist, das ned immer alle erreichbar sind von den dns - bzw diese nicht reagieren, je nach einwahl - hatte anfangs mit 3 dns 5-6 redials nötig, bis einer antwortete) ich müsste also ne strichliste über nen längeren zeitraum führen, und dann täglich die 30 mittels dig abfragen ... *grusel* eventuell mehmals am tag - je nachdem ob alles ok ist, oder nicht ... dig kann 'leider' auch ned alle eingetragenen dns abfragen und ne komplettliste vorsetzen *seuftz* aber dennoch danke trotzdem - nun kann ich wenigstens etwas machen .... Gruß Marco -- ICQ: 51735624 Gadu-Gadu: 4520146 AIM / Yahoo: LinuxCobra MSN: LinuxCobra@gmx.de Jabber: LinuxCobra@jabber.ccc.de http://www.linuxcobra.de PGP-Keyserver:http://wwwkeys.de.pgp.net

Martin Schröder

23 Nov 23 Nov

01:03

Am 22.11.06 schrieb Jäger Marco :

...

ok ich gestehe - ich hab vor allem die manpages von named und bind durchgekaut dig war mir ned wirklich n begriff ;-) dachte da eher an nen debugmode für named, der die info in nen file schreibt, das ich dann erst durchforsten muss :-/

logging { category default { default_syslog; }; category queries { default_syslog; }; category security { default_syslog; }; category lame-servers { null; }; }; Ansonsten dig +trace Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Jäger Marco

13:54

Am Donnerstag, 23. November 2006 02:03 schrieb Martin Schröder:

...

Am 22.11.06 schrieb Jäger Marco :

...
ok ich gestehe - ich hab vor allem die manpages von named und bind durchgekaut dig war mir ned wirklich n begriff ;-) dachte da eher an nen debugmode für named, der die info in nen file schreibt, das ich dann erst durchforsten muss :-/

logging { category default { default_syslog; }; category queries { default_syslog; }; category security { default_syslog; }; category lame-servers { null; }; };

Ansonsten dig +trace

Gruß Martin

;) so hatte gestern ein kleines bashscript getippt das via dig alle eingetragenen server abklappert (dig @DNS-IP xxx.homebox.net +trace >> ~/DNC-Test.txt) soweit so gut - nur kam eben wieder das Paradoxon: ping -> IP von gestern -> 100% loss script durchlaufen lassen.... von den 30 servern hatten 8 keine zeit, der rest -> antwort ok noch mal ping -> wieder alte ip ... also -> cpu1:~ # rndc status number of zones: 2 debug level: 9 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is ON recursive clients: 0/1000 tcp clients: 0/100 server is up and running cpu1:~ # rndc flush -> ping -> immer noch alte IP Also langsam glaub ich an Gespenster *lol* irgendwo muss die alte ip (seit 8 uhr heute morgen ungültig) ja herkommen ... nur hatte ich gestern nach dem ersten testlauf alle server die ned geantwortet haben, aus den forwarders rausgeworfen und bind nen reload aufgezwungen (sprich die "stummen" server werden nur noch im script getestet, ansonsten sind se "unbekannt") und von den "erreichbaren" hatte jeder !! die richtige IP und der witz dabei ist: via browser erreich ich den Server ............. jemand ne idee, woran das liegen kann, bzw wie ich den fehler auf die spur komme ? -- ICQ: 51735624 Gadu-Gadu: 4520146 AIM / Yahoo: LinuxCobra MSN: LinuxCobra@gmx.de Jabber: LinuxCobra@jabber.ccc.de http://www.linuxcobra.de PGP-Keyserver:http://wwwkeys.de.pgp.net

Arno Lehmann

14:28

Hallo, On 11/23/2006 2:54 PM, Jäger Marco wrote:

...

Am Donnerstag, 23. November 2006 02:03 schrieb Martin Schröder:

...
Am 22.11.06 schrieb Jäger Marco :

...
ok ich gestehe - ich hab vor allem die manpages von named und bind durchgekaut dig war mir ned wirklich n begriff ;-) dachte da eher an nen debugmode für named, der die info in nen file schreibt, das ich dann erst durchforsten muss :-/

logging { category default { default_syslog; }; category queries { default_syslog; }; category security { default_syslog; }; category lame-servers { null; }; };

Ansonsten dig +trace

Gruß Martin

;) so hatte gestern ein kleines bashscript getippt das via dig alle eingetragenen server abklappert (dig @DNS-IP xxx.homebox.net +trace >> ~/DNC-Test.txt)

soweit so gut - nur kam eben wieder das Paradoxon:

ping -> IP von gestern -> 100% loss script durchlaufen lassen.... von den 30 servern hatten 8 keine zeit, der rest -> antwort ok

Was sind denn das für Nameserver? An sich sollte es ja reichen in deinem lokalen nameserver einige wenige server einzutragen, oder gleich die ganze Auflösung selber zu machen und deinen nameserver nur auf die rootserver hinzuweisen.

...

noch mal ping -> wieder alte ip ... also -> cpu1:~ # rndc status number of zones: 2 debug level: 9 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is ON

Dann schau' doch mal ins log...

...

recursive clients: 0/1000 tcp clients: 0/100 server is up and running cpu1:~ # rndc flush -> ping -> immer noch alte IP

Also langsam glaub ich an Gespenster *lol*

Ich vermute mal dass dein nameserver gar nicht benutzt wird. Wie sieht die resolv.conf auf dem Rehner aus, der Probleme macht? Was gibt ein "tcpdump -i eth0 -vv -s 256 port 53" auf dem nameserver aus wenn du eine Adresse auflösen lässt? Hier z.B.: 15:24:57.025163 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: 57) elf.xxx.de.49646 > c.gtld-servers.net.domain: [bad udp cksum c1cf!] 26645 A? www.ibm.net. (29) Anfrage an meinen nameserver elf

...

irgendwo muss die alte ip (seit 8 uhr heute morgen ungültig) ja herkommen ...

nscd?

...

nur hatte ich gestern nach dem ersten testlauf alle server die ned geantwortet haben, aus den forwarders rausgeworfen und bind nen reload aufgezwungen

(sprich die "stummen" server werden nur noch im script getestet, ansonsten sind se "unbekannt")

und von den "erreichbaren" hatte jeder !! die richtige IP

und der witz dabei ist: via browser erreich ich den Server .............

jemand ne idee, woran das liegen kann, bzw wie ich den fehler auf die spur komme ?

Arno -- IT-Service Lehmann al@its-lehmann.de Arno Lehmann http://www.its-lehmann.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Jäger Marco

18:53

Am Donnerstag, 23. November 2006 15:28 schrieb Arno Lehmann:

...

Hallo,

On 11/23/2006 2:54 PM, Jäger Marco wrote: [....] Was sind denn das für Nameserver? An sich sollte es ja reichen in deinem lokalen nameserver einige wenige server einzutragen, oder gleich die ganze Auflösung selber zu machen und deinen nameserver nur auf die rootserver hinzuweisen.

gesammelt durch Einwahl -> da werden mir jedesmal 2 DNS "zugewiesen" ( und sind "nur" dem Routermodem bekannt. Da hab ich dann eine Woche lang deren IP's gesammelt - und die 30 am meisten vorgekommenen in die forwarders geworfen also alle von meinem "lieben Provider TeleCom" + einen DNS der frei verfügbar ist - und ohne cache läuft.

...

...
noch mal ping -> wieder alte ip ... also -> cpu1:~ # rndc status number of zones: 2 debug level: 9 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is ON

Dann schau' doch mal ins log...

*g* wenn ich da nur was finden könnte das einzige was ich bisher "gefunden" hab sind die dig einträge von meinem Check-script unter log/messages (aber auch nur wann welcher sever gefragt wurde) bei ping + sonstigem herrscht stillschweigen dort --- in named.conf definiert -> dump-file "/var/log/named_dump.db"; statistics-file "/var/log/named.stats"; ----> cpu1:~ # cat /var/log/named.stats cat: /var/log/named.stats: No such file or directory ----

...

...
recursive clients: 0/1000 tcp clients: 0/100 server is up and running cpu1:~ # rndc flush -> ping -> immer noch alte IP

Also langsam glaub ich an Gespenster *lol*

Ich vermute mal dass dein nameserver gar nicht benutzt wird. Wie sieht die resolv.conf auf dem Rehner aus, der Probleme macht? cpu1:~ # cat /etc/resolv.conf nameserver 127.0.0.1 search linuxcobra.dydns.org btx.dtag.de cpu1:~ #

...

Was gibt ein "tcpdump -i eth0 -vv -s 256 port 53" auf dem nameserver aus wenn du eine Adresse auflösen lässt? *g* vermutlich nix - eth0 geht ins LAN ;)

-> 1) Ping: cpu1:~ # tcpdump -i eth1 -vv -s 256 port 53 tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 256 bytes 0 packets captured 0 packets received by filter 0 packets dropped by kernel cpu1:~ # parallel dazu ->>>> ping bob-box.home.guschdel.net PING bob-box.home.guschdel.net (84.161.172.241) 56(84) bytes of data. --- bob-box.home.guschdel.net ping statistics --- 256 packets transmitted, 0 received, 100% packet loss, time 255272ms echte IP von bob-box.home.guschdel.net laut dig -> 84.161.186.83 und daraus werd ich ned wirklich schlau *g* - etwas zu viel und zu unübersichtlich ---> 2.) Via Web 1 (klappte) cpu1:~ # tcpdump -i eth1 -vv -s 256 port 53 tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 256 bytes 18:25:23.501998 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 82) cpu1.linuxcobra.dydns.org.exosee > resolv-H2.DTAG.DE.domain: [udp sum ok] 23918+ [1au] AAAA? bob-box.home.guschdel.net. ar: . OPT UDPsize=4096 (54) 18:25:23.590828 IP (tos 0x0, ttl 248, id 7052, offset 0, flags [DF], proto: UDP (17), length: 137) resolv-H2.DTAG.DE.domain > cpu1.linuxcobra.dydns.org.exosee: [udp sum ok] 23918 q: AAAA? bob-box.home.guschdel.net. 0/1/1 ns: guschdel.net. SOA ns.bob-net.de. admin.guschdel.net. 2006112301 10800 3600 604800 300 ar: . OPT UDPsize=4096 (109) 18:25:23.593513 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 103) cpu1.linuxcobra.dydns.org.exosee > dns04.btx.dtag.de.domain: [udp sum ok] 11959+ [1au] AAAA? bob-box.home.guschdel.net.linuxcobra.dydns.org. ar: . OPT UDPsize=4096 (75) 18:25:23.647755 IP (tos 0x0, ttl 60, id 0, offset 0, flags [DF], proto: UDP (17), length: 314) dns04.btx.dtag.de.domain > cpu1.linuxcobra.dydns.org.exosee: 11959- q: AAAA? bob-box.home.guschdel.net.linuxcobra.dydns.org. 0/13/1 ns: . NS K.ROOT-SERVERS.NET., . NS L.ROOT-SERVERS.NET., . NS M.ROOT-SERVERS.NET., . NS A.ROOT-SERVERS.NET., . NS B.ROOT-SERVERS.NET., . NS C.ROOT-SERVERS.NET., . NS D.ROOT-SERVERS.NET., . NS E.ROOT-SERVERS.NET., . NS[|domain] 18:25:23.649414 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 103) cpu1.linuxcobra.dydns.org.exosee > www-proxy.S1.srv.t-online.de.domain: [udp sum ok] 25310+ [1au] AAAA? bob-box.home.guschdel.net.linuxcobra.dydns.org. ar: . OPT UDPsize=4096 (75) 18:25:24.045857 IP (tos 0x0, ttl 56, id 7529, offset 0, flags [none], proto: UDP (17), length: 160) www-proxy.S1.srv.t-online.de.domain > cpu1.linuxcobra.dydns.org.exosee: [udp sum ok] 25310 NXDomain q: AAAA? bob-box.home.guschdel.net.linuxcobra.dydns.org. 0/1/1 ns: dydns.org. SOA master.dydns.com. root.master.dydns.com. 2006060602 10800 3600 3600000 300 ar: . OPT UDPsize=4096 (132) 6 packets captured 12 packets received by filter 0 packets dropped by kernel cpu1:~ # 3.) Via Web 2 (klappte nicht (timeout, verbindung bestand)) cpu1:~ # tcpdump -i eth1 -vv -s 256 port 53 tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 256 bytes 18:32:59.378726 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 82) cpu1.linuxcobra.dydns.org.exosee > dns01.btx.dtag.de.domain: [udp sum ok] 17841+ [1au] AAAA? bob-box.home.guschdel.net. ar: . OPT UDPsize=4096 (54) 18:32:59.433224 IP (tos 0x0, ttl 60, id 0, offset 0, flags [DF], proto: UDP (17), length: 303) dns01.btx.dtag.de.domain > cpu1.linuxcobra.dydns.org.exosee: 17841- q: AAAA? bob-box.home.guschdel.net. 0/13/1 ns: net. NS i.gtld-servers.net., net. NS j.gtld-servers.net., net. NS k.gtld-servers.net., net. NS l.gtld-servers.net., net. NS m.gtld-servers.net., net. NS a.gtld-servers.net., net. NS b.gtld-servers.net., net. NS c.gtld-servers.net., net. NS d.gtld-servers.net., net. NS[|domain] 18:32:59.435037 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 82) cpu1.linuxcobra.dydns.org.exosee > www-proxy.H1.srv.t-online.de.domain: [udp sum ok] 28611+ [1au] AAAA? bob-box.home.guschdel.net. ar: . OPT UDPsize=4096 (54) 18:32:59.530261 IP (tos 0x0, ttl 56, id 53226, offset 0, flags [none], proto: UDP (17), length: 82) www-proxy.H1.srv.t-online.de.domain > cpu1.linuxcobra.dydns.org.exosee: [udp sum ok] 28611 q: AAAA? bob-box.home.guschdel.net. 0/0/1 ar: . OPT UDPsize=4096 (54) 18:32:59.532859 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 103) cpu1.linuxcobra.dydns.org.exosee > www-proxy.K1.srv.t-online.de.domain: [udp sum ok] 17637+ [1au] AAAA? bob-box.home.guschdel.net.linuxcobra.dydns.org. ar: . OPT UDPsize=4096 (75) 18:32:59.733082 IP (tos 0x0, ttl 56, id 61514, offset 0, flags [none], proto: UDP (17), length: 160) www-proxy.K1.srv.t-online.de.domain > cpu1.linuxcobra.dydns.org.exosee: [udp sum ok] 17637 NXDomain q: AAAA? bob-box.home.guschdel.net.linuxcobra.dydns.org. 0/1/1 ns: dydns.org. SOA master.dydns.com. root.master.dydns.com. 2006060602 10800 3600 3600000 300 ar: . OPT UDPsize=4096 (132) 18:33:00.315036 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 96) cpu1.linuxcobra.dydns.org.exosee > dns50.t-ipnet.de.domain: [udp sum ok] 36239+ [1au] AAAA? E.ROOT-SERVERS.NET.linuxcobra.dydns.org. ar: . OPT UDPsize=4096 (68) 18:33:00.371155 IP (tos 0x0, ttl 60, id 0, offset 0, flags [DF], proto: UDP (17), length: 515) dns50.t-ipnet.de.domain > cpu1.linuxcobra.dydns.org.exosee: 36239- q: AAAA? E.ROOT-SERVERS.NET.linuxcobra.dydns.org. 0/13/14 ns: . NS H.ROOT-SERVERS.NET., . NS I.ROOT-SERVERS.NET., . NS J.ROOT-SERVERS.NET., . NS K.ROOT-SERVERS.NET., . NS L.ROOT-SERVERS.NET., . NS M.ROOT-SERVERS.NET., . NS A.ROOT-SERVERS.NET., . NS B.ROOT-SERVERS.NET., . NS C.ROOT-SERVERS.NET., .[| domain] 18:33:00.373010 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 96) cpu1.linuxcobra.dydns.org.exosee > www-proxy.HH1.srv.t-online.de.domain: [udp sum ok] 43185+ [1au] AAAA? E.ROOT-SERVERS.NET.linuxcobra.dydns.org. ar: . OPT UDPsize=4096 (68) 18:33:00.584279 IP (tos 0x0, ttl 56, id 1570, offset 0, flags [none], proto: UDP (17), length: 153) www-proxy.HH1.srv.t-online.de.domain > cpu1.linuxcobra.dydns.org.exosee: [udp sum ok] 43185 NXDomain q: AAAA? E.ROOT-SERVERS.NET.linuxcobra.dydns.org. 0/1/1 ns: dydns.org. SOA master.dydns.com. root.master.dydns.com. 2006060602 10800 3600 3600000 300 ar: . OPT UDPsize=4096 (125) 18:33:00.593604 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 96) cpu1.linuxcobra.dydns.org.exosee > dns03.btx.dtag.de.domain: [udp sum ok] 12214+ [1au] AAAA? D.GTLD-SERVERS.net.linuxcobra.dydns.org. ar: . OPT UDPsize=4096 (68) 18:33:00.822272 IP (tos 0x0, ttl 60, id 18245, offset 0, flags [DF], proto: UDP (17), length: 153) dns03.btx.dtag.de.domain > cpu1.linuxcobra.dydns.org.exosee: [udp sum ok] 12214 NXDomain q: AAAA? D.GTLD-SERVERS.net.linuxcobra.dydns.org. 0/1/1 ns: dydns.org. SOA master.dydns.com. root.master.dydns.com. 2006060602 10800 3600 3600000 300 ar: . OPT UDPsize=4096 (125) 12 packets captured 24 packets received by filter 0 packets dropped by kernel OK - Ping benutzt keinen DNS, und mal bekommt konqueror die richtige info mal nicht......... und laut dig haben alle server die richtige info ........... Nur: ALLE Anfragen müssten meines wissens über named / bind laufen - da in der resolv.conf ja kein echter DNS gelistet ist. also muss von irgenwoher die alte ip auftauchen - named wurde inzwischen mehrfach via ->>> rndc flush "geleert" (allein heute bestimmt 15-20x .....) und falls named irgendwoher die alte ip "zauberte" - warum lief dann ne anfrage? (im log stand dazu gar nix) vor allem: mal klappt alles, 10 min später ist die alte ip wieder da- und wenn ich dann flushe, passiert nix ( immer noch falsche ip vorhanden ...) -- ICQ: 51735624 Gadu-Gadu: 4520146 AIM / Yahoo: LinuxCobra MSN: LinuxCobra@gmx.de Jabber: LinuxCobra@jabber.ccc.de http://www.linuxcobra.de PGP-Keyserver:http://wwwkeys.de.pgp.net -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Peter Wiersig

21:44

On Thu, Nov 23, 2006 at 07:53:48PM +0100, Jäger Marco wrote:

...

3.) Via Web 2 (klappte nicht (timeout, verbindung bestand)) cpu1:~ # tcpdump -i eth1 -vv -s 256 port 53 tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 256 bytes 18:32:59.378726 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 82) cpu1.linuxcobra.dydns.org.exosee > dns01.btx.dtag.de.domain: [udp sum ok] 17841+ [1au] AAAA? bob-box.home.guschdel.net. ar: . OPT UDPsize=4096 (54)

Frage nach einer IPv6 Adresse. Gewollt? http://de.susewiki.org/index.php?title=FAQs#Seiten_im_Internet_.C3.B6ffnen_s... Peter -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Jäger Marco

22:08

Am Donnerstag, 23. November 2006 22:44 schrieb Peter Wiersig:

...

On Thu, Nov 23, 2006 at 07:53:48PM +0100, Jäger Marco wrote:

...
3.) Via Web 2 (klappte nicht (timeout, verbindung bestand)) cpu1:~ # tcpdump -i eth1 -vv -s 256 port 53 tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 256 bytes 18:32:59.378726 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 82) cpu1.linuxcobra.dydns.org.exosee > dns01.btx.dtag.de.domain: [udp sum ok] 17841+ [1au] AAAA? bob-box.home.guschdel.net. ar: . OPT UDPsize=4096 (54)

Frage nach einer IPv6 Adresse. Gewollt? http://de.susewiki.org/index.php?title=FAQs#Seiten_im_Internet_.C3.B6ffnen_ sich_sehr_langsam

Peter

hm eigendlich ned ;) - aber daran kanns ja ned liegen - sonst würde ja zb gmx auch ned erreichbar sein ;) IPV6 würd ja alles beeinfussen - nicht ausgerechnet nen dynamischen privatserver habs aber trotzdem ma rausgeworfen :) Gruß Marco -- ICQ: 51735624 Gadu-Gadu: 4520146 AIM / Yahoo: LinuxCobra MSN: LinuxCobra@gmx.de Jabber: LinuxCobra@jabber.ccc.de http://www.linuxcobra.de PGP-Keyserver:http://wwwkeys.de.pgp.net

Arno Lehmann

22:10

Hallo, On 11/23/2006 7:53 PM, Jäger Marco wrote:

...

Am Donnerstag, 23. November 2006 15:28 schrieb Arno Lehmann:

...
Hallo,

On 11/23/2006 2:54 PM, Jäger Marco wrote:

[....]

...
Was sind denn das für Nameserver? An sich sollte es ja reichen in deinem lokalen nameserver einige wenige server einzutragen, oder gleich die ganze Auflösung selber zu machen und deinen nameserver nur auf die rootserver hinzuweisen.

gesammelt durch Einwahl -> da werden mir jedesmal 2 DNS "zugewiesen" ( und sind "nur" dem Routermodem bekannt. Da hab ich dann eine Woche lang deren IP's gesammelt - und die 30 am meisten vorgekommenen in die forwarders geworfen also alle von meinem "lieben Provider TeleCom" + einen DNS der frei verfügbar ist - und ohne cache läuft.

Ah ja... das Problem dürfte sein dass viele der so gesammelten Nameserver für deine dann aktive IP-Adresse nicht arbeiten mögen.

...

...
...
noch mal ping -> wieder alte ip ... also -> cpu1:~ # rndc status number of zones: 2 debug level: 9 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is ON

Dann schau' doch mal ins log...

*g* wenn ich da nur was finden könnte

Ach so... named läuft normalerweise chroot'ed. Schau mal in /var/lib/named/var/log/named.log - das ist zuminest bei mir der dann gültige Pfad.

...

das einzige was ich bisher "gefunden" hab sind die dig einträge von meinem Check-script unter log/messages (aber auch nur wann welcher sever gefragt wurde) bei ping + sonstigem herrscht stillschweigen dort

--- in named.conf definiert -> dump-file "/var/log/named_dump.db"; statistics-file "/var/log/named.stats"; ----> cpu1:~ # cat /var/log/named.stats cat: /var/log/named.stats: No such file or directory ----

...
...
recursive clients: 0/1000 tcp clients: 0/100 server is up and running cpu1:~ # rndc flush -> ping -> immer noch alte IP

Also langsam glaub ich an Gespenster *lol*

Ich vermute mal dass dein nameserver gar nicht benutzt wird. Wie sieht die resolv.conf auf dem Rehner aus, der Probleme macht?

cpu1:~ # cat /etc/resolv.conf nameserver 127.0.0.1 search linuxcobra.dydns.org btx.dtag.de cpu1:~ #

also der lokal laufende Nameserver. Ist die searchlist Absicht? Ich halte die für etwas eigenwillig... Zumindest sollte - vermutlich - da dyndns stehen und nicht dydns.

...

...
Was gibt ein "tcpdump -i eth0 -vv -s 256 port 53" auf dem nameserver aus wenn du eine Adresse auflösen lässt?

*g* vermutlich nix - eth0 geht ins LAN ;)

Ok, so wie's aussieht müsstest du also auf lo lauschen.

...

-> 1) Ping:

cpu1:~ # tcpdump -i eth1 -vv -s 256 port 53

Aber es soll doch der lokale named gefragt werden. Du verfolgst jetzt, wenn ich deine Konfiguration richtig verstehe, den traffic im lokalen Netz. Da dürfte dann nichts relevantes zu finden sein: Gefragt wird der lokale named, und dessen Anfragen wiederum gehen hoffentlich zu seinen forwarders die im Internet stehen.

...

tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 256 bytes

0 packets captured 0 packets received by filter 0 packets dropped by kernel cpu1:~ #

Soweit passt das zu meinen Vermutungen.

...

parallel dazu ->>>> ping bob-box.home.guschdel.net PING bob-box.home.guschdel.net (84.161.172.241) 56(84) bytes of data.

--- bob-box.home.guschdel.net ping statistics --- 256 packets transmitted, 0 received, 100% packet loss, time 255272ms

echte IP von bob-box.home.guschdel.net laut dig -> 84.161.186.83

und daraus werd ich ned wirklich schlau *g* - etwas zu viel und zu unübersichtlich --->

Na ja, bisher ist nicht ersichtlich woher die Adresse stammt.

...

2.) Via Web 1 (klappte)

cpu1:~ # tcpdump -i eth1 -vv -s 256 port 53 tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 256 bytes 18:25:23.501998 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 82) cpu1.linuxcobra.dydns.org.exosee > resolv-H2.DTAG.DE.domain: [udp sum ok] 23918+ [1au] AAAA? bob-box.home.guschdel.net. ar: . OPT UDPsize=4096 (54) 18:25:23.590828 IP (tos 0x0, ttl 248, id 7052, offset 0, flags [DF], proto: UDP (17), length: 137) resolv-H2.DTAG.DE.domain > cpu1.linuxcobra.dydns.org.exosee: [udp sum ok] 23918 q: AAAA? bob-box.home.guschdel.net. 0/1/1 ns: guschdel.net. SOA ns.bob-net.de. admin.guschdel.net. 2006112301 10800 3600 604800 300 ar: . OPT UDPsize=4096 (109) 18:25:23.593513 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 103) cpu1.linuxcobra.dydns.org.exosee > dns04.btx.dtag.de.domain: [udp sum ok] 11959+ [1au] AAAA? bob-box.home.guschdel.net.linuxcobra.dydns.org. ar: . OPT UDPsize=4096 (75) 18:25:23.647755 IP (tos 0x0, ttl 60, id 0, offset 0, flags [DF], proto: UDP (17), length: 314) dns04.btx.dtag.de.domain > cpu1.linuxcobra.dydns.org.exosee: 11959- q: AAAA? bob-box.home.guschdel.net.linuxcobra.dydns.org. 0/13/1 ns: . NS K.ROOT-SERVERS.NET., . NS L.ROOT-SERVERS.NET., . NS M.ROOT-SERVERS.NET., . NS A.ROOT-SERVERS.NET., . NS B.ROOT-SERVERS.NET., . NS C.ROOT-SERVERS.NET., . NS D.ROOT-SERVERS.NET., . NS E.ROOT-SERVERS.NET., . NS[|domain] 18:25:23.649414 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 103) cpu1.linuxcobra.dydns.org.exosee > www-proxy.S1.srv.t-online.de.domain: [udp sum ok] 25310+ [1au] AAAA? bob-box.home.guschdel.net.linuxcobra.dydns.org. ar: . OPT UDPsize=4096 (75) 18:25:24.045857 IP (tos 0x0, ttl 56, id 7529, offset 0, flags [none], proto: UDP (17), length: 160) www-proxy.S1.srv.t-online.de.domain > cpu1.linuxcobra.dydns.org.exosee: [udp sum ok] 25310 NXDomain q: AAAA? bob-box.home.guschdel.net.linuxcobra.dydns.org. 0/1/1 ns: dydns.org. SOA master.dydns.com. root.master.dydns.com. 2006060602 10800 3600 3600000 300 ar: . OPT UDPsize=4096 (132)

Die einzige reply die ich hier sehe... und da steht dydns wo ich dyndns vermuten würde. Die Antwort ist ein NXDomain, was heisst "No such domain", was heisst das der Name nicht aufgelöst werden konnte.

...

6 packets captured 12 packets received by filter 0 packets dropped by kernel cpu1:~ #

3.) Via Web 2 (klappte nicht (timeout, verbindung bestand))

cpu1:~ # tcpdump -i eth1 -vv -s 256 port 53 tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 256 bytes 18:32:59.378726 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 82) cpu1.linuxcobra.dydns.org.exosee > dns01.btx.dtag.de.domain: [udp sum ok] 17841+ [1au] AAAA? bob-box.home.guschdel.net. ar: . OPT UDPsize=4096 (54) 18:32:59.433224 IP (tos 0x0, ttl 60, id 0, offset 0, flags [DF], proto: UDP (17), length: 303) dns01.btx.dtag.de.domain > cpu1.linuxcobra.dydns.org.exosee: 17841- q: AAAA? bob-box.home.guschdel.net. 0/13/1 ns: net. NS i.gtld-servers.net., net. NS j.gtld-servers.net., net. NS k.gtld-servers.net., net. NS l.gtld-servers.net., net. NS m.gtld-servers.net., net. NS a.gtld-servers.net., net. NS b.gtld-servers.net., net. NS c.gtld-servers.net., net. NS d.gtld-servers.net., net. NS[|domain] 18:32:59.435037 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 82) cpu1.linuxcobra.dydns.org.exosee > www-proxy.H1.srv.t-online.de.domain: [udp sum ok] 28611+ [1au] AAAA? bob-box.home.guschdel.net. ar: . OPT UDPsize=4096 (54) 18:32:59.530261 IP (tos 0x0, ttl 56, id 53226, offset 0, flags [none], proto: UDP (17), length: 82) www-proxy.H1.srv.t-online.de.domain > cpu1.linuxcobra.dydns.org.exosee: [udp sum ok] 28611 q: AAAA? bob-box.home.guschdel.net. 0/0/1 ar: . OPT UDPsize=4096 (54) 18:32:59.532859 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 103) cpu1.linuxcobra.dydns.org.exosee > www-proxy.K1.srv.t-online.de.domain: [udp sum ok] 17637+ [1au] AAAA? bob-box.home.guschdel.net.linuxcobra.dydns.org. ar: . OPT UDPsize=4096 (75) 18:32:59.733082 IP (tos 0x0, ttl 56, id 61514, offset 0, flags [none], proto: UDP (17), length: 160) www-proxy.K1.srv.t-online.de.domain > cpu1.linuxcobra.dydns.org.exosee: [udp sum ok] 17637 NXDomain q: AAAA? bob-box.home.guschdel.net.linuxcobra.dydns.org. 0/1/1 ns: dydns.org. SOA master.dydns.com. root.master.dydns.com. 2006060602 10800 3600 3600000 300 ar: . OPT UDPsize=4096 (132)

Und wieder NXDomain...

...

18:33:00.315036 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 96) cpu1.linuxcobra.dydns.org.exosee > dns50.t-ipnet.de.domain: [udp sum ok] 36239+ [1au] AAAA? E.ROOT-SERVERS.NET.linuxcobra.dydns.org. ar: . OPT UDPsize=4096 (68) 18:33:00.371155 IP (tos 0x0, ttl 60, id 0, offset 0, flags [DF], proto: UDP (17), length: 515) dns50.t-ipnet.de.domain > cpu1.linuxcobra.dydns.org.exosee: 36239- q: AAAA? E.ROOT-SERVERS.NET.linuxcobra.dydns.org. 0/13/14 ns: . NS H.ROOT-SERVERS.NET., . NS I.ROOT-SERVERS.NET., . NS J.ROOT-SERVERS.NET., . NS K.ROOT-SERVERS.NET., . NS L.ROOT-SERVERS.NET., . NS M.ROOT-SERVERS.NET., . NS A.ROOT-SERVERS.NET., . NS B.ROOT-SERVERS.NET., . NS C.ROOT-SERVERS.NET., .[| domain] 18:33:00.373010 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 96) cpu1.linuxcobra.dydns.org.exosee > www-proxy.HH1.srv.t-online.de.domain: [udp sum ok] 43185+ [1au] AAAA? E.ROOT-SERVERS.NET.linuxcobra.dydns.org. ar: . OPT UDPsize=4096 (68) 18:33:00.584279 IP (tos 0x0, ttl 56, id 1570, offset 0, flags [none], proto: UDP (17), length: 153) www-proxy.HH1.srv.t-online.de.domain > cpu1.linuxcobra.dydns.org.exosee: [udp sum ok] 43185 NXDomain q: AAAA? E.ROOT-SERVERS.NET.linuxcobra.dydns.org. 0/1/1 ns: dydns.org. SOA master.dydns.com. root.master.dydns.com. 2006060602 10800 3600 3600000 300 ar: . OPT UDPsize=4096 (125) 18:33:00.593604 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 96) cpu1.linuxcobra.dydns.org.exosee > dns03.btx.dtag.de.domain: [udp sum ok] 12214+ [1au] AAAA? D.GTLD-SERVERS.net.linuxcobra.dydns.org. ar: . OPT UDPsize=4096 (68) 18:33:00.822272 IP (tos 0x0, ttl 60, id 18245, offset 0, flags [DF], proto: UDP (17), length: 153) dns03.btx.dtag.de.domain > cpu1.linuxcobra.dydns.org.exosee: [udp sum ok] 12214 NXDomain q: AAAA? D.GTLD-SERVERS.net.linuxcobra.dydns.org. 0/1/1 ns: dydns.org. SOA master.dydns.com. root.master.dydns.com. 2006060602 10800 3600 3600000 300 ar: . OPT UDPsize=4096 (125)

12 packets captured 24 packets received by filter 0 packets dropped by kernel

OK - Ping benutzt keinen DNS, und mal bekommt konqueror die richtige info mal nicht.........

Ping benutzt eigentlich schon DNS...

...

und laut dig haben alle server die richtige info ...........

Nur: ALLE Anfragen müssten meines wissens über named / bind laufen - da in der resolv.conf ja kein echter DNS gelistet ist.

named / bind ist doch irgendwie der Prototyp eines echten DNS. Ich vermute die Konfiguration des named, soweit er denn benutzt wurde, ist auch kaputt - dass die Searchlist-Einträge an die Namen der root-server angehängt werden ist definitiv falsch. Da fehlt wohl irgendwo ein abschließender Punkt.

...

also muss von irgenwoher die alte ip auftauchen - named wurde inzwischen mehrfach via ->>> rndc flush "geleert" (allein heute bestimmt 15-20x .....) und falls named irgendwoher die alte ip "zauberte" - warum lief dann ne anfrage? (im log stand dazu gar nix)

In dem beobachteten Traffik sehe ich keinen Hinweis das bind irgendwoher IPs zauberte. Eher dürfte da Caching des resolvers (nscd) oder des Browsers hinter stecken. Wenn caching von hostnames aktiviert ist und eine lange positive-time-to-cache gesetzt ist mag das vorkommen. Squid cacht, soweit ich weiß, aufgelöste IPs ebenfalls. Möglicherweise auch dein Webbrowser.

...

vor allem: mal klappt alles, 10 min später ist die alte ip wieder da- und wenn ich dann flushe, passiert nix ( immer noch falsche ip vorhanden ...)

Tja, ich würde erst mal den named richtig konfigurieren. Oder du musst mir die Konfiguration besser erklären :-) Und dann sicherstellen dass der named tatsächlich benutzt wird. Ich weiss nicht wirklich sicher auf welchem deiner hosts der named läuft, von welchem die Anfragen kommen, und so. Arno -- IT-Service Lehmann al@its-lehmann.de Arno Lehmann http://www.its-lehmann.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

David Haller

23:12

Hallo, Am Don, 23 Nov 2006, Arno Lehmann schrieb:

...

Und dann sicherstellen dass der named tatsächlich benutzt wird. Ich weiss nicht wirklich sicher auf welchem deiner hosts der named läuft, von welchem die Anfragen kommen, und so.

Relevant ist auch noch die /etc/nsswitch.conf. Speziell die Eintraege: hosts: files dns networks: files dns So wird z.B. erst (ggfs. via nscd) in die /etc/hosts geschaut, und dann erst der definierte Nameserver (aus /etc/resolv.conf) befragt. -dnh -- Hinhören gehört zum Nachschauen, sonst hat man das Nachsehen. [Jakob Krieger in dag°] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Jäger Marco

27 Nov 27 Nov

10:44

Am Freitag, 24. November 2006 00:12 schrieb David Haller:

...

Hallo,

Am Don, 23 Nov 2006, Arno Lehmann schrieb:

...
Und dann sicherstellen dass der named tatsächlich benutzt wird. Ich weiss nicht wirklich sicher auf welchem deiner hosts der named läuft, von welchem die Anfragen kommen, und so.

Relevant ist auch noch die /etc/nsswitch.conf. Speziell die Eintraege:

hosts: files dns networks: files dns

So wird z.B. erst (ggfs. via nscd) in die /etc/hosts geschaut, und dann erst der definierte Nameserver (aus /etc/resolv.conf) befragt.

-dnh

-- Hinhören gehört zum Nachschauen, sonst hat man das Nachsehen. [Jakob Krieger in dag°]

jupp - und in der /etc/hosts sind nur die ständigen LAN-PC's drinnen, sowie die IP des HW-Routers aber nirgens ist lokal ein PC definiert, der via Inet erreichbar ist (ausser das würde in ner verschlüsselten datei stehen) - sogar via dateimanager-suche konnte nix gefunden werden - im kompletten system (na ja ok - die logs von named wurden angezeigt - aber die waren ja ned "relevant") -- ICQ: 51735624 Gadu-Gadu: 4520146 AIM / Yahoo: LinuxCobra MSN: LinuxCobra@gmx.de Jabber: LinuxCobra@jabber.ccc.de http://www.linuxcobra.de PGP-Keyserver:http://wwwkeys.de.pgp.net

Jäger Marco

24 Nov 24 Nov

00:19

Am Donnerstag, 23. November 2006 23:10 schrieb Arno Lehmann:

...

Hallo,

[...]

...

Ah ja... das Problem dürfte sein dass viele der so gesammelten Nameserver für deine dann aktive IP-Adresse nicht arbeiten mögen.

hmmm also das stimmt so nicht ganz -> via dig @server url antworten fast alle es gibt nur 2 varianten -> entweder ist der dns zuständig für das subnetz, und ich bekomm ne antwort, oder aber er ignoriert mich - und von den 30 aktuelle befragen antworten 22 - also mehr als 60% weil ich denke mal nicht, das ein echter dns nen unterschied macht, ob named frägt, oder ich manuell via dig ........ entweder er mag mich, oder nicht ;)

...

Ach so... named läuft normalerweise chroot'ed. Schau mal in /var/lib/named/var/log/named.log - das ist zuminest bei mir der dann gültige Pfad.

cpu1:~ # cat /var/lib/named/var/log/named.log cat: /var/lib/named/var/log/named.log: No such file or directory cpu1:~ # dir /var/lib/named/var/log/ total 16 drwxr-xr-x 2 named named 4096 Nov 14 12:52 . drwxr-xr-x 9 root root 4096 Aug 27 16:16 .. -rw-r--r-- 1 named named 147 Nov 14 12:49 named.stats -rw-r--r-- 1 named named 335 Nov 14 12:52 named_dump.db cpu1:~ # ^^^^ auch Fehlanzeige *grrrrrrrrrrrrrrrrrrrrr*

...

also der lokal laufende Nameserver.

Ist die searchlist Absicht? Ich halte die für etwas eigenwillig... Zumindest sollte - vermutlich - da dyndns stehen und nicht dydns.

*g* unbeabsichtigte absicht - ich hatte bei dyndns ne url - zuletzt vor etwas über 3 jahren - und da die ja nicht mehr wirklich existiert, hab ich diese dann minimal geändert (so aus nostalgie) = lokale Domain für meine 3 PC's ;)

...

...
...
Was gibt ein "tcpdump -i eth0 -vv -s 256 port 53" auf dem nameserver aus wenn du eine Adresse auflösen lässt?

*g* vermutlich nix - eth0 geht ins LAN ;)

Ok, so wie's aussieht müsstest du also auf lo lauschen.

na ja - ich dachte wegen eth -> du meintest ich soll richtung www lauschen ;) sprich wann geht ne anfrage von named an nen regulären DNS eth0 ---> LAN richtung cpu2, und an dem hängt manchmal cpu3 eth1 ---> Verbindung zum DSL-Router

...

...
-> 1) Ping:

cpu1:~ # tcpdump -i eth1 -vv -s 256 port 53

Aber es soll doch der lokale named gefragt werden. Du verfolgst jetzt, wenn ich deine Konfiguration richtig verstehe, den traffic im lokalen Netz. Da dürfte dann nichts relevantes zu finden sein: Gefragt wird der lokale named, und dessen Anfragen wiederum gehen hoffentlich zu seinen forwarders die im Internet stehen.

genau - und das zu denen wurde "belauscht" :)

...

Na ja, bisher ist nicht ersichtlich woher die Adresse stammt.

joa - und da das logging von namend irgendwie nicht hinhaut (weiß der Teufel wieso) [...] siehe oben ;)

...

Die einzige reply die ich hier sehe... und da steht dydns wo ich dyndns vermuten würde.

Die Antwort ist ein NXDomain, was heisst "No such domain", was heisst das der Name nicht aufgelöst werden konnte.

[...]

...

Ping benutzt eigentlich schon DNS...

...
und laut dig haben alle server die richtige info ...........

Nur: ALLE Anfragen müssten meines wissens über named / bind laufen - da in der resolv.conf ja kein echter DNS gelistet ist.

named / bind ist doch irgendwie der Prototyp eines echten DNS. Ich vermute die Konfiguration des named, soweit er denn benutzt wurde, ist auch kaputt - dass die Searchlist-Einträge an die Namen der root-server angehängt werden ist definitiv falsch. Da fehlt wohl irgendwo ein abschließender Punkt.

...
also muss von irgenwoher die alte ip auftauchen - named wurde inzwischen mehrfach via ->>> rndc flush "geleert" (allein heute bestimmt 15-20x .....) und falls named irgendwoher die alte ip "zauberte" - warum lief dann ne anfrage? (im log stand dazu gar nix)

In dem beobachteten Traffik sehe ich keinen Hinweis das bind irgendwoher IPs zauberte. Eher dürfte da Caching des resolvers (nscd) oder des Browsers hinter stecken. Wenn caching von hostnames aktiviert ist und eine lange positive-time-to-cache gesetzt ist mag das vorkommen. Squid cacht, soweit ich weiß, aufgelöste IPs ebenfalls. Möglicherweise auch dein Webbrowser.

...
vor allem: mal klappt alles, 10 min später ist die alte ip wieder da- und wenn ich dann flushe, passiert nix ( immer noch falsche ip vorhanden ...)

Tja, ich würde erst mal den named richtig konfigurieren. Oder du musst mir die Konfiguration besser erklären :-)

;) erklären ist gut *g* - ich hab mir nur etwa 30 beispiele für named studiert - und dann die standard named.conf von suse geringfügig geändert (das zb anfragen von den LAN-PCS auch akzeptiert werden ;) soweit ich die config - beispiele "verstanden" hab, müsste alles laufen ;) also "geplante" config -> alle PCs im lan via lokalem dns cache "versorgen" (IP's sollten 5-10 min gespeichert werden) - wobei pc 3 ned wirklich ins inet geht - der muss nur an die internen NFS-Server.

...

Und dann sicherstellen dass der named tatsächlich benutzt wird. Ich weiss nicht wirklich sicher auf welchem deiner hosts der named läuft, von welchem die Anfragen kommen, und so.

cpu1 = hauptrechner mit named + Maildienst + standard-firewall - cpu2 wird "nur" geroutet und auf nem gerouteten rechner nen dns ? unpraktisch, oder ? und named muss ja genutzt werden - sonst würd das inet ja ned gehen - oder ? Gruß marco -- ICQ: 51735624 Gadu-Gadu: 4520146 AIM / Yahoo: LinuxCobra MSN: LinuxCobra@gmx.de Jabber: LinuxCobra@jabber.ccc.de http://www.linuxcobra.de PGP-Keyserver:http://wwwkeys.de.pgp.net

Arno Lehmann

01:18

Hallo, On 11/24/2006 1:19 AM, Jäger Marco wrote:

...

Am Donnerstag, 23. November 2006 23:10 schrieb Arno Lehmann:

...
Hallo,

[...]

...
Ah ja... das Problem dürfte sein dass viele der so gesammelten Nameserver für deine dann aktive IP-Adresse nicht arbeiten mögen.

hmmm also das stimmt so nicht ganz -> via dig @server url antworten fast alle es gibt nur 2 varianten -> entweder ist der dns zuständig für das subnetz, und ich bekomm ne antwort, oder aber er ignoriert mich - und von den 30 aktuelle befragen antworten 22 - also mehr als 60%

weil ich denke mal nicht, das ein echter dns nen unterschied macht, ob named frägt, oder ich manuell via dig ........ entweder er mag mich, oder nicht ;)

Schon richtig, aber ich vermute mal dass es immer die gleichen sind die dir antworten, bzw. die nicht antworten.

...

...
Ach so... named läuft normalerweise chroot'ed. Schau mal in /var/lib/named/var/log/named.log - das ist zuminest bei mir der dann gültige Pfad.

cpu1:~ # cat /var/lib/named/var/log/named.log cat: /var/lib/named/var/log/named.log: No such file or directory cpu1:~ # dir /var/lib/named/var/log/ total 16 drwxr-xr-x 2 named named 4096 Nov 14 12:52 . drwxr-xr-x 9 root root 4096 Aug 27 16:16 .. -rw-r--r-- 1 named named 147 Nov 14 12:49 named.stats -rw-r--r-- 1 named named 335 Nov 14 12:52 named_dump.db cpu1:~ #

^^^^ auch Fehlanzeige *grrrrrrrrrrrrrrrrrrrrr*

Und was ist in der Konfiguration eingestellt? Irgendwas muss doch in der Konfiguration eingestellt sein. Stichwort logging { channel {}; category... }; dump-file und statistics-file sind NICHT log-Dateien. Oder probier mal mit lsof zu sehen was für Dateien der named offen hat.

...

...
also der lokal laufende Nameserver.

Ist die searchlist Absicht? Ich halte die für etwas eigenwillig... Zumindest sollte - vermutlich - da dyndns stehen und nicht dydns.

*g* unbeabsichtigte absicht - ich hatte bei dyndns ne url - zuletzt vor etwas über 3 jahren - und da die ja nicht mehr wirklich existiert, hab ich diese dann minimal geändert (so aus nostalgie) = lokale Domain für meine 3 PC's ;)

Keine gute Idee. Was passiert denn wenn irgend jemand mal die domain dydns.org in Betrieb nimmt? Für deinen Zweck gibt es bessere Möglichkeiten. genau genommen ist, was du machst, sogar von Grund auf flasch. Man soll nämlich nur zonen verwalten für die man zuständig ist, bzw. die explizit für lokale Benutzung gedachten Zonen.

...

...
...
...
Was gibt ein "tcpdump -i eth0 -vv -s 256 port 53" auf dem nameserver aus wenn du eine Adresse auflösen lässt?

*g* vermutlich nix - eth0 geht ins LAN ;)

Ok, so wie's aussieht müsstest du also auf lo lauschen.

na ja - ich dachte wegen eth -> du meintest ich soll richtung www lauschen ;) sprich wann geht ne anfrage von named an nen regulären DNS

eth0 ---> LAN richtung cpu2, und an dem hängt manchmal cpu3 eth1 ---> Verbindung zum DSL-Router

...
...
-> 1) Ping:

cpu1:~ # tcpdump -i eth1 -vv -s 256 port 53

Aber es soll doch der lokale named gefragt werden. Du verfolgst jetzt, wenn ich deine Konfiguration richtig verstehe, den traffic im lokalen Netz. Da dürfte dann nichts relevantes zu finden sein: Gefragt wird der lokale named, und dessen Anfragen wiederum gehen hoffentlich zu seinen forwarders die im Internet stehen.

genau - und das zu denen wurde "belauscht" :)

Ok.

...

...
Na ja, bisher ist nicht ersichtlich woher die Adresse stammt.

joa - und da das logging von namend irgendwie nicht hinhaut (weiß der Teufel wieso)

BIND Administrators Reference Manual lesen...

...

[...] siehe oben ;)

...
Die einzige reply die ich hier sehe... und da steht dydns wo ich dyndns vermuten würde.

Die Antwort ist ein NXDomain, was heisst "No such domain", was heisst das der Name nicht aufgelöst werden konnte.

[...]

...
Ping benutzt eigentlich schon DNS...

...
und laut dig haben alle server die richtige info ...........

Nur: ALLE Anfragen müssten meines wissens über named / bind laufen - da in der resolv.conf ja kein echter DNS gelistet ist.

named / bind ist doch irgendwie der Prototyp eines echten DNS. Ich vermute die Konfiguration des named, soweit er denn benutzt wurde, ist auch kaputt - dass die Searchlist-Einträge an die Namen der root-server angehängt werden ist definitiv falsch. Da fehlt wohl irgendwo ein abschließender Punkt.

Dieser Punkt wäre noch mal zu klären.

...

...
...
also muss von irgenwoher die alte ip auftauchen - named wurde inzwischen mehrfach via ->>> rndc flush "geleert" (allein heute bestimmt 15-20x .....) und falls named irgendwoher die alte ip "zauberte" - warum lief dann ne anfrage? (im log stand dazu gar nix)

In dem beobachteten Traffik sehe ich keinen Hinweis das bind irgendwoher IPs zauberte. Eher dürfte da Caching des resolvers (nscd) oder des Browsers hinter stecken. Wenn caching von hostnames aktiviert ist und eine lange positive-time-to-cache gesetzt ist mag das vorkommen. Squid cacht, soweit ich weiß, aufgelöste IPs ebenfalls. Möglicherweise auch dein Webbrowser.

...
vor allem: mal klappt alles, 10 min später ist die alte ip wieder da- und wenn ich dann flushe, passiert nix ( immer noch falsche ip vorhanden ...)

Tja, ich würde erst mal den named richtig konfigurieren. Oder du musst mir die Konfiguration besser erklären :-)

;) erklären ist gut *g* - ich hab mir nur etwa 30 beispiele für named studiert - und dann die standard named.conf von suse geringfügig geändert (das zb anfragen von den LAN-PCS auch akzeptiert werden ;) soweit ich die config - beispiele "verstanden" hab, müsste alles laufen ;)

Das ist keine Erklärung für mich.

...

also "geplante" config -> alle PCs im lan via lokalem dns cache "versorgen" (IP's sollten 5-10 min gespeichert werden) - wobei pc 3 ned wirklich ins inet geht - der muss nur an die internen NFS-Server.

Dafür ist das vermutlich etwas übertrieben, einen Nameserver sinnvoll einzusetzen ist nämlich ziemlich aufwendig :-) Wenn du einen halbwegs brauchbaren Router hast kann der als Proxy / cacheing Nameserver arbeiten. Andernfalls kannst du auf den clients ggf. zwei zuverlässige Nameserver aus dem Internet eintragen (eine Liste hast du ja schon :-) und die lokalen Hostnamen per hosts-Datei festlegen. Schliesslich gibt es auch noch kompaktere und einfacher einzurichtende Programme als bind wenn du nur einen cacheing Nameserver suchst. Mir fallen nur grade keine ein :-)

...

...
Und dann sicherstellen dass der named tatsächlich benutzt wird. Ich weiss nicht wirklich sicher auf welchem deiner hosts der named läuft, von welchem die Anfragen kommen, und so.

cpu1 = hauptrechner mit named + Maildienst + standard-firewall - cpu2 wird "nur" geroutet und auf nem gerouteten rechner nen dns ? unpraktisch, oder ?

Da gibt's auch andere Ansichten, und es hängt, wie üblich, stark vom Einsatzzweck ab. So wie du das skizzierst würde ich dann selber einen zentralen named betreiben wenn ich weitere Funktionalitäten brauche, z.B. lokale Auflösung mit dynamischer Änderung, oder viele lokale Hosts hätte.

...

und named muss ja genutzt werden - sonst würd das inet ja ned gehen - oder ?

Nein. Nur wenn tatsächlich cpu1 als einziger resolver bei den clients eingetragen ist. Was mir immer noch fehlt ist ein tcpdump der tatsächlich zeigt dass dein named zur Namensauflösung benutzt wird. Meine Beobachtung von vorhin muss ich übrigens korrigieren (ist doch schon spät :-) Es sind durchaus replys von externen Nameservern vorhanden, mit Verweisen auf andere Nameserver dabei. Allerdings auch welche mit NXDomain. Da könnte die Beschränkung auf die richtigen Forwarder helfen. Andererseits bleibt immer noch zu klären warum den Verweisen nicht gefolgt wird. Ich würde immer noch vorschlagen erst einmal die named.conf in Ordnung zu bringen. Forwarders aufräumen, logging einstellen. Dann vom lokalen Rechner aus probieren, mit tcpdump zusehen. Dann von anderen Rechnern aus dem lokalen Netz. Arno

...

Gruß marco

------------------------------------------------------------------------

# Copyright (c) 2001-2004 SuSE Linux AG, Nuernberg, Germany. # All rights reserved. # # Author: Frank Bodammer, Lars Mueller # # /etc/named.conf # # This is a sample configuration file for the name server BIND 9. It works as # a caching only name server without modification. # # A sample configuration for setting up your own domain can be found in # /usr/share/doc/packages/bind/sample-config. # # A description of all available options can be found in # /usr/share/doc/packages/bind/misc/options.

options {

# The directory statement defines the name server's working directory

directory "/var/lib/named";

# Write dump and statistics file to the log subdirectory. The # pathenames are relative to the chroot jail.

dump-file "/var/log/named_dump.db"; statistics-file "/var/log/named.stats";

# The forwarders record contains a list of servers to which queries # should be forwarded. Enable this line and modify the IP address to # your provider's name server. Up to three servers may be listed.

#forwarders { 217.160.221.181; };

# Enable the next entry to prefer usage of the name server declared in # the forwarders section.

forward first;

# The listen-on record contains a list of local network interfaces to # listen on. Optionally the port can be specified. Default is to # listen on all interfaces found on your system. The default port is # 53.

listen-on port 53 { 127.0.0.1; 192.168.2.20; };

# The listen-on-v6 record enables or disables listening on IPv6 # interfaces. Allowed values are 'any' and 'none' or a list of # addresses.

#listen-on-v6 { any; };

# The next three statements may be needed if a firewall stands between # the local server and the internet.

#query-source address * port 53; #transfer-source * port 53; #notify-source * port 53;

# The allow-query record contains a list of networks or IP addresses # to accept and deny queries from. The default is to allow queries # from all hosts.

allow-query { 127/8; 192.168.2.0/24; };

# If notify is set to yes (default), notify messages are sent to other # name servers when the the zone data is changed. Instead of setting # a global 'notify' statement in the 'options' section, a separate # 'notify' can be added to each zone definition.

notify no; include "/etc/named.d/forwarders.conf"; };

# To configure named's logging remove the leading '#' characters of the # following examples. #logging { # # Log queries to a file limited to a size of 100 MB. # channel query_logging { # file "/var/log/named_querylog" # versions 3 size 100M; # print-time yes; // timestamp log entries # }; # category queries { # query_logging; # }; # # # Or log this kind alternatively to syslog. # channel syslog_queries { # syslog user; # severity info; # }; # category queries { syslog_queries; }; # # # Log general name server errors to syslog. # channel syslog_errors { # syslog user; # severity error; # }; # category default { syslog_errors; }; # # # Don't log lame server messages. # category lame-servers { null; }; #}; logging { category default { default_syslog; }; category xfer-in { default_syslog; }; category queries { default_syslog; }; category security { default_syslog; }; category lame-servers { null; }; }; # The following zone definitions don't need any modification. The first one # is the definition of the root name servers. The second one defines # localhost while the third defines the reverse lookup for localhost.

zone "." in { type hint; file "root.hint"; };

zone "localhost" in { type master; file "localhost.zone"; };

zone "2.168.192.in-addr.arpa" in { type master; file "master/2.168.192.in-addr.arpa.zone"; };

zone "0.0.127.in-addr.arpa" in { type master; file "127.0.0.zone"; };

# Include the meta include file generated by createNamedConfInclude. This # includes all files as configured in NAMED_CONF_INCLUDE_FILES from # /etc/sysconfig/named

include "/etc/named.conf.include"; #logging { # category queries { log_syslog; }; # # category default { log_syslog; }; # channel log_syslog { syslog; }; #};

# You can insert further zone records for your own domains below or create # single files in /etc/named.d/ and add the file names to # NAMED_CONF_INCLUDE_FILES. # See /usr/share/doc/packages/bind/README.SUSE for more details.

-- IT-Service Lehmann al@its-lehmann.de Arno Lehmann http://www.its-lehmann.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Jäger Marco

08:02

Am Freitag, 24. November 2006 02:18 schrieb Arno Lehmann:

...

Hallo,

[.....]

...

On 11/24/2006 1:19 AM, Jäger Marco wrote:

...
Am Donnerstag, 23. November 2006 23:10 schrieb Arno Lehmann:

...
Hallo,

[...]

...
Ah ja... das Problem dürfte sein dass viele der so gesammelten Nameserver für deine dann aktive IP-Adresse nicht arbeiten mögen.

hmmm also das stimmt so nicht ganz -> via dig @server url antworten fast alle es gibt nur 2 varianten -> entweder ist der dns zuständig für das subnetz, und ich bekomm ne antwort, oder aber er ignoriert mich - und von den 30 aktuelle befragen antworten 22 - also mehr als 60%

weil ich denke mal nicht, das ein echter dns nen unterschied macht, ob named frägt, oder ich manuell via dig ........ entweder er mag mich, oder nicht ;)

Schon richtig, aber ich vermute mal dass es immer die gleichen sind die dir antworten, bzw. die nicht antworten.

also - in nem script hab ich seit gestern alle dns die ich kenne drin - das frägt via dig alle einzeln ab - und nach dem ersten durchlauf hab ich alle antwortfaulen aus den forwarders genommen. (sprich da sind aktuell nur die 22 drin die mich gestern mochten (mein redial ist auch morgens gegen 7:15) - und für heute ist dasselbe geplant ;) das script rennt alle 4 h ...

...

...
...
Ach so... named läuft normalerweise chroot'ed. Schau mal in /var/lib/named/var/log/named.log - das ist zuminest bei mir der dann gültige Pfad.

cpu1:~ # cat /var/lib/named/var/log/named.log cat: /var/lib/named/var/log/named.log: No such file or directory cpu1:~ # dir /var/lib/named/var/log/ total 16 drwxr-xr-x 2 named named 4096 Nov 14 12:52 . drwxr-xr-x 9 root root 4096 Aug 27 16:16 .. -rw-r--r-- 1 named named 147 Nov 14 12:49 named.stats -rw-r--r-- 1 named named 335 Nov 14 12:52 named_dump.db cpu1:~ #

^^^^ auch Fehlanzeige *grrrrrrrrrrrrrrrrrrrrr*

Und was ist in der Konfiguration eingestellt? Irgendwas muss doch in der Konfiguration eingestellt sein. Stichwort logging { channel {}; category... }; dump-file und statistics-file sind NICHT log-Dateien. Oder probier mal mit lsof zu sehen was für Dateien der named offen hat.

direkt nicht festgelegt (so wie dump / statistics) "Nur" logging { category default { default_syslog; }; .... in den beispielen fand ich dazu keine info :( und warum haste nicht in meine named.conf geschaut, die klebte doch an der mail von 1:19 ;) lsof sagt mir, das named nix loggt (sind nur die libs offen, sowie ports) [....]

...

...
...
Na ja, bisher ist nicht ersichtlich woher die Adresse stammt.

joa - und da das logging von namend irgendwie nicht hinhaut (weiß der Teufel wieso)

BIND Administrators Reference Manual lesen...

;) studiert - aber ned wirklich schlauer was das logging angeht -> entweder man nimmt (so wie ich) logging { category default { default_syslog; }; category xfer-in { default_syslog; }; category queries { default_syslog; }; category security { default_syslog; }; category lame-servers { null; }; }; oder man definiert statt dessen das jeweillige file -> Zitat Example usage of the size and versions options: channel "an_example_channel" { file "example.log" versions 3 size 20m; print-time yes; print-category yes; }; nur wie man das via default_syslog definiert, wurde auch dort nicht verraten ---> http://www.bind9.net/manual/bind/9.2.4/Bv9ARM.ch06.html#AEN1525 [...]

...

...
...
named / bind ist doch irgendwie der Prototyp eines echten DNS. Ich vermute die Konfiguration des named, soweit er denn benutzt wurde, ist auch kaputt - dass die Searchlist-Einträge an die Namen der root-server angehängt werden ist definitiv falsch. Da fehlt wohl irgendwo ein abschließender Punkt.

Dieser Punkt wäre noch mal zu klären.

joa - nur wie ? rcnamed reload meldet, das named.conf einwandfrei gelesen werden konnte - und von daher ist die fehlersuche nach nem punkt etwas schwierig - ausser ich setz in zeile 1 nen punkt, dann reload named, und wenn named ned meckert -> fehler gefunden ? Spaß beiseite, die art von fehlersuche kanns ned sein die weiterhilft - und die named conf mittels auge überprüfen? - mehrfach passiert - ohne ergebnis auch deshalb hatte ich an der mail von 1.19 Uhr die named.conf - vier Augen sehen mehr als 2 - wobei es nicht bei vier bleiben dürfte die sich den anhang anguggen - und damit steigen die chancen, den (oder die?) fehler schnell zu finden. [....]

...

...
;) erklären ist gut *g* - ich hab mir nur etwa 30 beispiele für named studiert - und dann die standard named.conf von suse geringfügig geändert (das zb anfragen von den LAN-PCS auch akzeptiert werden ;) soweit ich die config - beispiele "verstanden" hab, müsste alles laufen ;)

Das ist keine Erklärung für mich.

;) ist mir auch klar - nur wie soll ich was erklären ? das war erstmal nur ne erläuterung wie ich zur aktuellen config gekommen bin. wie die hw-config aussieht hab ich ja auch aufgelistet - nur wie ne config erklären ohne ne konkrete frage zu nem bestimmten punkt darin ? auch deshalb hatte ich an der mail von 1.19 Uhr die named.conf -> configs sind oft selbsterklärend (zumindest teilweise)

...

...
also "geplante" config -> alle PCs im lan via lokalem dns cache "versorgen" (IP's sollten 5-10 min gespeichert werden) - wobei pc 3 ned wirklich ins inet geht - der muss nur an die internen NFS-Server.

Dafür ist das vermutlich etwas übertrieben, einen Nameserver sinnvoll einzusetzen ist nämlich ziemlich aufwendig :-)

Inwiefern übertrieben ? das DNS-Anfragen von cpu1 und/oder cpu2 etwas gecached werden sollen? ich hab öfters den Fall das ich an beiden Pcs mit derselben URL arbeite (arbeiten muss) - und das parallel da wäre ein cache dazu ja eher sinnvoll

...

Wenn du einen halbwegs brauchbaren Router hast kann der als Proxy / cacheing Nameserver arbeiten.

genau genommen arbeite ich mit 2 routern (rein technisch gesehen) 1x -> HW Router der Telecom (DSL-Modemrouter) 1x -> cpu1 .... und auf cpu1 läuft ja named (irgendwie) ....

...

Andernfalls kannst du auf den clients ggf. zwei zuverlässige Nameserver aus dem Internet eintragen (eine Liste hast du ja schon :-) und die lokalen Hostnamen per hosts-Datei festlegen.

die lokalen hosts sind dort schon definiert - und 2 reguläre DNS eintragen parallel auf den rechnern bringt ned wirklich etwas : 1.) hatte ich, als ich das DSL installierte folgendes problem -> einwahl 1 -> inet ned erreichbar (bzw die DNS) -> DNS in die resolv eingetragen einwahl2 -> beide DNS von der letzten einwahl waren nicht mehr zuständig 2.) ich hab manchmal nen pc hier für updates (von der fam ohne inet), da will ich ned extra jedesmal für nen update (so alle 4 Monate) die aktuell gültigen DNS eintragen - sondern die PC's sind so konfiguriert : DCHP von cpu2 befragen, cpu1 ist der router + dns fürs inet sprich: ich muss se hochfahren -> und schon kann das update laufen (und leitungsmässig sitzt der pc dann parallel zu cpu2)

...

Schliesslich gibt es auch noch kompaktere und einfacher einzurichtende Programme als bind wenn du nur einen cacheing Nameserver suchst. Mir fallen nur grade keine ein :-)

:-) na ja kompakter und einfacher ? möglich - wobei ich bind ned grade als kompliziert einstufen würde ;-) ausserdem muss kompakter ned gleich besser sein ;- ) und ob se so stabil wie bind sind ? hmmm nicht garantiert *g* und bind dürfte auch noch in 5 jahren von den entwicklern gepflegt werden - bei anderen programmen ist das ned so sicher und bei suche nach dns-programmen für linux meldet sogar google bevorzugt bind :-) 3:0 für bind als wahl würd ich mal sagen

...

...
...
Und dann sicherstellen dass der named tatsächlich benutzt wird. Ich weiss nicht wirklich sicher auf welchem deiner hosts der named läuft, von welchem die Anfragen kommen, und so.

cpu1 = hauptrechner mit named + Maildienst + standard-firewall - cpu2 wird "nur" geroutet und auf nem gerouteten rechner nen dns ? unpraktisch, oder ?

Da gibt's auch andere Ansichten, und es hängt, wie üblich, stark vom Einsatzzweck ab. So wie du das skizzierst würde ich dann selber einen zentralen named betreiben wenn ich weitere Funktionalitäten brauche, z.B. lokale Auflösung mit dynamischer Änderung, oder viele lokale Hosts hätte.

Hmm 3 eigene Pcs + 5 weitere die via DCHP regelmässig "gefüttert" werden (siehe oben)

...

...
und named muss ja genutzt werden - sonst würd das inet ja ned gehen - oder ?

Nein. Nur wenn tatsächlich cpu1 als einziger resolver bei den clients eingetragen ist.

die verweisen alle auf 192.168.2.20 -> IP cpu1 /eth0 (LAN)

...

Was mir immer noch fehlt ist ein tcpdump der tatsächlich zeigt dass dein named zur Namensauflösung benutzt wird. ? tcpdump lief richtung www - zeigte also das was named mit den "echten" DNS "laberte"

Meine Beobachtung von vorhin muss ich übrigens korrigieren (ist doch schon spät :-) Es sind durchaus replys von externen Nameservern vorhanden, mit Verweisen auf andere Nameserver dabei. Allerdings auch welche mit NXDomain. Da könnte die Beschränkung auf die richtigen Forwarder helfen.

Kann passieren ;) wie gesagt - aktuell sind "nur" dns in den forwarders, die mir via dig ne antwort geben - nur halt sortiert nach IP, nicht nach der zeit *gg*

...

Andererseits bleibt immer noch zu klären warum den Verweisen nicht gefolgt wird.

genau - und daran knabbere ich ja :((

...

Ich würde immer noch vorschlagen erst einmal die named.conf in Ordnung zu bringen. Forwarders aufräumen, logging einstellen. Dann vom lokalen Rechner aus probieren, mit tcpdump zusehen. Dann von anderen Rechnern aus dem lokalen Netz.

genau da liegt der Hase in der Pfeffersauce *g* - immo arbeite ich nur via cpu1 daran - cpu2 läuft "nebenbei" (wobei der auch ins inet kommt aktuell - ohne schwierigkeiten - und solange das so ist, lass ich den auch links liegen :-) ) und die named.conf müsste, soweit ich die examples für die config, bzw die config-manuals dazu verstanden hab, so weit korrekt sein (bis auf das logging, siehe oben) - und finde den / die Fehler nicht wirklich (Möglichkeit-> ich seh den Fehler, denk aber das stimmt so) [betriebsblind] und nun wieder der satz *reply on* auch deshalb hatte ich an der mail von 1.19 Uhr die named.conf dran kleben *reply off* :-)) weil ich versuch erst mal selber, eventuelle fehler die ich selbst fabrizier, zu lokalisieren (manpages, manuals, archiv der suse-liste, ...) bevor ich anfange, selber zu tippen nur : wenn ich gar nicht mehr weiterkomm mit meinem latein dann fang ich an zu tippen -- ICQ: 51735624 Gadu-Gadu: 4520146 AIM / Yahoo: LinuxCobra MSN: LinuxCobra@gmx.de Jabber: LinuxCobra@jabber.ccc.de http://www.linuxcobra.de PGP-Keyserver:http://wwwkeys.de.pgp.net

Arno Lehmann

25 Nov 25 Nov

00:06

Hallo, On 11/24/2006 9:02 AM, Jäger Marco wrote:

...

Am Freitag, 24. November 2006 02:18 schrieb Arno Lehmann:

...
Hallo,

[.....]

...
On 11/24/2006 1:19 AM, Jäger Marco wrote:

...
Am Donnerstag, 23. November 2006 23:10 schrieb Arno Lehmann:

...
Hallo,

[...]

...
Ah ja... das Problem dürfte sein dass viele der so gesammelten Nameserver für deine dann aktive IP-Adresse nicht arbeiten mögen.

hmmm also das stimmt so nicht ganz -> via dig @server url antworten fast alle es gibt nur 2 varianten -> entweder ist der dns zuständig für das subnetz, und ich bekomm ne antwort, oder aber er ignoriert mich - und von den 30 aktuelle befragen antworten 22 - also mehr als 60%

weil ich denke mal nicht, das ein echter dns nen unterschied macht, ob named frägt, oder ich manuell via dig ........ entweder er mag mich, oder nicht ;)

Schon richtig, aber ich vermute mal dass es immer die gleichen sind die dir antworten, bzw. die nicht antworten.

also - in nem script hab ich seit gestern alle dns die ich kenne drin - das frägt via dig alle einzeln ab - und nach dem ersten durchlauf hab ich alle antwortfaulen aus den forwarders genommen. (sprich da sind aktuell nur die 22 drin die mich gestern mochten (mein redial ist auch morgens gegen 7:15) - und für heute ist dasselbe geplant ;) das script rennt alle 4 h ...

...
...
...
Ach so... named läuft normalerweise chroot'ed. Schau mal in /var/lib/named/var/log/named.log - das ist zuminest bei mir der dann gültige Pfad.

cpu1:~ # cat /var/lib/named/var/log/named.log cat: /var/lib/named/var/log/named.log: No such file or directory cpu1:~ # dir /var/lib/named/var/log/ total 16 drwxr-xr-x 2 named named 4096 Nov 14 12:52 . drwxr-xr-x 9 root root 4096 Aug 27 16:16 .. -rw-r--r-- 1 named named 147 Nov 14 12:49 named.stats -rw-r--r-- 1 named named 335 Nov 14 12:52 named_dump.db cpu1:~ #

^^^^ auch Fehlanzeige *grrrrrrrrrrrrrrrrrrrrr*

Und was ist in der Konfiguration eingestellt? Irgendwas muss doch in der Konfiguration eingestellt sein. Stichwort logging { channel {}; category... }; dump-file und statistics-file sind NICHT log-Dateien. Oder probier mal mit lsof zu sehen was für Dateien der named offen hat.

direkt nicht festgelegt (so wie dump / statistics) "Nur" logging { category default { default_syslog; }; .... in den beispielen fand ich dazu keine info :( und warum haste nicht in meine named.conf geschaut, die klebte doch an der mail von 1:19 ;)

Erstens hab' ich oft keine Lust Attachments in Mailinglisten zu öffnen, zweitens bestand die Datei fast nur aus Kommentaren, die hättest du auch rausfiltern können (z.B. grep -v '#' /etc/named.conf) und drittens stehen da im wesentlichen Verweise auf Includedateien drin die du nicht mitgeschickt hast.

...

lsof sagt mir, das named nix loggt (sind nur die libs offen, sowie ports)

Warum nicht mal sowas: logging { channel log_file { file "/log/named.log" size 256M versions 10; severity info; print-time yes; print-category yes; print-severity yes; }; category default { log_file; }; category update { log_file; }; category security { log_file; }; category database { log_file; }; category config { log_file; }; category client { log_file; }; category unmatched { log_file; }; category dispatch { log_file; }; category dnssec { log_file; }; category lame-servers { log_file; }; category delegation-only { log_file; }; }; probieren?

...

[....]

...
...
...
Na ja, bisher ist nicht ersichtlich woher die Adresse stammt.

joa - und da das logging von namend irgendwie nicht hinhaut (weiß der Teufel wieso)

BIND Administrators Reference Manual lesen...

;) studiert - aber ned wirklich schlauer was das logging angeht -> entweder man nimmt (so wie ich) logging { category default { default_syslog; }; category xfer-in { default_syslog; }; category queries { default_syslog; }; category security { default_syslog; }; category lame-servers { null; }; }; oder man definiert statt dessen das jeweillige file -> Zitat Example usage of the size and versions options: channel "an_example_channel" { file "example.log" versions 3 size 20m; print-time yes; print-category yes; }; nur wie man das via default_syslog definiert, wurde auch dort nicht verraten

---> http://www.bind9.net/manual/bind/9.2.4/Bv9ARM.ch06.html#AEN1525

Da steht aber: "There are four predefined channels that are used for named's default logging as follows. How they are used is described in Section 6.2.10.2. channel "default_syslog" { syslog daemon; // send to syslog's daemon // facility severity info; // only send priority info // and higher };" mit "Section 6.2.10.2" als Verweis. ...

...

:-) na ja kompakter und einfacher ? möglich - wobei ich bind ned grade als kompliziert einstufen würde ;-)

Offenbar doch, oder?

...

ausserdem muss kompakter ned gleich besser sein ;-)

Ist es aber meistens, nämlich dann wenn die kompaktere Lösung alle Anforderungen abdeckt.

...

und ob se so stabil wie bind sind ? hmmm nicht garantiert *g* und bind dürfte auch noch in 5 jahren von den entwicklern gepflegt werden - bei anderen programmen ist das ned so sicher und bei suche nach dns-programmen für linux meldet sogar google bevorzugt bind :-) 3:0 für bind als wahl würd ich mal sagen

Aber womit hast du verglichen? Nun ja, das will ich jetzt nicht weiter diskutieren.

...

...
...
...
Und dann sicherstellen dass der named tatsächlich benutzt wird. Ich weiss nicht wirklich sicher auf welchem deiner hosts der named läuft, von welchem die Anfragen kommen, und so.

cpu1 = hauptrechner mit named + Maildienst + standard-firewall - cpu2 wird "nur" geroutet und auf nem gerouteten rechner nen dns ? unpraktisch, oder ?

Da gibt's auch andere Ansichten, und es hängt, wie üblich, stark vom Einsatzzweck ab. So wie du das skizzierst würde ich dann selber einen zentralen named betreiben wenn ich weitere Funktionalitäten brauche, z.B. lokale Auflösung mit dynamischer Änderung, oder viele lokale Hosts hätte.

Hmm 3 eigene Pcs + 5 weitere die via DCHP regelmässig "gefüttert" werden (siehe oben)

...
...
und named muss ja genutzt werden - sonst würd das inet ja ned gehen - oder ?

Nein. Nur wenn tatsächlich cpu1 als einziger resolver bei den clients eingetragen ist.

die verweisen alle auf 192.168.2.20 -> IP cpu1 /eth0 (LAN)

...
Was mir immer noch fehlt ist ein tcpdump der tatsächlich zeigt dass dein named zur Namensauflösung benutzt wird.

? tcpdump lief richtung www - zeigte also das was named mit den "echten" DNS "laberte"

Also am besten nochmal von vorne. Stelle erstmal fest welche Anfragen an den named gehen. lausche mit tcpdump auf dem Interface lo auf traffic auf port 53. Setze ein dig nach einem der rechner im Lan ab. Wenn jetzt kein korrektes Reply von dem named zu beobachten ist ist der nicht richtig konfiguriert. Dann schreibe dir z.B. manuell eine minimale named.conf. (z.B. finde ich in deiner keine lokale Zone - wie soll der also im Lan Namen auflösen?) Wenn Anfragen nach Lan-Rechner von localhost richtig beantwortet werden frage per dig nach einem externen Rechner. Du solltest eine korrekte Antwort bekommen. Wenn nicht, dann prüfe erstmal das log vom named, wenn das alles in Ordnung ist dann lausche mit tcpdump auf dem externen Interface auf DNS-Traffic wenn du per dig eine externe Adresse auflösen lässt. Wenn du das Ergebnis hast sehen wir weiter - mir ist's jetzt schon wieder zu spät ;-) Arno -- IT-Service Lehmann al@its-lehmann.de Arno Lehmann http://www.its-lehmann.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Jäger Marco

11:21

Am Samstag, 25. November 2006 01:06 schrieb Arno Lehmann: [...]

...

...
in den beispielen fand ich dazu keine info :( und warum haste nicht in meine named.conf geschaut, die klebte doch an der mail von 1:19 ;)

Erstens hab' ich oft keine Lust Attachments in Mailinglisten zu öffnen, zweitens bestand die Datei fast nur aus Kommentaren, die hättest du auch rausfiltern können (z.B. grep -v '#' /etc/named.conf) und drittens stehen da im wesentlichen Verweise auf Includedateien drin die du nicht mitgeschickt hast.

hab mir das ganze noch ma angeschaut ;) 1.) include forwarders ? da stehen nur die DNS drin die abgefragt werden - was ja auch hinhaut, sonst wär ich ja nicht online ;-) 2.) /etc/named.conf.include ist leer (0B Länge, mit Zeit+Datumsstempel des letzten reloads von named) und weitere includes gibts ned, also wurde nichts wichtiges "vergessen" (configmässig)

...

...
lsof sagt mir, das named nix loggt (sind nur die libs offen, sowie ports)

Warum nicht mal sowas:

logging { channel log_file { file "/log/named.log" size 256M versions 10; severity info; print-time yes; print-category yes; print-severity yes; }; category default { log_file; }; category update { log_file; }; category security { log_file; }; category database { log_file; }; category config { log_file; }; category client { log_file; }; category unmatched { log_file; }; category dispatch { log_file; }; category dnssec { log_file; }; category lame-servers { log_file; }; category delegation-only { log_file; }; };

probieren?

Wuah ;) manchmal kann man die Manuals lesen bis einem die Augen rausfallen und doch das ned richtig umsetzen :-/ [...]

...

Also am besten nochmal von vorne.

Stelle erstmal fest welche Anfragen an den named gehen. lausche mit tcpdump auf dem Interface lo auf traffic auf port 53.

;) hab's mal "doppelt" laufen lassen - einmal lo und parallel eth1 -> (richtige IP : 84.161.193.97) cpu1:~> ping bob-box.home.guschdel.net PING bob-box.home.guschdel.net (84.161.172.241) 56(84) bytes of data. 64 bytes from p54A1ACF1.dip0.t-ipconnect.de (84.161.172.241): icmp_seq=1 ttl=59 time=111 ms [....] 64 bytes from p54A1ACF1.dip0.t-ipconnect.de (84.161.172.241): icmp_seq=10 ttl=59 time=111 ms --- bob-box.home.guschdel.net ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9093ms rtt min/avg/max/mdev = 110.280/111.108/111.845/0.613 ms ---- cpu1:~ # tcpdump -i eth1 -vv -s 256 port 53 tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 256 bytes 0 packets captured 0 packets received by filter 0 packets dropped by kernel cpu1:~ # ---- cpu1:~ # tcpdump -i lo -vv -s 256 port 53 tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 256 bytes 0 packets captured 0 packets received by filter 0 packets dropped by kernel cpu1:~ # ---- gegentest -> ---- @cpu1:~> ping www.gmx.de PING www.gmx.de (213.165.64.215) 56(84) bytes of data. 64 bytes from www.gmx.net (213.165.64.215): icmp_seq=1 ttl=57 time=65.0 ms 64 bytes from www.gmx.net (213.165.64.215): icmp_seq=2 ttl=57 time=65.2 ms 64 bytes from www.gmx.net (213.165.64.215): icmp_seq=3 ttl=57 time=64.1 ms --- www.gmx.de ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2006ms rtt min/avg/max/mdev = 64.169/64.820/65.220/0.464 ms ---- cpu1:~ # tcpdump -i eth1 -vv -s 256 port 53 tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 256 bytes 11:07:31.635089 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 67) cpu1.linuxcobra.lan.filenet-nch > dns03.btx.dtag.de.domain: [udp sum ok] 52216+ [1au] A? www.gmx.de. ar: . OPT UDPsize=4096 (39) 11:07:31.690781 IP (tos 0x0, ttl 60, id 0, offset 0, flags [DF], proto: UDP (17), length: 83) dns03.btx.dtag.de.domain > cpu1.linuxcobra.lan.filenet-nch: [udp sum ok] 52216 q: A? www.gmx.de. 1/0/1 www.gmx.de. A www.gmx.net ar: . OPT UDPsize=4096 (55) 2 packets captured 4 packets received by filter 0 packets dropped by kernel tcpdump -i lo -vv -s 256 port 53 ---- cpu1:~ # tcpdump -i lo -vv -s 256 port 53 tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 256 bytes 11:07:31.634026 IP (tos 0x0, ttl 64, id 36801, offset 0, flags [DF], proto: UDP (17), length: 56) localhost.health-polling > localhost.domain: [udp sum ok] 10916+ A? www.gmx.de. (28) 11:07:31.692789 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 491) localhost.domain > localhost.health-polling: 10916 q: A? www.gmx.de. 1/13/13 www.gmx.de. A www.gmx.net ns: . NS f.root-servers.net., . NS g.root-servers.net., . NS h.root-servers.net., . NS i.root-servers.net., . NS j.root-servers.net., . NS k.root-servers.net., . NS l.root-servers.net., . NS m.root-servers.net., . NS a.root-servers.net., . NS b.root-servers.net., . [|domain] 2 packets captured 6 packets received by filter 0 packets dropped by kernel ---- hmmm ok mal benutzt ping named , dann wieder nicht ? *hüstelz*

...

Setze ein dig nach einem der rechner im Lan ab.

@cpu1:~> dig cpu2.linuxcobra.lan ; <<>> DiG 9.3.1 <<>> cpu2.linuxcobra.lan ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 45309 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;cpu2.linuxcobra.lan. IN A ;; AUTHORITY SECTION: . 3526 IN SOA A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2006112401 1800 900 604800 86400 ;; Query time: 5 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Nov 25 11:14:23 2006 ;; MSG SIZE rcvd: 112 ---- cpu1:~ # tcpdump -i eth1 -vv -s 256 port 53 tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 256 bytes 0 packets captured 0 packets received by filter 0 packets dropped by kernel ---- cpu1:~ # tcpdump -i lo -vv -s 256 port 53 tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 256 bytes 11:14:23.532567 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 65) localhost.qsm-gui > localhost.domain: [udp sum ok] 45309+ A? cpu2.linuxcobra.lan. (37) 11:14:23.533399 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 140) localhost.domain > localhost.qsm-gui: [udp sum ok] 45309 NXDomain q: A? cpu2.linuxcobra.lan. 0/1/0 ns: . SOA A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2006112401 1800 900 604800 86400 (112) 2 packets captured 6 packets received by filter 0 packets dropped by kernel ---- also ich würde sagen: ok - named frägt bei nem lokalen host auch "nur" lokal nach ........

...

Wenn jetzt kein korrektes Reply von dem named zu beobachten ist ist der nicht richtig konfiguriert. Dann schreibe dir z.B. manuell eine minimale named.conf. (z.B. finde ich in deiner keine lokale Zone - wie soll der also im Lan Namen auflösen?)

hmmm also named antwortet ... (und ich glaube korrekt) die lokale zone wurde doch definiert .... (so wie ich die examples & manuals verstanden hab) zone "2.168.192.in-addr.arpa" in { type master; file "master/2.168.192.in-addr.arpa.zone"; }; und in dem file sind die einzelnen rechner, die dauernd hier sind (die Gastrechner sind mir dazu zu selten da)

...

Wenn Anfragen nach Lan-Rechner von localhost richtig beantwortet werden frage per dig nach einem externen Rechner.

Du solltest eine korrekte Antwort bekommen

via dig bekomm ich von dem privaten Host die richtige IP - andere programme nicht ¿?¿ (aktuell komm ich nur auf den rechner, wenn ichs via IP mach - ne auflösung mittels ping/browser geht nicht immer, manchmal ist plötzlich nach 5 guten auflösungen wieder ne veraltete am rumspuken) bei statischen rechnern klappts zu 100%

...

Wenn nicht, dann prüfe erstmal das log vom named, wenn das alles in Ordnung ist dann lausche mit tcpdump auf dem externen Interface auf DNS-Traffic wenn du per dig eine externe Adresse auflösen lässt. Wenn du das Ergebnis hast sehen wir weiter - mir ist's jetzt schon wieder zu spät ;-)

Arno

-- IT-Service Lehmann al@its-lehmann.de Arno Lehmann http://www.its-lehmann.de

-- ICQ: 51735624 Gadu-Gadu: 4520146 AIM / Yahoo: LinuxCobra MSN: LinuxCobra@gmx.de Jabber: LinuxCobra@jabber.ccc.de http://www.linuxcobra.de PGP-Keyserver:http://wwwkeys.de.pgp.net

Jäger Marco

27 Nov 27 Nov

06:37

So.... hab mal in named.conf folgende zeilen eingefügt (gestern nachmittag) max-ncache-ttl 10800; max-cache-ttl 10800; danach -> cpu1:~ # rcnamed force-reload Reloading name server BIND server reload successful done cpu1:~ # rndc flush und es mir verkniffen, danach den dynamischen Rechner aufzurufen. ->cpu1:~> ping bob-box.home.guschdel.net PING bob-box.home.guschdel.net (84.161.172.241) 56(84) bytes of data. --- bob-box.home.guschdel.net ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3018ms ---------- cpu1:~ # tcpdump -i lo -vv -s 256 port 53 tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 256 bytes 07:12:34.626987 IP (tos 0x0, ttl 64, id 60789, offset 0, flags [DF], proto: UDP (17), length: 71) localhost.gwha > localhost.domain: [udp sum ok] 27254+ A? bob-box.home.guschdel.net. (43) 07:12:34.797006 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 87) localhost.domain > localhost.gwha: [udp sum ok] 27254 q: A? bob-box.home.guschdel.net. 1/0/0 bob-box.home.guschdel.net. A p54A1ACF1.dip0.t-ipconnect.de (59) 07:12:34.798833 IP (tos 0x0, ttl 64, id 60832, offset 0, flags [DF], proto: UDP (17), length: 73) localhost.gwha > localhost.domain: [udp sum ok] 22857+ PTR? 241.172.161.84.in-addr.arpa. (45) 07:12:34.863134 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 116) localhost.domain > localhost.gwha: [udp sum ok] 22857 q: PTR? 241.172.161.84.in-addr.arpa. 1/0/0 241.172.161.84.in-addr.arpa. PTR p54A1ACF1.dip0.t-ipconnect.de. (88) 4 packets captured 12 packets received by filter 0 packets dropped by kernel cpu1:~ # ------------- cpu1:~ # tcpdump -i eth0 -vv -s 256 port 53 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 256 bytes 0 packets captured 0 packets received by filter 0 packets dropped by kernel cpu1:~ # ------------- cpu1:~> dig bob-box.home.guschdel.net ; <<>> DiG 9.3.1 <<>> bob-box.home.guschdel.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47889 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;bob-box.home.guschdel.net. IN A ;; ANSWER SECTION: bob-box.home.guschdel.net. 300 IN A 84.161.172.241 ;; Query time: 94 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Nov 27 07:15:07 2006 ;; MSG SIZE rcvd: 59 cpu1:~ # tcpdump -i lo -vv -s 256 port 53 tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 256 bytes 07:15:07.023560 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) localhost.gwha > localhost.domain: [udp sum ok] 47889+ A? bob-box.home.guschdel.net. (43) 07:15:07.113188 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 87) localhost.domain > localhost.gwha: [udp sum ok] 47889 q: A? bob-box.home.guschdel.net. 1/0/0 bob-box.home.guschdel.net. A p54A1ACF1.dip0.t-ipconnect.de (59) 2 packets captured 6 packets received by filter 0 packets dropped by kernel cpu1:~ # cpu1:~ # tcpdump -i eth0 -vv -s 256 port 53 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 256 bytes 0 packets captured 0 packets received by filter 0 packets dropped by kernel ---------- ; <<>> DiG 9.3.1 <<>> @217.160.221.181 bob-box.home.guschdel.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14449 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;bob-box.home.guschdel.net. IN A ;; ANSWER SECTION: bob-box.home.guschdel.net. 300 IN A 84.161.160.229 ;; AUTHORITY SECTION: guschdel.net. 86400 IN NS ns.bob-net.de. guschdel.net. 86400 IN NS ns.schlund.de. ;; ADDITIONAL SECTION: ns.bob-net.de. 86400 IN A 217.160.221.181 ns.schlund.de. 75029 IN A 195.20.224.97 ;; Query time: 74 msec ;; SERVER: 217.160.221.181#53(217.160.221.181) ;; WHEN: Mon Nov 27 07:16:25 2006 ;; MSG SIZE rcvd: 143 ----------------- also soweit ich das ganze versteh, meint named, das dieser rechner zum lokalen netz gehört .... nur da ist der nirgends definiert ............. und im log dazu (komplett über obigen zeitraum) -> 27-Nov-2006 07:02:59.357 queries: client 127.0.0.1#1383: query: popmail.t-online.de IN A + 27-Nov-2006 07:12:34.627 queries: client 127.0.0.1#1383: query: bob-box.home.guschdel.net IN A + 27-Nov-2006 07:12:34.687 lame-servers: FORMERR resolving 'bob-box.home.guschdel.net/A/IN': 194.25.2.132#53 27-Nov-2006 07:12:34.799 queries: client 127.0.0.1#1383: query: 241.172.161.84.in-addr.arpa IN PTR + 27-Nov-2006 07:13:00.058 queries: client 127.0.0.1#1383: query: popmail.t-online.de IN A + 27-Nov-2006 07:15:07.024 queries: client 127.0.0.1#1383: query: bob-box.home.guschdel.net IN A + 27-Nov-2006 07:21:51.018 queries: client 127.0.0.1#1383: query: mx.freenet.de IN A + 27-Nov-2006 07:22:39.962 queries: client 127.0.0.1#1383: query: 241.172.161.84.in-addr.arpa IN PTR + 27-Nov-2006 07:22:40.034 lame-servers: FORMERR resolving '241.172.161.84.in-addr.arpa/PTR/IN': 217.5.100.185#53 27-Nov-2006 07:22:40.094 queries: client 127.0.0.1#1383: query: bob-box.home.guschdel.net IN A + 27-Nov-2006 07:22:40.154 lame-servers: FORMERR resolving 'bob-box.home.guschdel.net/A/IN': 194.25.2.133#53 27-Nov-2006 07:23:00.673 queries: client 127.0.0.1#1383: query: popmail.t-online.de IN A + sorry, aber irgendwie entzieht es sich mir, woher bind die falsche info nimmt via tcp dump wird nicht ins web gefragt -- ICQ: 51735624 Gadu-Gadu: 4520146 AIM / Yahoo: LinuxCobra MSN: LinuxCobra@gmx.de Jabber: LinuxCobra@jabber.ccc.de http://www.linuxcobra.de PGP-Keyserver:http://wwwkeys.de.pgp.net

Arno Lehmann

28 Nov 28 Nov

22:55

Hallo, On 11/27/2006 7:37 AM, Jäger Marco wrote:

...

So.... hab mal in named.conf folgende zeilen eingefügt (gestern nachmittag) max-ncache-ttl 10800; max-cache-ttl 10800; danach -> cpu1:~ # rcnamed force-reload

Warum? Ich sehe noch nicht den Zusammenhang mit dem Problem.

...

Reloading name server BIND server reload successful done cpu1:~ # rndc flush und es mir verkniffen, danach den dynamischen Rechner aufzurufen.

->cpu1:~> ping bob-box.home.guschdel.net PING bob-box.home.guschdel.net (84.161.172.241) 56(84) bytes of data.

--- bob-box.home.guschdel.net ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3018ms ---------- cpu1:~ # tcpdump -i lo -vv -s 256 port 53 tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 256 bytes 07:12:34.626987 IP (tos 0x0, ttl 64, id 60789, offset 0, flags [DF], proto: UDP (17), length: 71) localhost.gwha > localhost.domain: [udp sum ok] 27254+ A? bob-box.home.guschdel.net. (43) 07:12:34.797006 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 87) localhost.domain > localhost.gwha: [udp sum ok] 27254 q: A? bob-box.home.guschdel.net. 1/0/0 bob-box.home.guschdel.net. A p54A1ACF1.dip0.t-ipconnect.de (59) 07:12:34.798833 IP (tos 0x0, ttl 64, id 60832, offset 0, flags [DF], proto: UDP (17), length: 73) localhost.gwha > localhost.domain: [udp sum ok] 22857+ PTR? 241.172.161.84.in-addr.arpa. (45) 07:12:34.863134 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 116) localhost.domain > localhost.gwha: [udp sum ok] 22857 q: PTR? 241.172.161.84.in-addr.arpa. 1/0/0 241.172.161.84.in-addr.arpa. PTR p54A1ACF1.dip0.t-ipconnect.de. (88)

Ok, der Name wurde also aufgeöst, und das reverse mapping stimmt auch, denn es wird ja nicht der DNS-Server des dynDNS-Providers befragt.

...

4 packets captured 12 packets received by filter 0 packets dropped by kernel cpu1:~ # ------------- cpu1:~ # tcpdump -i eth0 -vv -s 256 port 53 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 256 bytes

0 packets captured 0 packets received by filter 0 packets dropped by kernel cpu1:~ # ------------- cpu1:~> dig bob-box.home.guschdel.net

; <<>> DiG 9.3.1 <<>> bob-box.home.guschdel.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47889 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION: ;bob-box.home.guschdel.net. IN A

;; ANSWER SECTION: bob-box.home.guschdel.net. 300 IN A 84.161.172.241

;; Query time: 94 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Nov 27 07:15:07 2006 ;; MSG SIZE rcvd: 59 cpu1:~ # tcpdump -i lo -vv -s 256 port 53 tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 256 bytes 07:15:07.023560 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) localhost.gwha > localhost.domain: [udp sum ok] 47889+ A? bob-box.home.guschdel.net. (43) 07:15:07.113188 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 87) localhost.domain > localhost.gwha: [udp sum ok] 47889 q: A? bob-box.home.guschdel.net. 1/0/0 bob-box.home.guschdel.net. A p54A1ACF1.dip0.t-ipconnect.de (59)

2 packets captured 6 packets received by filter 0 packets dropped by kernel cpu1:~ # cpu1:~ # tcpdump -i eth0 -vv -s 256 port 53 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 256 bytes

0 packets captured 0 packets received by filter 0 packets dropped by kernel ---------- ; <<>> DiG 9.3.1 <<>> @217.160.221.181 bob-box.home.guschdel.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14449 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION: ;bob-box.home.guschdel.net. IN A

;; ANSWER SECTION: bob-box.home.guschdel.net. 300 IN A 84.161.160.229

;; AUTHORITY SECTION: guschdel.net. 86400 IN NS ns.bob-net.de. guschdel.net. 86400 IN NS ns.schlund.de.

;; ADDITIONAL SECTION: ns.bob-net.de. 86400 IN A 217.160.221.181 ns.schlund.de. 75029 IN A 195.20.224.97

;; Query time: 74 msec ;; SERVER: 217.160.221.181#53(217.160.221.181) ;; WHEN: Mon Nov 27 07:16:25 2006 ;; MSG SIZE rcvd: 143 ----------------- also soweit ich das ganze versteh, meint named, das dieser rechner zum lokalen netz gehört

Äh, wieso? Wenn ich die obigen Ausgaben richtig verstehe gibt dein named doch eine durchaus externe Adresse zurück, nämlich eine die aus dem Pool der Telekomiker stammt. Und immerhin entsprich die Lebensdauer der Daten dem was bei einer ersten Anfrage nach einem dynDNS-Host zu erwarten ist: 300s in diesem Fall. Dass auf dem externen Interface nichts zu sehen ist wundert mich auch... wie ist denn dein Internetzugang darüber realisiert? Nicht dass da ein DSL-Modem dranhängt was per pppoe oder pptp oder sonst irgendwie getunnelt angesprochen wird...

...

.... nur da ist der nirgends definiert ............. und im log dazu (komplett über obigen zeitraum) ->

27-Nov-2006 07:02:59.357 queries: client 127.0.0.1#1383: query: popmail.t-online.de IN A + 27-Nov-2006 07:12:34.627 queries: client 127.0.0.1#1383: query: bob-box.home.guschdel.net IN A + 27-Nov-2006 07:12:34.687 lame-servers: FORMERR resolving 'bob-box.home.guschdel.net/A/IN': 194.25.2.132#53 27-Nov-2006 07:12:34.799 queries: client 127.0.0.1#1383: query: 241.172.161.84.in-addr.arpa IN PTR + 27-Nov-2006 07:13:00.058 queries: client 127.0.0.1#1383: query: popmail.t-online.de IN A + 27-Nov-2006 07:15:07.024 queries: client 127.0.0.1#1383: query: bob-box.home.guschdel.net IN A + 27-Nov-2006 07:21:51.018 queries: client 127.0.0.1#1383: query: mx.freenet.de IN A + 27-Nov-2006 07:22:39.962 queries: client 127.0.0.1#1383: query: 241.172.161.84.in-addr.arpa IN PTR + 27-Nov-2006 07:22:40.034 lame-servers: FORMERR resolving '241.172.161.84.in-addr.arpa/PTR/IN': 217.5.100.185#53 27-Nov-2006 07:22:40.094 queries: client 127.0.0.1#1383: query: bob-box.home.guschdel.net IN A + 27-Nov-2006 07:22:40.154 lame-servers: FORMERR resolving 'bob-box.home.guschdel.net/A/IN': 194.25.2.133#53 27-Nov-2006 07:23:00.673 queries: client 127.0.0.1#1383: query: popmail.t-online.de IN A +

sorry, aber irgendwie entzieht es sich mir, woher bind die falsche info nimmt via tcp dump wird nicht ins web gefragt

Ist ja erstmal egal... könnte ein Problem beim tcpdump sein, oder sonst was. Das Ergebnis sieht jedenfalls korrekt aus. Interessant finde ich die lame-server Einträge. Hier könnte evtl. ein Problem liegen, sollte aber eigentlich nicht. Außer du hast mehrere Nameserver in Benutzung und einige cachen zu lange. Aber da du ja sagts dass aller DNS-Verkehr über den bind auf CPU1 geht ist das wohl unwahrscheinlich. Zur Konrolle hab' ich das mal hier gemacht:

...

23:12:40.344628 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: 82) elf.xxxx.xxxx.de.filenet-tms > bob-net.de.domain: [bad udp cksum c0e!] 30871% [1au] A? bob-box.home.guschdel.net. ar: . OPT UDPsize=2048 (54)

; <<>> DiG 9.2.4 <<>> bob-box.home.guschdel.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58718 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION: ;bob-box.home.guschdel.net. IN A

;; ANSWER SECTION: bob-box.home.guschdel.net. 300 IN A 84.161.191.79

;; AUTHORITY SECTION: guschdel.net. 85918 IN NS ns.bob-net.de. guschdel.net. 85918 IN NS ns.schlund.de.

;; ADDITIONAL SECTION: ns.bob-net.de. 85779 IN A 217.160.221.181 ns.schlund.de. 85938 IN A 195.20.224.97

;; Query time: 31 msec ;; SERVER: 192.168.0.4#53(192.168.0.4) ;; WHEN: Tue Nov 28 23:12:40 2006 ;; MSG SIZE rcvd: 143

elf:~ # 23:12:40.370214 IP (tos 0x0, ttl 52, id 9063, offset 0, flags [DF], length: 182) bob-net.de.domain > elf.xxxx.xxxx.de.filenet-tms: [udp sum ok] 30871* q: A? bob-box.home.guschdel.net. 1/2/3 bob-box.home.guschdel.net. A 84.161.191.79 ns: guschdel.net. NS ns.schlund.de., guschdel.net. NS ns.bob-net.de. ar: ns.bob-net.de. A bob-net.de, ns.schlund.de. A ns.schlund.de, . OPT UDPsize=4096 (154)

Die Reihenfolge ist eher nur durch die Ausgabe bedingt. Interessieren würde mich nun ob die Adresse die du bekommen hast die richtige war. Ich weiss nicht 100%-ig wie bind loggt, sprich ich kann nicht sagen ob die Zeilen "resolving 'bob-box.home.guschdel.net/A/IN': 194.25.2.133#53" wirklich heißen dass der bind mit Hilfe weiterer Nameserver auflöst, aber ich vermute das. Bisher kann ich also immer noch nicht das Problem sehen, vorausgesetzt dass der Name richtig aufgelöst wurde. Lt. dem was ich sehe ist bob-box ein Rechner auf dem zumindest die folgenden Dienste laufen: 22/tcp open ssh 25/tcp open smtp (zumindest aktuell :-) 80/tcp open http (dokuWiki) 113/tcp open auth 1720/tcp filtered H.323/Q.931 5800/tcp filtered vnc-http 5900/tcp filtered vnc Wenn das der Rechner ist den du meinst kann ich zumindest sagen dass der dynDNS-Anbieter funktioniert :-) Wenn du jetzt noch einen dig/tcpdump-Output von einem nicht richtig funktionierenden Versuch hast fällt mir dazu vielleicht was ein... Arno -- IT-Service Lehmann al@its-lehmann.de Arno Lehmann http://www.its-lehmann.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Peter Wiersig

23 Nov 23 Nov

07:00

On Wed, Nov 22, 2006 at 10:03:47PM +0100, Jäger Marco wrote:

...

dachte da eher an nen debugmode für named, der die info in nen file schreibt, das ich dann erst durchforsten muss :-/

(so nach dem Motto "DNS Lookup for www.xxx.homebox.net from 192.1.1.1 was 111.222.111.222 at 22-11-2006 14:15:15"

Das ist leicht mit tcpdump zu erzeugen. Die bind eigenen Logging Methoden habe ich selbst nie hochgeschraubt. Peter -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

6360

Age (days ago)

6366

Last active (days ago)

List overview

Download

19 comments

5 participants

participants (5)

Arno Lehmann
David Haller
Jäger Marco
Martin Schröder
Peter Wiersig