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