Diskussion:Entwicklungsumgebung/DHCP: Unterschied zwischen den Versionen
(kpl.) |
KKeine Bearbeitungszusammenfassung |
||
Zeile 51: | Zeile 51: | ||
fixed-address 192.168.3.241; | fixed-address 192.168.3.241; | ||
} | } | ||
} | |||
Version vom 11. Dezember 2008, 22:07 Uhr
DDNS
ist eine feine Sache, machen wir seit Jahren, weil es die Namensauflösung extrem beschleunigt.
Was man dafür braucht ist ein key, der dem bind und dem dhcpd bekannt ist.
in die dhcpd.conf:
allow booting; server-identifier 192.168.3.2; option domain-name "sub.domain.tld"; option domain-name-servers 192.168.3.2; option subnet-mask 255.255.255.0; option netbios-node-type 8; # First WINS,then Broadcast option netbios-name-servers 192.168.3.3; # Samba #neu: http://wiki.bsdforen.de/howto/automatische_proxy-konfiguration option wpad code 252 = text; option wpad "http://wpad.domain.tld/wpad.dat"; default-lease-time 3600; # 1h max-lease-time 86400; # 1d authoritative; # Der DHCPd soll DDNS machen ddns-update-style interim; # Die Clients sollen *nie* selbst DDNS machen, sondern immer der DHCPd ignore client-updates; get-lease-hostnames on; # Anstelle den key anzugeben, sollte auch ein include möglich sein: # include "/etc/bind/Kbst.domain.tld.+157+35662.key"; key sub.domain.tld { algorithm HMAC-MD5.SIG-ALG.REG.INT; secret xRLSiTqRBXw[...snip...]UbaAIXUfBpJ4M0XovKQj76Lg== }; zone sub.domain.tld { primary 127.0.0.1; key sub.domain.tld; } zone 3.168.192.in-addr.arpa. { primary 127.0.0.1; key sub.domain.tld; } ## END DEFAULTS # DHCP für Netz sub.domain.tld subnet 192.168.3.0 netmask 255.255.255.0 { option broadcast-address 192.168.3.255; option domain-name "sub.domain.tld"; option routers 192.168.3.1; range 192.168.3.150 192.168.3.199; host alix # Schulserver Installer { hardware ethernet 00:01:02:03:04:05; fixed-address 192.168.3.241; } }
und dann in die named.conf.local
key sub.domain.tld { algorithm hmac-md5; secret "xRLSiTqRBE2SG.......ovKQj76Lg=="; }; // sub.domain.tld mit 192.168.3.0/24 zone "sub.domain.tld" IN { type master; file "db.sub.domain.tld"; allow-update {key sub.domain.tld;}; }; // 3.168.192.in-addr.arpa für sub.domain.tld zone "3.168.192.in-addr.arpa" IN { type master; file "db.192.168.3"; allow-update {key sub.domain.tld;}; };
Das wars schon. Den Key erstellt man über
/usr/sbin/dnssec-keygen -a HMAC-MD5 -n HOST -b 512 $DOMAIN.
Wenn auch noch Linuxclients in der /etc/dhcp3/dhcclient.conf ein
send host-name "workstation"; stehen haben, sind auch diese mit im
Geschäft.
Viele Grüße Thorsten (080606)
X.509-Zertifikate
Zertifikate machen nur dann Sinn, wenn der Dienst der sie benutzt auch verifizieren kann. Dazu gehört nicht nur ein Public/Private Key-Pair, sondern auch, im Falle von Serverdiensten, ein eindeutiger DNS-Name.
Das Problem mit dem eindeutigen DNS-Namen ist etwas diffizil. Fast alle Anwender von ssl, also X.509, benutzen den DNS-Namen des Rechners. Für einfachste Dinge ist das OK. Aber wenn ein Rechner Dienste wie LDAP oder SAMBA bereitstellt, die einen Online-Backup-Dienst ermöglichen, wie PDC + 1 bis 99 BDC, dann ist die Benutzung des realen Hostnamens, als Key-Bezeichner echt schwachsinnig.
Stellt euch vor, der PDC fällt aus. Ein BDC übernimmt vollautomatisch seine Funktion. Der hat aber einen anderen DNS-Namen, damit einen anderen Key und der Admin und alle, die via ssl darauf zugreifen wollen, sind draussen.
Also für solche Dienste muss als Key-Bezeichner ein DNS-Alias genommen werden. Denn der darf auf mehreren DNS-Hostnamen zeigen.
Die DNS-Domain für den aktuellen Rechner:
hostname -d
Im LDAP stehen nur Kopien des Domain-Namens.
ldapsearch -x -LLL "cn=DHCP Service Config" dhcpOption|\ sed -ne '/^dhcpOption/{N;s/dhcpOption: domain-name //;s/"//g;p}'
Der Installer hat auch eine Kopie gespeichert:
debconf-get-selections --installer|grep netcfg/get_domain|cut -f4
Es gibt aber keine LDAP-Domain. Nur einen NamingContext:
ldapsearch -x -LLL -h localhost -s base -b "" "objectclass=*" \ namingcontexts
Red. gekürzt. Text von Harry.