dyn DNS update erzwingen / beschleunigen

[bongout]

Hi Forum,

kleines Problem...

wenn meine DHCP Clients (wie's leider immer wieder vorkommt) abschmieren und neu starten kommt es vor, dass mein DNS nicht "sofort" aktualisiert wird.

Kann ich den update beschleunigen / erzwingen?

[SubOptimal]

Hi bongout,

wenn Du mal etwas genauer beschreiben würdest was eigentlich genau Dein Problem ist, dann hilft Dir sicher auch jemand. Aber so stellt sich nur die Frage: Was haben Deine DHCP-Clients mit DynDNS zu tun?

SubOptimal

[bongout]

Hi,

und danke für den Tipp - sorry... war zu undeutlich!

Also: es ist ein BIND9 DNS und DHCP3 mit dynamischem update.

Wie erwähnt hab ich regelmäßig Probleme, wenn meine Clients "abschmieren" und dann wieder hochfahren.

Durch die Meldung

Code: Alles auswählen

 no such RRset

sind meine Hosts dann nictt mehr erreichbar....

Wie könnte ich das wohl ändern

[KBDCALLS]

Wenn der ddclient im Daemon Mode läuft werd die IPS alles 300 Sekunden aktualisiert. Die Zeit kann man aber runtersetzen.

Code: Alles auswählen

 /etc/default/ddclient 

Was hat DHCP damit zu tun ?

[herrchen]

Wie könnte ich das wohl ändern

wer macht denn das update?
wenn du das den DHCP-server machen lässt, müsste der das doch bei jeder IP, die er rausrückt sofort machen.
gibt es einträge im "syslog" des servers?

herrchen

[SubOptimal]

Hi,

Also: es ist ein BIND9 DNS und DHCP3 mit dynamischem update.

Wie erwähnt hab ich regelmäßig Probleme, wenn meine Clients "abschmieren" und dann wieder hochfahren.
Durch die Meldung

Code: Alles auswählen

 no such RRset

sind meine Hosts dann nictt mehr erreichbar....
Wie könnte ich das wohl ändern

Vielleicht mal die komplette Meldung aus dem syslog hier posten? Mit den spärlichen Angaben konnte ich zumindest das hier finden.

SubOptimal

PS: Wenn Französisch nicht zu Deinem Sprachschatz gehört, die Seite einfach durch ${OnlineTranslator} übersetzen lassen.

[bongout]

HI Leute,

nochmal danke, danke, danke... gestern hab' ich mich nicht sonderlich geschickt hier angestellt:

Deshalb heute vielleicht etwas besser:

Code: Alles auswählen

Jun 27 13:17:11 pia dhcpd: DHCPOFFER on 192.168.2.232 to aa:00:00:29:ea:c0 (demo) via eth1
Jun 27 13:17:13 pia dhcpd: Can't update forward map demo.pub.domain.de. to 192.168.2.232: no such RRset
Jun 27 13:17:13 pia dhcpd: DHCPREQUEST for 192.168.2.232 (192.168.2.2) from aa:00:00:29:ea:c0 (demo) via eth1
Jun 27 13:17:13 pia dhcpd: DHCPACK on 192.168.2.232 to aa:00:00:29:ea:c0 (demo) via eth1

ist mein syslog auf dem DHCP/ DNS Server. Die DHCP Client conf ist minimal

Code: Alles auswählen

send host-name "demo";

Die DHCP3 Server config:

Code: Alles auswählen

# DHCP Deamon configuration file

authoritative;

max-lease-time 86400;
default-lease-time 14400;
ddns-update-style interim;
ddns-ttl 1800;

subnet 192.168.2.0 netmask 255.255.255.0 {
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.2.255;

# don't let clients modify their own records
# ignore client-updates;

# dynamic DNS updates
ddns-updates on;
ddns-update-style interim;
ddns-domainname "pub.domain.de.";
ddns-rev-domainname "in-addr.arpa.";

option domain-name "pub.domain.de";
option domain-name-servers 192.168.2.2;
option routers 192.168.2.1;

range 192.168.2.11 192.168.2.254;

key "PUB" {
algorithm hmac-md5;
        secret
        "key"
        };

zone pub.domain.de {
        primary 192.168.2.2;
        key "PUB";
        }

zone 2.168.192.in-addr.arpa {
        primary 192.168.2.2;
        key "key";
        }

Ich frage mich, woher

Code: Alles auswählen

bound to 192.168.2.225 -- renewal in 7200 seconds

beim booten meines Client kommt.... denn danach scheint alles in Ordnung zu sein - aber ich will halt keine zwei Stunden warten, wenn was schiefgeht....

[KBDCALLS]

Wo liegt das Problem?

Er kriegt doch ne Bestätigung

Code: Alles auswählen

Jun 27 13:17:13 pia dhcpd: DHCPACK on 192.168.2.232 to aa:00:00:29:ea:c0 (demo) via eth1

ACK=acknowledge=Bestätigung/Empfang

Auch wird, wenn möglich die gleiche Adresse vergeben.

Code: Alles auswählen

bound to 192.168.2.225 -- renewal in 7200 seconds  

Das steht in der Config des DHCP servers.

[bongout]

naja...

das Problem ist konkret, dass nach dem reboot (bei dem anscheinend auch immer eine neue IP vergeben wird) der DNS nicht sofort die Info über die neue IP bekommt und erst nach geraumer Zeit die richtige IP (=neue) auflöst...

Eigentlich sollte doch immer wenn der DHCP eine IP vergibt (egal ob alt oder neu) SOFORT ein DNS update stattfinden

[KBDCALLS]

Teste doch mal ob wirklich eine neue Adresse vergeben wird?

[bongout]

wird... immer wieder neu...

und meine named.log sagt dann:

Code: Alles auswählen

Jun 28 07:18:50.194 update: info: client 192.168.2.2#1025: updating zone 'pub.domain.de/IN': update failed: 'name not in use' prerequisite not satisfied (YXDOMAIN)
Jun 28 07:18:50.195 update: info: client 192.168.2.2#1025: updating zone 'pub.domain.de/IN': update failed: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)
Jun 28 07:48:53.545 update: info: client 192.168.2.2#1025: updating zone 'pub.domain.de/IN': update failed: 'name not in use' prerequisite not satisfied (YXDOMAIN)
Jun 28 07:48:53.545 update: info: client 192.168.2.2#1025: updating zone 'pub.domain.de/IN': update failed: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)

[KBDCALLS]

Vergleiche doch mal die IP vor dem Booten und danach.

[bongout]

Ich glaube ich hab' die Ursache meines Problem - wenngleich mir die Lösung noch fehlt.

Meine Clients sind virtuelle XEN hosts - und bekamen bei jedem reboot eine neue MAC Adresse. Das mochte mein DHCP wohl nicht.

Hab' jetzt statische MAC Adressen vergeben und siehe da - es funktioniert

Aber dennoch muss es doch irgendwie möglich sein, selbst wenn der Client eine neue MAC Adresse bekommt, dass DHCP / DNS sauber arbeiten... oder?

[herrchen]

Code: Alles auswählen

zone 2.168.192.in-addr.arpa {
        primary 192.168.2.2;
        key "key";
        }

steht hier wirklich "key "key"" und nicht "key "PUB""?

herrchen

[bongout]

steht hier wirklich "key "key"" und nicht "key "PUB""?

sorry - rumgebastelt - da steht natürlich "PUB"

[KBDCALLS]

Ich glaube ich hab' die Ursache meines Problem - wenngleich mir die Lösung noch fehlt.

Meine Clients sind virtuelle XEN hosts - und bekamen bei jedem reboot eine neue MAC Adresse. Das mochte mein DHCP wohl nicht.

Das ist natürlich klar , wenn ständig die Mac Adresse geändert wird dann kann logischerweise, auch der DHCPserver nicht wissen das ers mit dem gleichen Rechner zu tun hat, und vergibt dann ne andere IP.

[bongout]

hmm.. ok...

aber wie kann ich nun meinem DNS erklären , dass obgleich neue MAC mit neuer IP der gleiche Name dahinter steckt... oder geht das schlicht nicht?

[Hendri]

Hallo,
dann gib deinen XEN Guests einfach eine fixe MAC und das Problem ist behoben.

In deiner Xen Config vom Guest folgendes hinein nehmen:

Code: Alles auswählen

vif = [ 'mac=FF:FF:FF:FF:FF:FF, bridge=br0, ip="0.0.0.0/32"' ]

Hier ein Auszug aus dem MAC Address Artikel von Wikipedia:
Locally Administered addresses are assigned by the network administrator instead of the hardware vendor. Locally Administered addresses have the second bit of their first octet set to one (value 02 in printed format.)

[bongout]

Hi Hendri,

hmm - danke.. das hab' ich dann auch so gemacht.

Das dumm eist nur, dass ich noch kein scribbel gefunden hab, wie ich mir die MAC Adressen dynamisch erzeugen könnte...

OK - ich hab' jetzt auch nich mehr intensiev gesucht. Aber wenn jemand was weiß

Gruß