expertenaustausch > linux.debian.user.german

Andreas Pakulat (19.09.2005, 17:20)
On 16.09.05 22:22:26, Andreas Pakulat wrote:
> On 16.09.05 19:25:19, Thomas Antepoth wrote:
> > Aber wenn Du gerade dabei bist, mach' doch eben noch auch jeweils einen:

> Bin momentan bei meinen Eltern und erst Sonntag abend wieder in der
> Wohnung, ich meld mich dann mit den entsprechenden Ausgaben nochmal.
> > dig 1.168.192.in-addr.arpa ns
> > dig 2.168.192.in-addr.arpa ns


Da:
andreas@neo:~>dig 2.168.192.in-addr.arpa ns

; <<>> DiG 9.2.4 <<>> 2.168.192.in-addr.arpa ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24797
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;2.168.192.in-addr.arpa. IN NS

;; AUTHORITY SECTION:
168.192.in-addr.arpa. 86400 IN SOA neo.apaku.dnsalias.org. root.neo.apaku.dnsalias.org. 11 28800 7200 2419200 86400

;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Sep 19 17:06:31 2005
;; MSG SIZE rcvd: 103

andreas@neo:~>dig 1.168.192.in-addr.arpa ns

; <<>> DiG 9.2.4 <<>> 1.168.192.in-addr.arpa ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5280
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;1.168.192.in-addr.arpa. IN NS

;; AUTHORITY SECTION:
168.192.in-addr.arpa. 86400 IN SOA neo.apaku.dnsalias.org. root.neo.apaku.dnsalias.org. 11 28800 7200 2419200 86400

;; Query time: 5 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Sep 19 17:06:33 2005
;; MSG SIZE rcvd: 103

Sollte da nicht ne ANSWER Section mit meinem Nameserver sein? Oder ist
hier die AUTHORITY Section ausreichend?

Ahh, mir daemmerts, ich hab ja nur ne Zonendefinition für 192.168
gemacht, damit ich mir was spare... Muss ich also für beide Subnetze
eigene Zonefiles anlegen ja?

> Nein, ich hab nur meine Lan-Zone und die fuer die Root-Server (aber als
> .... aehm, wie heisst das... faellt mir grad nicht ein, also nicht
> "master"). forwarders habe ich momentan auch nicht, weil ich ja ein
> paar Probleme hatte (siehe anderen Thread mit dhcpd) und dachte erst es
> wuerde daran liegen.
> Ich vermute (aber genau sagen kann ichs erst Sonntag) dass ich bei
> obigem dig den ns1.dyndns.org zurueckbekomme...


So, genau siehts so aus:
root@neo:~>dig dnsalias.org ns

; <<>> DiG 9.2.4 <<>> dnsalias.org ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64184
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;dnsalias.org. IN NS

;; ANSWER SECTION:
dnsalias.org. 85777 IN NS ns1.dyndns.org.
dnsalias.org. 85777 IN NS ns2.dyndns.org.
dnsalias.org. 85777 IN NS ns3.dyndns.org.
dnsalias.org. 85777 IN NS ns4.dyndns.org.
dnsalias.org. 85777 IN NS ns5.dyndns.org.

;; ADDITIONAL SECTION:
ns1.dyndns.org. 65844 IN A 63.208.196.90

;; Query time: 5 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Sep 19 17:12:01 2005
;; MSG SIZE rcvd: 143

> Naja, die werden im Round-Robin-Prinzip ausgegeben. Ich wollte halt den
> Rechner von beiden Seiten gleich nennen. Aber vllt. aendere ich das noch
> - Namen sind ja eh Schall und Rauch...


Hab ich jetzt gemacht, wobei nur noch einer als NS fungiert für die
Forwärtsauflösung der apaku.dnsalias.org Zone, rückwärts geht jeweils
über das Interface das im jeweiligen Subnetz hängt.

Andreas
Thomas Antepoth (19.09.2005, 18:10)
Schalom :-)

das Diggen ist immer wieder erhellend :-)

[..]
> Ahh, mir daemmerts, ich hab ja nur ne Zonendefinition für 192.168
> gemacht, damit ich mir was spare... Muss ich also für beide Subnetze
> eigene Zonefiles anlegen ja?


Absolut korrekt.

Du kannst das Setup selbst testen, indem Du mal versuchst, direkt mit dem
"nsupdate" einen Eintrag in deine Zones zu schaufeln - gerade so als ob
der dnsupdate.pl das machen würde.

Wenn das schon nicht funktioniert, dann wird der dnsupdate.pl das auch
nicht können.

Für einen Quick-Hack - ohne irgendwelche Vorbedingungen (PREREQ):

dfw1:/var/named# nsupdate
> update add oink.so.antepoth.de 10 in a 192.168.186.42
> update add 42.186.168.192.in-addr.arpa 10 ptr oink.so.antepoth.de.


Bitte beachten: Zweimal ENTER drücken!

Im daemon.log steht dann was von:
Sep 19 17:49:31 dfw1 named[3192]: client 192.168.186.254#1042: updating zone 'so.antepoth.de/IN': adding an RR
Sep 19 17:49:59 dfw1 named[3192]: client 192.168.186.254#1043: updating zone '186.168.192.in-addr.arpa/IN': adding an RR
dfw1:/var/log#

Und der dns gibt dann brav aus:

dfw1:/var/log# nslookup oink.so.antepoth.de
Server: 127.0.0.1
Address: 127.0.0.1#53

Name: oink.so.antepoth.de
Address: 192.168.186.42

dfw1:/var/log# nslookup 192.168.186.42
Server: 127.0.0.1
Address: 127.0.0.1#53

42.186.168.192.in-addr.arpa name = oink.so.antepoth.de.

Zum Entfernen:

dfw1:/var/named# nsupdate
> update delete 42.186.168.192.in-addr.arpa
> update delete oink.so.antepoth.de


Auch hier wieder das daemon.log dazu:

Sep 19 17:55:05 dfw1 named[3192]: client 192.168.186.254#1043: updating zone '186.168.192.in-addr.arpa/IN': delete all rrsets from a name
Sep 19 17:55:16 dfw1 named[3192]: client 192.168.186.254#1043: updating zone 'so.antepoth.de/IN': delete all rrsets from a name

Wenn diese Schritte schon mal laufen, dann kann das DNS-Setup nicht gar so
falsch sein. Dann können nur noch irgendwelche wilden PREREQ des alten
dnsupdate.pl dafür sorgen, daß nicht upgedated wird.

> ;; ANSWER SECTION:
> dnsalias.org. 85777 IN NS ns1.dyndns.org.
> dnsalias.org. 85777 IN NS ns2.dyndns.org.
> dnsalias.org. 85777 IN NS ns3.dyndns.org.
> dnsalias.org. 85777 IN NS ns4.dyndns.org.
> dnsalias.org. 85777 IN NS ns5.dyndns.org.


Damit fragt das interne LAN die externen NS nach der Subdomain .apaku.

Diese Subdomain wird dann aber NS-mäßig wieder nach nsX.dyndns.org
geleitet. Der wiederum läßt sicherlich nicht allzuviele nsupdate von
deinem DNS zu, denke ich mal.

> Hab ich jetzt gemacht, wobei nur noch einer als NS fungiert für die
> Forwärtsauflösung der apaku.dnsalias.org Zone, rückwärts geht jeweils
> über das Interface das im jeweiligen Subnetz hängt.


Ist sauberer. Auch bei der Fehlersuche tut man sich leichter.

t++
Andreas Pakulat (19.09.2005, 20:30)
On 19.09.05 18:01:33, Thomas Antepoth wrote:
> Absolut korrekt.


Ok, hab ich geaendert.

Mal ne Frage: Hast du dhcpd oder dhcp3-server laufen? Ersteres laeuft ja
zusammen mit autodns-dhcp, und der dhcp3 kann das von sich aus oder?

Ich hatte jetzt mal den dhcp3-server installiert, aber es passiert
immernoch nicht mehr...

> Wenn das schon nicht funktioniert, dann wird der dnsupdate.pl das auch
> nicht können.


Also nsupdate funktionier schon beim ersten Teil nicht (also host -> IP
eintragen).

Sep 19 19:37:12 neo named[8360]: client 192.168.1.1#1026: updating zone 'apaku.dnsalias.org/IN': adding an RR
Sep 19 19:37:12 neo named[8360]: journal file /etc/bind/db.apaku.dnsalias.org.jnl does not exist, creating it
Sep 19 19:37:12 neo named[8360]: /etc/bind/db.apaku.dnsalias.org.jnl: create: permission denied
Sep 19 19:37:12 neo named[8360]: client 192.168.1.1#1026: updating zone 'apaku.dnsalias.org/IN': error: journal open failed: unexpected error

Hab mir dann mal die Berechtigungen in /etc/bind angeguckt - Huch meine
Zone-Files sind alle nur für root schreibbar. Also fix geaendert:
root@neo:/etc/bind>ls -l
total 17
-rw-rw-r-- 1 root bind 237 Jan 25 2005 db.0
-rw-rw-r-- 1 root bind 271 Jan 25 2005 db.127
-rw-rw-r-- 1 root bind 207 Sep 19 17:13 db.192.168.1
-rw-rw-r-- 1 root bind 208 Sep 19 17:50 db.192.168.2
-rw-rw-r-- 1 root bind 237 Jan 25 2005 db.255
-rw-rw-r-- 1 root bind 465 Sep 19 17:50 db.apaku.dnsalias.org
-rw-rw-r-- 1 root bind 353 Sep 23 2004 db.empty
-rw-rw-r-- 1 root bind 256 Jan 25 2005 db.local
-rw-rw-r-- 1 root bind 1507 Jan 25 2005 db.root
-rw-r--r-- 1 root bind 1611 Sep 15 12:25 named.conf
-rw-r--r-- 1 root bind 688 Sep 19 17:51 named.conf.local
-rw-r--r-- 1 root bind 931 Sep 19 17:52 named.conf.options
-rw-r----- 1 bind bind 77 Sep 13 22:26 rndc.key
-rw-r--r-- 1 root root 1317 Sep 23 2004 zones.rfc1918

Aber noch keine Besserung. Dann noch /etc/bind selbst überprüft: Da war
root@neo:/etc/bind>ls -ld .
drwxr-sr-x 2 root bind 1024 Sep 19 19:42 .

wohl auch noch ein "w" zuwenig...

> Wenn diese Schritte schon mal laufen, dann kann das DNS-Setup nicht gar so
> falsch sein. Dann können nur noch irgendwelche wilden PREREQ des alten
> dnsupdate.pl dafür sorgen, daß nicht upgedated wird.


Also ich schau jetzt erstmal ob es mit dem dhcp3-server funktioniert...

Nee, der DHCP-Server scheint irgendwie keine DNS-Updates zu machen. Aber
bevor ich jetzt wieder den dhcpd v2.X + autodns-dhcp installiere, hast
du ne Idee wo ich da mit dem Schraubenzieher ansetzen kann? Ne IP
bekomme ich vom dhcp-Server. Config haengt an (habs auchschon mit dem
interim Mode probiert - keine Besserung)

> Damit fragt das interne LAN die externen NS nach der Subdomain .apaku.
> Diese Subdomain wird dann aber NS-mäßig wieder nach nsX.dyndns.org
> geleitet. Der wiederum läßt sicherlich nicht allzuviele nsupdate von
> deinem DNS zu, denke ich mal.


Jepp, so alle 5 Minuten darf man bei Dyndns das tun, aber dafuer laeuft
auf dem Router ja der dyndns-Client, der macht das auch nur alle 5
Minuten. Und da ich mittlerweile wieder am Uni-Netz haenge bekomme ich
trotz ISDN-Einwahl nur alle 24h eine neue IP zugewiesen :-)

Sprich das ist alles nicht das Problem.

Andreas
Thomas Antepoth (19.09.2005, 21:10)
Krishna Swami :-)

On Mon, 19 Sep 2005, Andreas Pakulat wrote:

> Mal ne Frage: Hast du dhcpd oder dhcp3-server laufen? Ersteres laeuft ja
> zusammen mit autodns-dhcp, und der dhcp3 kann das von sich aus oder?


dhcpd3 - aber egal was den "update add ..." beim bind9 ausführt - zuerst
muß mal der bind9 einen dynamischen Update hinbekommen. Und das scheint
im Augenblick noch fehlzuschlagen.

Am dhcpd3 beeindruckt mich die Sache aus "einem Guß" und die extreme
Vorsicht bei der Vorgehensweise - beim dnsupdate.pl empfand ich die ganze
Sache etwas brachial, andererseits hatte mir das ddns.cron.update schon
das eine oder andere Mal eine Zone wieder "gerichtet", die mir der dhcpd3
nicht sauber upgedatet hatte. YMMV. Bei beiden muß man aber den
nsupdate Mechanismus grundlegend verstanden haben.

> Also nsupdate funktionier schon beim ersten Teil nicht (also host -> IP
> eintragen).
> Sep 19 19:37:12 neo named[8360]: client 192.168.1.1#1026: updating zone 'apaku.dnsalias.org/IN': adding an RR
> Sep 19 19:37:12 neo named[8360]: journal file /etc/bind/db.apaku.dnsalias.org.jnl does not exist, creating it
> Sep 19 19:37:12 neo named[8360]: /etc/bind/db.apaku.dnsalias.org.jnl: create: permission denied


Das Erzeugen eines Journals schlägt seitens des bind fehl. Offensichtlich
sind die Perms für den User bind auf dem Directory noch nicht offen genug.

Ich würde die Configs und die Zones voneinander trennen. /etc/bind hat nur
configs und ist restriktiv - /var/named hat nur Zones und hat rw-Perms
für den User bind.

Das sieht dann hier so aus:

dfw1:/var/named# ls -la
total 486
drwxr-xr-x 4 bind bind 464 Sep 19 19:19 .
drwxr-xr-x 16 root root 360 Sep 3 06:39 ..
-rw-r--r-- 1 bind bind 192 Mar 14 2003 127.0.0.zone
-rw------- 1 bind bind 354 Aug 27 00:12 192.168.101.0.zone
-rw------- 1 bind bind 417 Sep 19 19:19 192.168.186.0.zone
-rw-r--r-- 1 bind bind 189688 Sep 19 19:04 192.168.186.0.zone.jnl
-rw------- 1 bind bind 417 Aug 27 00:12 192.168.241.0.zone
-rw-r--r-- 1 bind bind 334 Aug 27 00:35 antepoth.de.zone
-rw-r--r-- 1 bind bind 158 Mar 14 2003 localhost.zone
drwxr-xr-x 2 bind bind 48 Mar 14 2003 master
-rw-r--r-- 1 bind bind 2498 Mar 14 2003 root.hint
drwxr-xr-x 2 bind bind 48 Oct 25 2003 slave
-rw------- 1 bind bind 580 Sep 19 19:19 so.antepoth.de.zone
-rw-r--r-- 1 bind bind 268879 Sep 19 19:04 so.antepoth.de.zone.jnl
dfw1:/var/named#

Wie man sieht, wachsen die .jnl-Dateien erklecklich an. Wenn ich mal nicht
weiß, was ich tun soll, dann finde ich auch noch heraus, wie man die
purged ;-)

> Sep 19 19:37:12 neo named[8360]: client 192.168.1.1#1026: updating zone 'apaku.dnsalias.org/IN': error: journal open failed: unexpected error


> Aber noch keine Besserung. Dann noch /etc/bind selbst überprüft: Da war
> root@neo:/etc/bind>ls -ld .
> drwxr-sr-x 2 root bind 1024 Sep 19 19:42 .
> wohl auch noch ein "w" zuwenig...


Auch absolut korrekt erkannt. Wie gesagt - die Configs und die Zones würde
ich trennen. Wenn es schon unterhalb von /etc/bind/ sein muß, dann
wenigstens als /etc/bind/zones/

> Also ich schau jetzt erstmal ob es mit dem dhcp3-server funktioniert...
> Nee, der DHCP-Server scheint irgendwie keine DNS-Updates zu machen. Aber
> bevor ich jetzt wieder den dhcpd v2.X + autodns-dhcp installiere, hast
> du ne Idee wo ich da mit dem Schraubenzieher ansetzen kann?


Zuerst der DDNS mit dem bind9 - danach kann man sich immer noch
entscheiden, welchen dhcp man verwendet.

Wie man den Update testet, weißt Du mittlerweile. Und bevor der nicht
funktioniert, würde ich keinen Handschlag in irgendeine andere Richtung
machen. Das kann nur Folgefehler und damit vertane Zeit geben.

> > Der wiederum läßt sicherlich nicht allzuviele nsupdate von
> > deinem DNS zu, denke ich mal.

> Jepp, so alle 5 Minuten darf man bei Dyndns das tun, aber dafuer laeuft
> auf dem Router ja der dyndns-Client, der macht das auch nur alle 5
> Minuten.


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.

t++
Andreas Pakulat (19.09.2005, 22:30)
On 19.09.05 21:04:48, Thomas Antepoth wrote:
> On Mon, 19 Sep 2005, Andreas Pakulat wrote:
> > Mal ne Frage: Hast du dhcpd oder dhcp3-server laufen? Ersteres laeuft ja
> > zusammen mit autodns-dhcp, und der dhcp3 kann das von sich aus oder?

> dhcpd3 - aber egal was den "update add ..." beim bind9 ausführt - 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. Ich fang meisst an eine Antwort zu schreiben und notiere
dann nebenbei was ich so mache. Habe also zuerstmal nsupdate ausprobiert
und anhand der Logmeldungen herausgefunden, dass ebend die Rechte nicht
ausreichend gesetzt waren. Das hab ich behoben und mit nsupdate kann ich
nun updates durchführen. Nur der dhcpd macht das leider noch nicht :-(

> Ich würde die Configs und die Zones voneinander trennen. /etc/bind hat nur
> configs und ist restriktiv - /var/named hat nur Zones und hat rw-Perms
> für den User bind.


Macht Sinn, hätte ich wahrscheinlich auch so gemacht, aber per Default
sind die db.* Dateien in /etc bei bind9. /var/named existiert nicht,
aber /var/cache/bind. Dort werd ich die Zone-files hinverfrachten.

> Auch absolut korrekt erkannt. Wie gesagt - die Configs und die Zones würde
> ich trennen. Wenn es schon unterhalb von /etc/bind/ sein muß, dann
> wenigstens als /etc/bind/zones/


Ok, da fehlte offensichtlich der Satz "Ja, nach Änderung der Rechte geht
das nsupdate jetzt". Mein Fehler.

> Zuerst der DDNS mit dem bind9 - danach kann man sich immer noch
> entscheiden, welchen dhcp man verwendet.


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...

> 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? 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). 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.

Andreas
Hans-Georg Bork (20.09.2005, 23:00)
Moin,

On Mon, Sep 19, 2005 at 10:25:57PM +0200, Andreas Pakulat wrote:
> [...]
> 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.


Domainnamen werden normalerweise von rechts nach links aufgeloest und
dann "verarbeitet"; es wird also u.U. der NS von dnsalias.de verwandt.
Da Deine IP-Adressen nur lokal verwendbar sind (192.168.0.0/16) ist
es eigentlich (fast) logisch auch den jeweiligen Namen nur lokal zuzulassen,
und zwar indem Du eine eigene Domain verwendest, z.B. blah.apaku.local.
Damit gehen weder Anfragen, noch Updates an externe NS. Bei mir ist das
..home und funzt, ohne das dyndns irgendwelche Probleme macht.

Gruss
-- hgb
Andreas Pakulat (20.09.2005, 23:40)
On 20.09.05 22:31:19, Hans-Georg Bork wrote:
> Moin,
> On Mon, Sep 19, 2005 at 10:25:57PM +0200, Andreas Pakulat wrote:
> Domainnamen werden normalerweise von rechts nach links aufgeloest und
> dann "verarbeitet"; es wird also u.U. der NS von dnsalias.de verwandt.
> Da Deine IP-Adressen nur lokal verwendbar sind (192.168.0.0/16) ist
> es eigentlich (fast) logisch auch den jeweiligen Namen nur lokal zuzulassen,
> und zwar indem Du eine eigene Domain verwendest, z.B. blah.apaku.local.
> Damit gehen weder Anfragen, noch Updates an externe NS. Bei mir ist das
> .home und funzt, ohne das dyndns irgendwelche Probleme macht.


Prinzipiell ist das ja korrekt. Ich hatte das weiter oben im Thread
schonmal erwähnt, wir hatten hier vor einiger Zeit (Anfang des Jahres)
eine längere Diskussion darüber dass die in den Message-ID's benutzten
Domänen nach Möglichkeit auflösbar sein sollten. Sprich wenn dort bei
mir z.B.

morpheus.apaku.dnsalias.org

steht sollte wenigstens der nicht-Host-Teil auflösbar sein (für jeden).
Die genauen Gründe hab ich nicht im Kopf... Jedenfalls hatte ich als
Ergebnis dessen von meiner selbst erdachten Domain auf meine
dyndns-Domain umgestellt (ebend wie oben). Ich will das eigentlich nicht
wieder ändern und das Auflösen meiner lokalen Namen funktioniert ja
soweit auch, nur ebend das der dhcpd kein DNS-Update durchführt. Wenn
ich da nicht bald nen Schalter finde werd ich nen Bugreport schreiben,
denn nen Config-Fehler habe ich eigentlich nicht (jedenfalls sehe ich
keinen).

Andreas
Thomas Antepoth (21.09.2005, 07:40)
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 existdelete 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 wirdmit
> > 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++
Andreas Pakulat (21.09.2005, 09:50)
On 21.09.05 07:30:37, Thomas Antepoth wrote:
> On Mon, 19 Sep 2005, Andreas Pakulat wrote:
> Die conf vom dhcpd3 sieht hier so aus:


Bei mir eigentlich genauso, nur dass die host-Teile keine feste IP
vergeben.

> 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.


Hmm, das ist natürlich genau das was ich möchte, sprich: Der DHPC-Client
soll seinen Hostnamen nicht selbst schicken, das will ich in der
dhcpd-Config festlegen, aber er soll eine IP aus der Range kriegen und
keine feste. Also doch wieder die autodns-dhcp-Skripte installieren und
den dhcpd2 nehmen?

> 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


Mache ich heute nachmittag...

> 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 Bind hört auf den interenen LAN-Interfaces und auf lo, nicht aber
auf dem externen ISDN-Interface. Wozu auch, der soll ja nur fürs LAN
NSen.. Aber meine Clients nutzen alle meinen DNS, so dass der die Chance
hat apaku.dnsalias.org aufzulösen ohne andere NS zu fragen. Erfragt halt
nur alles unbekannte nach...

> > 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) :-)


In gewisser Weise hast du Recht, denn eigentlich sollte der NS ja damit
anfangen den de-Teil aufzulösen oder? Oder liegt das an

andreas@morpheus:~>cat /etc/resolv.conf
search apaku.dnsalias.org
nameserver 192.168.2.1

> 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?


DNS-failover brauch ich hier nicht - wenn der DNS nicht geht, geht auch
kein LAN :-) Der ist ja Router/DHCP/DNS/Backup/Interneteinwahl in einem.

Andreas
Thomas Antepoth (21.09.2005, 20:20)
On Wed, 21 Sep 2005, Andreas Pakulat wrote:

> Hmm, das ist natürlich genau das was ich möchte, sprich: Der DHPC-Client
> soll seinen Hostnamen nicht selbst schicken, das will ich in der
> dhcpd-Config festlegen, aber er soll eine IP aus der Range kriegen und
> keine feste.


Die Rechner, die mit der "host"-Direktive in der dhcpd.conf eingebunden
sind, haben eine statische IP. Statische IPs werden aber vom DHCP3 nicht
an den DNS gemeldet - wozu auch - deren Hostnamen ändern sich ja auch
nicht.

Schau' Dir mal die Range in meiner .conf genau an.

Der Range geht bis .190 - die Rechner sofa und ssofa haben jedoch .199 und
.193 - diese waren mit der "host"-Direktive gemeint.

Alle anderen in der Range bis .190 werden dynamisch allokiert und auch
dynamisch eingetragen - gerade so wie es sich für anständige DDNS-Server
gehört.

> Also doch wieder die autodns-dhcp-Skripte installieren und
> den dhcpd2 nehmen?


Wenn Du magst - ist - wie schon gesagt - Geschmackssache. :-)
Funktionieren tun sie sicherlich beide, wenn man sie richtig einrichtet.

Aber allem zum Trotz - ich vermute noch irgendwo im dns-Setup einen
kleinen Hundling, eher eine DNS-Formalie als einen Fehler, die den dhcp
davon abhält, einen Update vorzunehmen. Manuell mag das klappen, aber der
dhcpd3 fragt noch ein paar Kleinigkeiten am DNS ab, die erfüllt sein
müssen, bevor der den "update add" 'rausschickt.

Sowas läßt sich übrigens recht pfiffig mit dem dnswalk ausknobeln, fällt
mir gerade ein - ein nahezu vorbildlicher (hüstel) DNS sieht dann so aus:

dfw1:/var/named# dnswalk .so.antepoth.de.
Checking .so.antepoth.de.
BAD: .so.antepoth.de. has only one authoritative nameserver
Getting zone transfer of .so.antepoth.de. from fw1.so.antepoth.de...done.
SOA=fw1.so.antepoth.de contact=root.so.antepoth.de
0 failures, 0 warnings, 1 errors.
dfw1:/var/named#

Den Voraussetzung, 2 DNS-Server haben zu müssen, scheint im DHCP3 auf
jeden Fall nicht mehr so wichtig zu sein, wie seinerzeit noch.

> In gewisser Weise hast du Recht, denn eigentlich sollte der NS ja damit
> anfangen den de-Teil aufzulösen oder? Oder liegt das an
> andreas@morpheus:~>cat /etc/resolv.conf
> search apaku.dnsalias.org
> nameserver 192.168.2.1


Selbst dann sollte eigentlich erst mal von org nach dnsalias nach apaku
resolved werden. Aber einen Versuch wär's vielleicht wert!

Mach' doch mal den Morpheus bei Dir lokal zum SOA für dnsalias.org indem
Du eine Master-Zone dort deklarierst und dort dann eine Delegation an
apaku einbaust. Ist zwar nicht ganz fair und nicht ganz fein - aber für
einen Quickie ganz brauchbar. Wenn's danach funktioniert, wissen wir, daß
die fehlende Delegation schuld war.

> DNS-failover brauch ich hier nicht - wenn der DNS nicht geht, geht auch
> kein LAN :-)


Ebendrum braucht man ja auch ein Failover :*)

> Der ist ja Router/DHCP/DNS/Backup/Interneteinwahl in einem.


Und dann noch bitte eine HA-Lösung für offene Connections an der Firewall,
bitte. Reicht aber, wenn's morgen fertig ist :-D

t++
Andreas Pakulat (21.09.2005, 22:40)
On 21.09.05 20:18:45, Thomas Antepoth wrote:
> > Hmm, das ist natürlich genau das was ich möchte, sprich: Der DHPC-Client
> > soll seinen Hostnamen nicht selbst schicken, das will ich in der
> > dhcpd-Config festlegen, aber er soll eine IP aus der Range kriegen und
> > keine feste.

> Die Rechner, die mit der "host"-Direktive in der dhcpd.conf eingebunden
> sind, haben eine statische IP.


Bei dir, bei mir nicht.

> Statische IPs werden aber vom DHCP3 nicht an den DNS gemeldet - wozu
> auch - deren Hostnamen ändern sich ja auch nicht.


Klaro.

> Schau' Dir mal die Range in meiner .conf genau an.
> Der Range geht bis .190 - die Rechner sofa und ssofa haben jedoch .199 und
> .193 - diese waren mit der "host"-Direktive gemeint.


So genau hatte ich nicht hingeschaut, nur gesehen dass du statische IP's
nutzt.

> Alle anderen in der Range bis .190 werden dynamisch allokiert und auch
> dynamisch eingetragen - gerade so wie es sich für anständige DDNS-Server
> gehört.


Ich hab in dem host-Teil keine statische IP definiert und mein Rechner
bekommt deswegen eine der IP's in der Range.

Das Problem ist nur: DNS-Update looft nicht.

Ich hatte testweise mal die host-Angabe rausgenommen, so dass nur noch
eine IP-Range vorhanden war für mein Subnet - 0 Erfolg. Der DHCPD macht
kein DNS-Update.

> Aber allem zum Trotz - ich vermute noch irgendwo im dns-Setup einen
> kleinen Hundling, eher eine DNS-Formalie als einen Fehler, die den dhcp
> davon abhält, einen Update vorzunehmen. Manuell mag das klappen, aber der
> dhcpd3 fragt noch ein paar Kleinigkeiten am DNS ab, die erfüllt sein
> müssen, bevor der den "update add" 'rausschickt.


Ok, wie kriegt man das raus?

> Sowas läßt sich übrigens recht pfiffig mit dem dnswalk ausknobeln, fällt
> mir gerade ein - ein nahezu vorbildlicher (hüstel) DNS sieht dann so aus:


Aha, mal schauen....

andreas@neo:~>dnswalk .apaku.dnsalias.org.
Checking .apaku.dnsalias.org.
BAD: .apaku.dnsalias.org. has only one authoritative nameserver
Getting zone transfer of .apaku.dnsalias.org. from neo.apaku.dnsalias.org...done.
SOA=neo.apaku.dnsalias.org contact=root.neo.apaku.dnsalias.org
WARN: mathias.apaku.dnsalias.org A 192.168.1.2: no PTR record
0 failures, 1 warnings, 1 errors.

Hmm, das Warning ist merkwürdig. Denn ich hab

zone "1.168.192.in-addr.arpa" {
type master;
notify no;
file "/var/cache/bind/db.192.168.1";
allow-query { any; };
allow-update { 127.0.0.1; 192.168.1.1; 192.168.2.1; };
};

Und dort dann

$TTL 3D
@ IN SOA neo.apaku.dnsalias.org. root.neo.apaku.dnsalias.org. (
11
8H
2H
4W
1D )
NS neo.apaku.dnsalias.org.
1 PTR trinity.apaku.dnsalias.org.
2 PTR mathias.apaku.dnsalias.org.

> Den Voraussetzung, 2 DNS-Server haben zu müssen, scheint im DHCP3 auf
> jeden Fall nicht mehr so wichtig zu sein, wie seinerzeit noch.


Ich hoffe es, denn ich hab nur 1 :-( und mehr ist auch nicht drin.

> Selbst dann sollte eigentlich erst mal von org nach dnsalias nach apaku
> resolved werden. Aber einen Versuch wär's vielleicht wert!
> Mach' doch mal den Morpheus bei Dir lokal zum SOA für dnsalias.org indem
> Du eine Master-Zone dort deklarierst und dort dann eine Delegation an
> apaku einbaust. Ist zwar nicht ganz fair und nicht ganz fein - aber für
> einen Quickie ganz brauchbar. Wenn's danach funktioniert, wissen wir, daß
> die fehlende Delegation schuld war.


Da muss ich erst nochmal in die DNS-Doku schauen, damit ich verstehe ob
du morpheus oder neo/trinity meinst (letztere ist naemlich der mit dem
Bind) und was genau ich da in der Config aendern muss. Dauert also ein
bisschen...

> > DNS-failover brauch ich hier nicht - wenn der DNS nicht geht, geht auch
> > kein LAN :-)

> Ebendrum braucht man ja auch ein Failover :*)


Naja, dann bräuchte ich aber nicht nur nen 2. Rechner, sondern ne 2.
ISDN-Karte, nen 3. Zimmer das noch dazu Feuerfest und Erdbebensicher ist
(achja Wasserdich auch) :-)

Andreas
Andreas Pakulat (21.09.2005, 23:20)
On 21.09.05 22:35:56, Andreas Pakulat wrote:
> On 21.09.05 20:18:45, Thomas Antepoth wrote:
> Aha, mal schauen....
> andreas@neo:~>dnswalk .apaku.dnsalias.org.
> Checking .apaku.dnsalias.org.
> BAD: .apaku.dnsalias.org. has only one authoritative nameserver
> Getting zone transfer of .apaku.dnsalias.org. from neo.apaku.dnsalias.org...done.
> SOA=neo.apaku.dnsalias.org contact=root.neo.apaku.dnsalias.org
> WARN: mathias.apaku.dnsalias.org A 192.168.1.2: no PTR record
> 0 failures, 1 warnings, 1 errors.
> Hmm, das Warning ist merkwürdig. Denn ich hab


Ich hab den mathias-Host erstmal komplett entfernt, kein Warning mehr.
Aber auch noch kein DDNS-Update.

> Da muss ich erst nochmal in die DNS-Doku schauen, damit ich verstehe ob
> du morpheus oder neo/trinity meinst (letztere ist naemlich der mit dem
> Bind) und was genau ich da in der Config aendern muss. Dauert also ein
> bisschen...


Also wenn ich das richtig verstanden habe sollte mein DNS-Server jetzt
behaupten er wäre für dnsalias.org zuständig:

andreas@neo:~>dig dnsalias.org afxr

; <<>> DiG 9.2.4 <<>> dnsalias.org afxr
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19506
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;dnsalias.org. IN A

;; AUTHORITY SECTION:
dnsalias.org. 86400 IN SOA neo.apaku.dnsalias.org. root.neo.apaku.dnsalias.org. 16 28800 7200 2419200 86400

;; Query time: 6 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Sep 21 23:14:47 2005
;; MSG SIZE rcvd: 81

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3376
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;afxr. IN A

;; AUTHORITY SECTION:
.. 10233 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2005092100 1800 900 604800 86400

;; Query time: 3174 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Sep 21 23:14:50 2005
;; MSG SIZE rcvd: 97

Hat aber noch keinerlei Veränderung gebracht. Ich hatte sicherheitshalbe
nochmal den hosts-Teil aus der dhcpd-Config entfernt und ebenso den
DHCP-Client seinen Host-Namen übertragen lassen. Der DHCPD will einfach
kein DNS-Update anstossen.

Andreas
Thomas Antepoth (22.09.2005, 21:51)
On Wed, 21 Sep 2005, Andreas Pakulat wrote:

> Ich hab den mathias-Host erstmal komplett entfernt, kein Warning mehr.
> Aber auch noch kein DDNS-Update.


Wenn ich es richtig gesehen habe, war das der Copy'n Paste aus dem
Zonefile. Das kann man mit bind9 getrost vergessen, solange er läuft.

Das einzige, was Dir wirklich die Zone ausgibt, die auch die Clients
sehen, ist ein:

dig @dns yourzone axfr

Bind9 speichert sich die dynamischen Änderunen in den .jnl-Dateien ab und
speichert erst dann das Zonefile, wenn man mit dem rndc Utility den Server
davon überzeugt es zu tun oder den Bind9 durchstartet. Frag' mich bitte
nicht nach dem "rndc" Tool. Ich hab' schon den Vorläufer "ndc" nicht
wirklich verstanden. ;-)

Da der dnswalk auch nur einen Zonetransfer macht, kann das Ergebnis aus
dem Zonefile im Zweifel auch nur falsch sein.


Ich bring die ganzen Namen immer durcheinander. Bin ja auch schon alt. ;-)
Ich meine natürlich den "neo/trinity" - wie komme ich da auf Morpheus?

[..]
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Wed Sep 21 23:14:47 2005
> ;; MSG SIZE rcvd: 81


Da fehlt noch mindestens ein NS Eintrag und die Delegation für .apaku.

Bei der lokalen Zone antepoth.de sieht die so aus:

dfw1:~# dig antepoth.de axfr

; <<>> DiG 9.2.4 <<>> antepoth.de axfr
;; global options: printcmd
antepoth.de. 172800 IN SOA fw1.antepoth.de. root.antepoth.de. 1999092901 86400 7200 604800 172800
antepoth.de. 172800 IN NS fw1.antepoth.de.
antepoth.de. 172800 IN MX 10 mail.antepoth.de.
extern.antepoth.de. 172800 IN A 192.168.101.254
fw1.antepoth.de. 172800 IN A 192.168.186.254
mail.antepoth.de. 172800 IN A 212.227.20.60
so.antepoth.de. 172800 IN NS fw1.antepoth.de.
. 172800 IN A 212.227.20.60
antepoth.de. 172800 IN SOA fw1.antepoth.de.
root.antepoth.de. 1999092901 86400 7200 604800 172800
;; Query time: 7 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Sep 22 21:43:57 2005
;; XFR size: 10 records

Sehr schön sieht man auch den so.antepoth.de Eintrag. Der besteht nur aus
einem NS-Record. Die Zone .so hat dann den "fw1.so.antepoth.de" als NS -
mit der gleichen IP wie der fw1.antepoth.de.

> Hat aber noch keinerlei Veränderung gebracht.


Ja. Denn woher soll der DNS mit der "künstlichen" Zone dnsalias.org denn
wissen, wie er die .apaku delegieren soll? Mir fielen auch die 3 Sekunden
auf, die für die Antwort nötig waren. Die hat der Bind auf dem "neo."
gebraucht, um die ganzen root-NS zu fragen, wer hier dnsalias.org kennen
könnte. Die 7..8 msec hier zeigen auch, daß hier keine Anfragen nach außen
geroutet werden.

> Ich hatte sicherheitshalbe nochmal den hosts-Teil aus der dhcpd-Config
> entfernt und ebenso den DHCP-Client seinen Host-Namen übertragen lassen.
> Der DHCPD will einfach kein DNS-Update anstossen.


Jetzt wäre mal langsam ein

tcpdump -s0 -n -w blubb.dmp -i DEINBINDINTERFACE port 53

und davon der hexdump

durch:

tcpdump -Xnr blubb.dmp

während einem Update interessant.

Keys hast Du ja hoffentlich keine, und das Update der Zones wird
vermutlich - wie hier - aus persönlicher Faulheit - auch - per IP
gesteuert. ;-)

Bei den Windei-Kisten kannst Du den Update ganz gelöst über

ipconfig /release
ipconfig /renew

auslösen.

t++
Andreas Pakulat (22.09.2005, 23:30)
On 22.09.05 21:49:26, Thomas Antepoth wrote:
> On Wed, 21 Sep 2005, Andreas Pakulat wrote:
> Wenn ich es richtig gesehen habe, war das der Copy'n Paste aus dem
> Zonefile. Das kann man mit bind9 getrost vergessen, solange er läuft.
> Das einzige, was Dir wirklich die Zone ausgibt, die auch die Clients
> sehen, ist ein:
> dig @dns yourzone axfr


Ok, also nachdem ich rausgekriegt hab das ich fuer "@dns" "@meindns"
schreiben muss lief der Befehlt soweit durch. Fuer apaku.dnsalias.org
listet er mir quasi das von mir definierte zone-File auf (wenn ich das
richtig sehe). Fuer dnsalias.org natuerlich nur dann wenn ich meinen
bind9 als Master fuer die Domain einrichte...

Soweit sehe ich keine Fehler in meinem DNS-Setup, wenn du dich
vergewissern willst ob die Ausgaben der 2 Befehle wirklich korrekt sind,
bitte off-list (bins langsam leid das immer alles zu C'n'P...)

> Bind9 speichert sich die dynamischen Änderunen in den .jnl-Dateien ab und
> speichert erst dann das Zonefile, wenn man mit dem rndc Utility den Server
> davon überzeugt es zu tun oder den Bind9 durchstartet. Frag' mich bitte
> nicht nach dem "rndc" Tool. Ich hab' schon den Vorläufer "ndc" nicht
> wirklich verstanden. ;-)


Ich mach wenn sowas noetig wird immer ein /etc/init.d/bind9 restart. Hab
nicht die Zeit _noch_ ein Tool kennen zu lernen - jedenfalls nicht wenns
so auch geht...

> Da fehlt noch mindestens ein NS Eintrag und die Delegation für .apaku.


Hmm, wenn ich das richtig sehe fehlt mir da nur sowas:

apaku.dnsalias.org NS neo.apaku.dnsalias.org.

im Zone-File?

> > Hat aber noch keinerlei Veränderung gebracht.

> Ja. Denn woher soll der DNS mit der "künstlichen" Zone dnsalias.org denn
> wissen, wie er die .apaku delegieren soll?


:-)

> Mir fielen auch die 3 Sekunden
> auf, die für die Antwort nötig waren. Die hat der Bind auf dem "neo."
> gebraucht, um die ganzen root-NS zu fragen, wer hier dnsalias.org kennen
> könnte. Die 7..8 msec hier zeigen auch, daß hier keine Anfragen nach außen
> geroutet werden.


Was du nicht alles siehst... Ach ja, jetzt sehe ich da auch ne Query
time ;-)

Also ich denke jetzt funktioniert die Delegation:
root@neo:~>dig dnsalias.org axfr

; <<>> DiG 9.2.4 <<>> dnsalias.org axfr
;; global options: printcmd
dnsalias.org. 259200 IN SOA neo.apaku.dnsalias.org. root.neo.apaku.dnsalias.org. 16 28800 7200 2419200 86400
dnsalias.org. 259200 IN NS neo.apaku.dnsalias.org.
apaku.dnsalias.org. 259200 IN NS neo.apaku.dnsalias.org.
dnsalias.org. 259200 IN SOA neo.apaku.dnsalias.org. root.neo.apaku.dnsalias.org. 16 28800 7200 2419200 86400
;; Query time: 6 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Sep 22 23:03:21 2005
;; XFR size: 4 records

Nur der DHCPd mag immernoch nicht mit dem Bind9 quatschen. Hat der nicht
irgendeine Debug-Option oder so, ist ja schlimm wie wenig
gesprächsfreudig der ist...

> > Ich hatte sicherheitshalbe nochmal den hosts-Teil aus der dhcpd-Config
> > entfernt und ebenso den DHCP-Client seinen Host-Namen übertragen lassen.
> > Der DHCPD will einfach kein DNS-Update anstossen.

> Jetzt wäre mal langsam ein
> tcpdump -s0 -n -w blubb.dmp -i DEINBINDINTERFACE port 53


Stell dir vor, das musste ich aufm Server erst noch installieren. Was
im Moment - apt-proxy sei dank - bedeutet ich darf das DNS-Update per
Hand machen und dem Bind hinterher den Namen wieder abgewoehnen :-(

> tcpdump -Xnr blubb.dmp


Ich lass das mal, denn der tcpdump hat auf allen 3 Interfaces _kein_
Paket mitgeloggt. Sprich der DHCPd versucht es erst gar nicht. Ich poste
jetzt (sicherheitshalber) nochmal meine DHCP-Config, vllt. faellt dir
was auf was ich falsch mache...

root@neo:~>grep -v "^#.*$" /etc/dhcp3/dhcpd.conf | grep -v "^$"
ddns-update-style interim;
ddns-domainname "apaku.dnsalias.org";
ddns-updates on;
deny client-updates;
option domain-name "apaku.dnsalias.org";
option domain-name-servers 192.168.2.1;
default-lease-time 600;
max-lease-time 7200;
authoritative;
log-facility local7;
subnet 192.168.2.0 netmask 255.255.255.0 {
option routers 192.168.2.1;
option broadcast-address 192.168.1.255;
range 192.168.2.20 192.168.2.30;
}

Andreas
Andreas Pakulat (22.09.2005, 23:50)
On 22.09.05 23:23:50, Andreas Pakulat wrote:
> > tcpdump -Xnr blubb.dmp

> Ich lass das mal, denn der tcpdump hat auf allen 3 Interfaces _kein_
> Paket mitgeloggt. Sprich der DHCPd versucht es erst gar nicht. Ich poste
> jetzt (sicherheitshalber) nochmal meine DHCP-Config, vllt. faellt dir
> was auf was ich falsch mache...


So, also die Ursache hab ich gefunden, nur eine Lösung noch nicht.

Also Problem war einfach nur, dass ich den Client nicht den Hostnamen
hab mitsenden lassen. Da in der dhcpd-Config aber eh

deny client-updates;

steht, dachte ich das waere egal. Nunja, es kommt noch besser, diese
Direktive scheint vollkommen wirkungslos zu sein, denn der DHCP-Server
nimmt trotzdem den Hostnamen den der Client liefert, nicht den den ich
per

subnet 192.168.2.0 netmask 255.255.255.0 {
option routers 192.168.2.1;
option broadcast-address 192.168.1.255;
range 192.168.2.20 192.168.2.30;
host morpheus {
ddns-hostname morpheus;
hardware ethernet 10:02:3F:67:BD:6c;
}
}

festgelegt habe. Da muss ich wohl noch ein wenig in den Untiefen von
dhcpd wühlen. Das einzig nervige dabei ist, dass der dhcpd nur die
Hostnamen updated die er nicht schon upgedatet hat - was heisst jedesmal
die lease-Datei loeschen und den dhcpd neu starten.

Wer hat sich denn diesen Schwachsinn ausgedacht?? ;-)

Andreas

Ähnliche Themen