Hallo Werner, Am 06/12/2015 um 11:14 AM schrieb Werner Flamme:
Werner Franke [12.06.2015 10:04]:
[...]
vielen Dank für Deine Antwort. options timeout:1 options attempts:4
und beide auf 1 setzen? ok
brachten keine Änderung. dig @10.130.0.6 testrechner liefert ; <<>> DiG 9.8.1-P1 <<>> @10.130.0.6 testrechner ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37444 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 .... ;; Query time: 1301 msec ;; SERVER: 10.130.0.6#53(10.130.0.6) ;; WHEN: Fri Jun 12 07:32:57 2015 ;; MSG SIZE rcvd: 101
Also scheint der 2. DNS Server zu antworten, wenn man ihn direkt anspricht.
Ja, aber gibt er auch die richtige Adresse aus? Genau die Zeile hast Du ja aus Sicherheizgründen gelöscht :) QUERY: 1 -> Anfrage nach einer Adresse; AUTHORITY: 1 -> der Server ist echter Nameserver für das Netz; ANSWER: 0 -> oje... Auch NXDOMAIN zeigt eigentlich, dass er die Antwort nicht kennt. Stimmt, kennt er nicht. Ich habe den update Mechanismus der beiden DNS noch nicht verstanden, aber in der named.conf steht (als beispiel):
Primare Server: zone "vlab.alu" { type master; allow-transfer { 10.130.0.6; }; allow-update { key "ddns-update"; }; file "/var/named/data/vlab.alu.db"; }; Secondary : zone "vlab.alu" { type slave; masters { 10.130.0.5; }; file "/var/named/slaves/vlab.alu.db"; }; Und in den Files in /var/named/slaves findet sind keine Zeile mit "testrechner". Also scheint der Update Mechanismus nicht zu funktionieren.
Wie sich 2 Bind-DNS-Server abgleichen, ist auf sehr vielen Webseiten beschrieben (Zone Transfer). Dazu kann ich auch nichts sagen, ich benutze Bind nicht. Ich weiß nur, dass inzwischen auch Bind und DHCP zusammenarbeiten sollen (zumindest, wenn es sich um die ISC-Versionen handelt).
OK, das muss ich mir also nochmal zu Gemüte führen
Meine ganzen Versuche finden in einer VMware Umgebung in einem Sandbox Netzwerk statt. eth0 ist mit dem ALU Netzwerk verbunden, eth1 (oder eno33557248) ist mit einem virtuellen Switch verbunden, damit ich mit meinen Versuchen die produktive Umgebung in VMware nicht störe.
Die Umgebung ist erst mal irrelevant. Auch wenn wir für Testsysteme einen eigenen Host mit völlig separaten Netzen haben.
Ich habe ein reichliches Dutzend VMs, die jeweils 3 Nameserver eingetragen haben, und bei allen klappt die Umschaltung. Allerdings habe ich auch auf allen VMs den DNSmasq installiert, der sich darum kümmert :)
An dem Sandbox-Switch sind die beiden DHCP/DNS Server und zwei weitere virtuelle Hosts, die die Testrechner spielen sollen, verbunden.
Als Gateway für eno33557248 habe ich den primären DHCP/DNS Server eingetragen. Somit kommt auf einem Testrechner bei route: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 10.130.0.5 0.0.0.0 UG 100 0 0 eth0 10.130.0.0 * 255.255.0.0 U 0 0 0 eth0 Der 10.130.0.5 ist jedoch down. Allerdings ein "ping 10.130.0.6" funktioniert. Und "ping 10.130.4.20"/"ping 10.130.7.138" (das sind die beiden Testrechner) auch.
Ja, bei den Netzmasken brauchst Du ja für 10.130.x.y kein Gateway, das geht direkt an die Hosts.
OK
Könnte das ein Problem bei mir sein ? Darf man einen DHCP/DNS Server nicht auch noch als Gateway eintragen ?
Doch, darf man. Wenn das Gateway down ist, kommst Du halt aus dem Bereich 10.130.0.0/16 nicht raus. Das ist unabhängig von weiteren Funktionen des Gateway-Rechners.
OK
Sorry, ich bin wirklich nicht 'familiar' mit der ganzen Sache. Dürfte aus meinen Postings auch deutlich herauszulesen sein. Und einen Admin kann ich nicht fragen.
Die meisten haben mal klein angefangen ;) Das ist nur bei manchen so lange her, dass sie sich nicht mehr erinnern :)
Na mich stört da nur, dass man die IT Spezialisten nicht fragen kann/darf, weil IT.
Gibt es für DHCP/DNS auch so was wie traceroute ? traceroute liefert ja die Netzwerke, die nacheinander benutzt werden.
Was willst Du da erkennen? Da ein Gateway nicht benötigt wird, wird der angepingte Host auch der nächste Hop sein.
Nein, so was wie dnsask testrechner check /etc/resolv.conf of localhost ask first nameserver: 10.130.0.5 - no answer... ask second nameserver: 10.130.0.6 - ??? oder so, so dass man nachvollziehen kann warum wer wie gefragt wird und was der als Antwort gibt.
DHCP scheint übrigens zu funktionieren. Zumindest interpretiere ich die Meldungen von ondnbdns02 (10.130.0.6) in "/var/log/messages" so:
DHCP funktioniert zweifellos, sonst hätte Dein Client ja keine IP-Adresse :)
Die hatte er schon vor dem runterfahren des ersten DHCP/DNS Servers. Das bringt mich auf die Idee, falls die aktuellen Probleme behoben sind, auch mal einen neuen virt. Host zu machen und zu schauen ob der eine IP bekommt. Gruss Werner -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org