DHCP + Bind: 'name not in use' prerequisite not satisfied (YXDOMAIN)
Peter Mairhofer
Ich habe zu dynamischen DNS Updates mittels DHCP3 und Bind9 nun eine
weitere Frage. Folgende Meldungen treten auch bei ganz legitimen Clients
auf, die eine echte dynamische Lease haben und wo sich die MAC Adresse
*nicht* ï¿œndert:
Aug 25 03:49:14 intra named[17032]: client 192.168.0.1#49678: updating
zone 'dyn.local/IN': update unsuccessful: Acer.dyn.local: 'name not in
use' prerequisite not satisfied (YXDOMAIN)
Aug 25 03:49:20 intra named[17032]: client 192.168.0.1#47775: updating
zone 'dyn.local/IN': update unsuccessful: Acer.dyn.local: 'name not in
use' prerequisite not satisfied (YXDOMAIN)
Ist das nun eine Fehlermeldung oder kann das getrost ignoriert werden?
Falls ja, gibt es eine Mï¿œglichkeit das ï¿œberhaupt abzustellen? (Nachdem
die Meldungen ja wirklich oft kommen, jedesmal wenn sich irgendein
Client einschaltet)
Bemerkenswert vielleicht bei meiner Config: Ich habe reverse und forward
Eintrï¿œge in einer Zone. In der "echten" reverse Zone verwende ich dazu
einfach Classless in-addr.arpa delegation um die reverse Eintrï¿œge
ebenfalls auf die forward Zone (dyn.local) zu delegieren:
$GENERATE 201-254 $ IN CNAME $.0.168.192.dyn.local.
Und das ist damit die dhcp3.conf:
ddns-update-style interim;
ddns-domainname "dyn.local";
ddns-rev-domainname "dyn.local.";
update-static-leases true;
key DHCP_UPDATER {
algorithm HMAC-MD5.SIG-ALG.REG.INT;
secret XXXXXXXXXXXXXXXXXXXXXX==;
};
zone dyn.local. {
primary 192.168.0.1;
key DHCP_UPDATER;
}
Besten Dank!
LG,
Peter
Juergen P. Meier
> Ich habe zu dynamischen DNS Updates mittels DHCP3 und Bind9 nun eine
> weitere Frage. Folgende Meldungen treten auch bei ganz legitimen Clients
> auf, die eine echte dynamische Lease haben und wo sich die MAC Adresse
> *nicht* ï¿œndert:
>
> Aug 25 03:49:14 intra named[17032]: client 192.168.0.1#49678: updating
> zone 'dyn.local/IN': update unsuccessful: Acer.dyn.local: 'name not in
> use' prerequisite not satisfied (YXDOMAIN)
> Aug 25 03:49:20 intra named[17032]: client 192.168.0.1#47775: updating
> zone 'dyn.local/IN': update unsuccessful: Acer.dyn.local: 'name not in
> use' prerequisite not satisfied (YXDOMAIN)
Wie sieht die Zone aus (aktueller Dump) und wie die DHCP dns-update
config dazu?
> Ist das nun eine Fehlermeldung oder kann das getrost ignoriert werden?
> Falls ja, gibt es eine Mï¿œglichkeit das ï¿œberhaupt abzustellen? (Nachdem
> die Meldungen ja wirklich oft kommen, jedesmal wenn sich irgendein
> Client einschaltet)
Es werden keine Updates durchgefuehrt, weil die zu updatenden Namen
bereits belegt sind.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Peter Mairhofer
Danke fï¿œr deine Antwort!
Juergen P. Meier schrieb:
> Peter Mairhofer <6383...@gmx.net>:
>> Ich habe zu dynamischen DNS Updates mittels DHCP3 und Bind9 nun eine
>> weitere Frage. Folgende Meldungen treten auch bei ganz legitimen Clients
>> auf, die eine echte dynamische Lease haben und wo sich die MAC Adresse
>> *nicht* ï¿œndert:
>>
>> Aug 25 03:49:14 intra named[17032]: client 192.168.0.1#49678: updating
>> zone 'dyn.local/IN': update unsuccessful: Acer.dyn.local: 'name not in
>> use' prerequisite not satisfied (YXDOMAIN)
>> Aug 25 03:49:20 intra named[17032]: client 192.168.0.1#47775: updating
>> zone 'dyn.local/IN': update unsuccessful: Acer.dyn.local: 'name not in
>> use' prerequisite not satisfied (YXDOMAIN)
>
> Wie sieht die Zone aus (aktueller Dump)
Du meinst mit rdnc dumpdb -zones ?
;
; Zone dump of 'dyn.local/IN'
;
dyn.intra.nobaq.net. 1800 IN SOA intra.lan.local.
hostmaster.intra. 2007095211 3600 1800 604800 1800
dyn.intra. 1800 IN NS intra.lan.local.
201.0.168.192.dyn.local. 21600 IN PTR grml.dyn.local.
208.0.168.192.dyn.local. 302400 IN PTR Acer.dyn.local.
217.0.168.192.dyn.local. 302400 IN PTR client1.dyn.local.
219.0.168.192.dyn.local. 302400 IN PTR client2.dyn.local.
248.0.168.192.dyn.local. 302400 IN PTR Acer.dyn.local.
Acer.dyn.local. 302400 IN A 192.168.0.208
Acer.dyn.local. 302400 IN TXT
"31ed2befc4bba6e06967d252cb0e0c1f8d"
grml.dyn.local. 21600 IN A 192.168.0.201
grml.dyn.local. 21600 IN TXT
"0024ff00e59bc0c886667e411315c2bde6"
client1.dyn.local. 302400 IN A 192.168.0.217
client1.dyn.local. 302400 IN TXT
"31074554fbe5f8f9e9aa02c46be532eb3c"
client2.dyn.local. 302400 IN A 192.168.0.219
client2.dyn.local. 302400 IN TXT
"6f9c718be8ee9b40e05aa79ed96631eb6c"
Dazu ist zu sagen:
* Die Meldung scheint bei jedem Client aufzutreten und zwar nach dem
zweiten Mal
* "client1" ist der Name des Rechners mit unterschiedlicher MAC (siehe
<h6jqdb$m4a$1...@news.albasani.net>). Zusï¿œtzlich matcht "grml" darauf,
weil davon vor kurzem mit einer grml Boot-CD gebootet wurde.
> und wie die DHCP dns-update config dazu?
Siehe OP:
ddns-update-style interim;
ddns-domainname "dyn.local";
ddns-rev-domainname "dyn.local.";
update-static-leases true;
key DHCP_UPDATER {
algorithm HMAC-MD5.SIG-ALG.REG.INT;
secret XXXXXXXXXXXXXXXXXXXXXX==;
};
zone dyn.local. {
primary 192.168.0.1;
key DHCP_UPDATER;
}
> [...]
> Es werden keine Updates durchgefuehrt, weil die zu updatenden Namen
> bereits belegt sind.
Ja, aber das werden sie ja zwangslï¿œufig sein, wenn es kein DHCP Release
gibt oder?
Wenn ich die DHCP manpage richtig verstanden habe, dann wird der Eintrag
in so einem Fall ersetzt, vorrausgesetzt es existiert ein TXT Eintrag
dessen Hash auf die passende MAC matcht. Und das sollte eigentlich bei
allen Clients der Fall sein (ausser client1 wie gesagt).
LG,
Peter
Juergen Ilse
Peter Mairhofer <6383...@gmx.net> wrote:
> ;
> ; Zone dump of 'dyn.local/IN'
> ;
Wenn dein System "zeroconf" unterstuetzt, solltest du tunlichst auf
".local" (und Subdomains davon) als lokale authoritative Zone fuer
deinen bind verzichten ...
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Peter Mairhofer
> Hallo,
>
> Peter Mairhofer <6383...@gmx.net> wrote:
>> ;
>> ; Zone dump of 'dyn.local/IN'
>> ;
>
> Wenn dein System "zeroconf" unterstuetzt, solltest du tunlichst auf
> ".local" (und Subdomains davon) als lokale authoritative Zone fuer
> deinen bind verzichten ...
Ich weiss, habe ich aber ï¿œberall deaktiviert. Werd aber bei Gelegenheit
eh auf einen anderen Namen umsteigen.
LG,
Peter