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