Re: dhcpd liefert mir 1 DNS-Server zuviel
On Mon, 19 Sep 2005, Andreas Pakulat wrote:
> > zuerst muß mal der bind9 einen dynamischen Update hinbekommen. Und das
> > scheint im Augenblick noch fehlzuschlagen.
> Nö das geht jetzt eigentlich, hatte ich wohl nicht deutlich genug
> geschrieben.
Nein - ich hätte es - eingeschaltetes Hirn, ausgeschlafenen Körper und
aufgesetzter Brille beim Lesen vorausgesetzt - auch verstehen können.
Meine Schuld. Was muss ich auch zu nachtschlafender Zeit posten. :-)
Aber wenn der Bind nun sauber die Updates und Deletes mittels nsupdate
macht, dann kann man auch mal wagen, die dhcpd.conf anzupassen. Die eine
Teilkomponente vom ddns läuft ja nun bei Dir. Glückwunsch :-)
Die conf vom dhcpd3 sieht hier so aus:
dfw1:/etc/dhcp3# cat dhcpd.conf
# dhcpd.conf
#
# Sample configuration file for ISC dhcpd
#
# option definitions common to all supported networks...
option domain-name "so.antepoth.de";
option domain-name-servers fw1.so.antepoth.de;
default-lease-time 600;
max-lease-time 7200;
# if you want to use dynamical DNS updates, you should first read
# read /usr/share/doc/packages/dhcp-server/DDNS-howto.txt
ddns-update-style interim;
ddns-updates on;
# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;
# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;
subnet 192.168.186.0 netmask 255.255.255.0 {
range 192.168.186.1 192.168.186.190;
option routers 192.168.186.254;
option broadcast-address 192.168.186.255;
host sofa {
fixed-address 192.168.186.199;
hardware ethernet 00:30:84:0B:03:70;
}
# Solaris Maschine
host ssofa {
fixed-address 192.168.186.193;
hardware ethernet 00:0C:29:95:ED:FB;
}
}
Mehr ist da nicht zu finden - und mehr braucht es auch nur in
Ausnahmefällen (s.u.). Bitte beachten: Die Maschinen, die mit der "host"
Direktive eingebunden sind, müssen "von Hand" im DNS eingetragen werden.
Für diese Maschinen findet kein automatisches Update statt.
Bitte beachten: Es handelt sich hierbei um den dhcpd3 - der hat dann auch
so Niftigkeiten wie dhcp-failover und die dnsupdate.pl Scripte braucht man
da nicht oder nur, wenn der dhcpd3 etwas zaghaft mit den prereq umgeht und
dadurch Inkonsistenzen zwischen aktiven Rechnern und DNS-Einträgen
auftreten. So kann es z.B. passieren, daß ein bereits vorhandenes
Reverse-Resolving das komplette Update verhindert. Dafür sind dann die
ddns-Scripte wie geschaffen.
> Wie gesagt nsupdate funktioniert, nur der dhcpd macht das nicht. Ich hab
> noch die "Option" primary X.Y.Z.T gefunden für dhcpd aber bewirkt hat
> das auch noch nichts. Irgendwie ist der dhcpd auch nicht sehr gesprächig
> bzgl. logfiles...
primary ? Habe ich hier nicht, da antepoth.de hier im LAN auch die
Subdomain .so sauber an einen NS-Eintrag delegiert. Möglicherweise
verhindert die fehlende Delegation von .apaku seitens dyndns.org das
Update vom dhcp. Du wirst es an den PREREQ im Dump merken.
Die Gesprächigkeit ist aber dennoch gegeben: Denn die Meldungen sehen hier
in der messages so aus, wenn eine Windows-Maschine bootet:
Sep 21 06:51:10 dfw1 dhcpd: DHCPDISCOVER from 00:0c:29:a2:2a:ab via eth0
Huch? Da darf der dhcp nicht nach innen pingen?
Muss ich noch gleich ändern.
Sep 21 06:51:10 dfw1 kernel: Shorewall:all2all:REJECT:IN= OUT=eth0 SRC=192.168.186.254 DST=192.168.186.189 LEN =48 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=26839 SEQ=0
Done!
#
# PING erlauben
#
ACCEPT loc net icmp 8
# Fuer den DHCP-Server zum Feststellen ob eine IP bereits belegt ist.
ACCEPT $FW loc icmp 8
Weiter im Log.
Sep 21 06:51:11 dfw1 dhcpd: DHCPOFFER on 192.168.186.189 to 00:0c:29:a2:2a:ab (wixp) via eth0
Sep 21 06:51:11 dfw1 dhcpd: Added new forward map from wixp.so.antepoth.de to 192.168.186.189
Sep 21 06:51:11 dfw1 dhcpd: added reverse map from 189.186.168.192.in-addr.arpa. to wixp.so.antepoth.de
Sep 21 06:51:11 dfw1 dhcpd: Wrote 0 deleted host decls to leases file.
Sep 21 06:51:11 dfw1 dhcpd: Wrote 0 new dynamic host decls to leases file.
Sep 21 06:51:11 dfw1 dhcpd: Wrote 21 leases to leases file.
Sep 21 06:51:11 dfw1 dhcpd: DHCPREQUEST for 192.168.186.189 (192.168.186.254) from 00:0c:29:a2:2a:ab (wixp) via eth0
Sep 21 06:51:11 dfw1 dhcpd: DHCPACK on 192.168.186.189 to 00:0c:29:a2:2a:ab (wixp) via eth0
Der Named meint in der daemon.log dann noch:
Sep 21 06:51:11 dfw1 named[27935]: client 192.168.186.254#1053: updating zone 'so.antepoth.de/IN': adding an RR
Sep 21 06:51:11 dfw1 named[27935]: client 192.168.186.254#1053: updating zone 'so.antepoth.de/IN': adding an RR
Sep 21 06:51:11 dfw1 named[27935]: client 192.168.186.254#1053: updating zone '186.168.192.in-addr.arpa/IN': deleting an rrset
Sep 21 06:51:11 dfw1 named[27935]: client 192.168.186.254#1053: updating zone '186.168.192.in-addr.arpa/IN': adding an RR
und das wars. Mehr braucht's eigentlich nicht an Meldungen.
Der Test mit dem nslookup zeigt auch:
t_antepoth@sofa:~> nslookup wixp
Server: 192.168.186.254
Address: 192.168.186.254#53
Name: wixp.so.antepoth.de
Address: 192.168.186.189
t_antepoth@sofa:~> nslookup 192.168.186.189
Server: 192.168.186.254
Address: 192.168.186.254#53
189.186.168.192.in-addr.arpa name = wixp.so.antepoth.de.
t_antepoth@sofa:~>
Und so sieht das dann aus, wenn man dem Rechner mittels
"ipconfig /release"
die IP klaut:
Sep 21 07:09:07 dfw1 dhcpd: if wixp.so.antepoth.de IN TXT "31286f2c489d0cd1bedaf1f3462b3376a1" rrset exists and wixp.so.antepoth.de IN A 192.168.186.189 rrset exists delete wixp.so.antepoth.de IN A 192.168.186.189: success.
Sep 21 07:09:07 dfw1 dhcpd: if wixp.so.antepoth.de IN A rrset doesn't exist delete wixp.so.antepoth.de IN TXT "31286f2c489d0cd1bedaf1f3462b3376a1": success.
Sep 21 07:09:07 dfw1 dhcpd: removed reverse map on 189.186.168.192.in-addr.arpa.
Man sieht den Update der Forward und Reverse-Zone und alles ist gut.
Interessanterweise fehlt das Löschen beim Herunterfahren des Rechners. Auf
diese Weise behält eine Windei-Maschine die alte IP bei einem
Subnet-Wechsel zuerst einmal - auch wenn der dhcpd etwas anderes
behauptet. Nett zu wissen!
> > Oh - da habe ich mich mistverständlich ausgedrückt. dyndns.org wird mit
> > sicherheit keine Zone-Updates mittels den bindutils zulassen sondern hat
> > ein eigenes Interface.
> Ja haben sie. Dann verstehe ich nicht so recht was du meinst?
dyndns.org "weiß" nichts von der Subdomain apaku und daß die an einen
internen DNS delegiert werden soll. Entsprechend war auch mein
Anfangsverdacht, daß der nsupdate zuerst den NS für dyndns.org holt, dort
dann feststellt, daß es für .apaku keine Delegation gibt und anschließend
alle weiteren Aktionen vermeidet.
Das würde ich jetzt an deiner Stelle nachprüfen, indem ich mittels
tcpdump -s0 -w blah.dmp -i DEININTERFACE port 53
mir mal den mitgesnifften Netzwerktraffic zum Thema DNS in der
blah.dmp anschaue. Dort tauchen die dann mittlerweile bekannten Befehle
zum NSUPDATE auf. Wenn die dort nicht auftauchen, sniffst Du am falschen
Interface oder Du hast dann die Fehlerursache gefunden (bind lauscht am
falschen Interface und nimmt dort keine Updates entgegen).
> Mein DNS ist nur für intern gedacht, der lauscht nicht am externen
> Interface und leitet alle nicht-lokal auflösbaren Anfragen an die
> "richtigen" DNS-Server der Uni weiter (mittels forwarders festgelegt).
Das funktioniert ja auch mittlerweile - was mich aber dennoch
überrascht...(s.o. Thema: Fehlende Delegation von .apaku) :-)
> Ich will ja die blah.apaku.dnsalias.de Einträge gar nirgendwo
> registrieren, die will ich nur im LAN per DNS-Server statt per
> /etc/hosts auflösen können.
Weiß ich - ist auch wirklich keine Raketenwissenschaft und funktioniert
auch wirklich gut mit Debian ... :-)
Wirklich lustig wird es dann allerdings mit dhcp-failover. Denn i.d.R. ist
der DNS und DHCP eine Maschine. DHCP kann nur den DNS-Master updaten. Wie
macht man nun ein DNS-Failover mit DDNS? Kann man zwei Master-NS für ein
und die selbe Zone haben? Zonefiles via NFS?
Da fangen dann die wirklichen Fragen an... ;-)
t++
Reply to: