Home Server, Teil 5 – Konfiguration: DHCP & Dynamischer DNS

Projekt 'Home-Server'

Seit der Installation von CUPS und Samba stellt der Server bereits die primär benötigten Datei- und Druckdienste im Haus bereit. Die Windows-Clients finden Ihren Server ‘server’ und der Server sieht die Clients ‘desktop1’, ‘desktop2’, usw obwohl nirgends Hostnamen und IP Adressen hinterlegt sind. Der Grund dafür ist, dass die Windows basierten Datei- und Druckdienste parallel zu den TCP/IP Mechanismen einen eigens Namensdienst nutzen, die NETBIOS Auflösung.

Für viele Anwendungen reicht dies nicht, speziell für Anwendungen im Internet/IP Umfeld. Wenn man sich mit der SSH auf dem Server anmelden will, muss man dies entweder über die IP Adresse machen oder über einen Hostnamen. Im letzten Fall muss der PC, auf dem der SSH Client aufgerufen wird, in der Lage sein, aus dem Namen eine IP Adresse zu machen. Viele Wege führen nach Rom:

/etc/hosts

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1          localhost.home localhost

192.168.100.1      desktop1
192.168.100.2      desktop2
192.168.100.3      notebook
192.168.100.253    server
192.168.100.254    gateway

Variante 1 – statische HOSTS Datei

Jedes (mir bekannte) Betriebssystem mit TCP/IP Unterstützung kennt eine sogenannte HOSTS Datei. In dieser Datei stehen zeilenweise Einträge, die mit der IP Adresse beginnen, gefolgt von einem oder mehreren über Leerzeichen getrennte Hostnamen. Der hinsichtlich der Server-Konfiguration einfachste Weg ist auf dem Server und jedem Client eine solche Datei anzulegen. Da die Datei statisch ist, muss die TCP/IP Konfiguration auf den Clients ebenfalls statisch sein (der Server sollte sowieso eine statische IP Konfiguration verwenden).

Mit jedem zusätzlichen PC ist die HOSTS Datei auf allen PCs zu erweitern, allerdings hält sich die Zahl der PCs im Heimbereich auch meistens in Grenzen. Sofern eine Kommunikation unter den Client PCs nicht gefragt ist, reicht auf den Clients sogar der Eintrag für den Server und nur auf dem Server ist eine komplette Liste zu pflegen.

Alternative IP Konfiguration (Windows XP)

Variante 2 – DHCP und statischer DNS

Die nächste Variante ist die Verwendung von DHCP, um die Clients automatisch zu konfigurieren sowie die Verwendung eines statischen DNS Servers – also einem DNS Server, bei dem die IP Adressen der Clients fest in einer Tabelle eingetragen sind. Man spart sich die Aktualisierungen auf den Clients, muss aber den DHCP Server so konfigurieren, dass er einem bestimmten Client immer die gleiche IP Adresse gibt. Dies sollte aber für jeden DHCP Server eine leichte Übung sein, die Zuordnung passiert über die Mac-Adresse. Ein guter DSL Router beherrscht dies. Wer nur ein Netzwerk zu Hause betreibt, kann auch problemlos den DSL Router dafür verwenden, im Fall eines zweiten Guest LANs benötigt man dann aber noch einen zusätzlichen DHCP Service für das zweite Netzwerk.

Wenn der DHCP Server auf dem Home Server läuft, heisst dies letztendlich, dass der Server laufen muss, damit der Client PC eine IP Adresse erhält. Da der Home Server aber auch das DNS bereitstellt, sollte er sowieso laufen. Mit einem kleinen Trick kommt man hier aus der Zwickmühle: man trägt auf dem DSL Router in der DHCP Konfiguration als primären DNS Server den Home Server ein, als sekundären den Router selbst. Ist der Home Server aus, nutzt der Client den DSL Router.

Im Fall von Windows XP geht es aber auch ohne den DHCP Server im Router. In den TCP/IP Einstellungen stellt man die automatische Konfiguration ein und erhält dann einen zweiten Kartenreiter, auf dem man eine alternative TCP/IP Konfiguration angeben kann, wenn kein DHCP Service zur Verfügung steht.

Variante 3 – DHCP mit dynamischem DNS

Die nächste Steigerung ist, dass man abgesehen von dem mit einer statischen IP Adresse konfigurierten Server keine weiteren statischen Einträge im DNS macht und alle Clients dynamisch in das DNS einträgt, sobald sie eine IP Adresse erhalten haben. Diesen Eintrag kann entweder der Client machen oder der DHCP Server, der die IP Adresse vergeben hat. Der sicherere Weg ist, dass der DHCP Server den Eintrag vornimmt – der Weg über den Client wirft auch die Frage auf, ob der Server (oder der Admin) eventuell nicht weiss, was er tut.

Dieser Weg dürfte in der Regel nur mit einem DHCP Server auf dem Home Server möglich sein, zumindest wäre es mir neu, wenn ein DHCP Service eines DSL Routers DNS Updates durchführen kann. Aber auch hier gilt wieder: im Fall von Windows XP läßt sich sehr einfach eine Alternativkonfiguration festlegen für den Fall, dass der Home Server aus ist. Hier reicht es dann, als primären DNS Server den Router einzutragen – wenn der Server läuft, kommt die Alternativ-Konfiguration eh nicht zum tragen.

DNS – Der Domain Name Service

Ziel war Variante 3, wobei nur der DHCP Server selbst Einträge im DNS vornehmen soll. Beim Aufsetzen des DNS Servers hat man prinzipiell die Wahl, ob man DNS Anfragen an einen oder mehrere bestimmte andere Server weiterleitet (Forwarding) oder ob man dem Server selbst die gesamte Auflösung überträgt. Ein Forwarding-Server ist hinsichtlich der Konfiguration einfacher, hat aber natürlich die Abhängigkeit von den fest eingetragenen Forward-Servern. Ich habe mich dazu entschieden, einen “vollwertigen” DNS Server aufzusetzen.

/etc/named.conf

// named.conf @ server

include "/etc/rndc.key";

controls {
  inet * allow { localhost; } keys { "rndckey"; };
};

acl "local" {
  192.168.100.0/24;
  192.168.101.0/24;
};

acl "admin" {
  192.168.100.1;
};

options {
  directory       "/var/named";
  dump-file       "/var/named/data/cache_dump.db";
  statistics-file "/var/named/data/named_stats.txt";

  // optional, if outgoing firewall restrictions
  // query-source address * port 53;

  allow-query    { "local"; };
  allow-transfer { "admin"; };
};

zone "." IN {
  type hint;
  file "named.ca";
};

zone "home" IN {
  type master;
  file "home.zone";
  allow-update { key rndckey; };
};


zone "100.168.192.in-addr.arpa" IN {
  type master;
  file "named.100.168.192";
  allow-update { key rndckey; };
};

zone "101.168.192.in-addr.arpa" IN {
  type master;
  file "named.101.168.192";
  allow-update { key rndckey; };
};

zone "localhost" IN {
  type master;
  file "localhost.zone";
  allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
  type master;
  file "named.local";
  allow-update { none; };
};

zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
  type master;
  file "named.ip6.local";
  allow-update { none; };
};

zone "255.in-addr.arpa" IN {
  type master;
  file "named.broadcast";
  allow-update { none; };
};

zone "0.in-addr.arpa" IN {
  type master;
  file "named.zero";
  allow-update { none; };



};

logging {
  channel queries_log {
    file "/var/log/named/named-queries.log";
    severity info;
    print-category yes;
    print-severity yes;
    print-time     yes;
  };

  channel update_log {
    file "/var/log/named/named-update.log";
    severity debug 9;
    print-category yes;
    print-severity yes;
    print-time     yes;
  };

  channel security_log    {
    file "/var/log/named/named-security.log";
    severity  info;
    print-category yes;
    print-severity yes;
    print-time     yes;
  };

  category default  { default_syslog; };

  category queries  { queries_log;  };
  category update   { update_log;   };
  category security { security_log; };
};


# End of file

Oben ist die Hauptkonfigurationsdatei des DNS Servers zu sehen. Die zusätzlich nötigen Konfigurationsdateien sind durch Anklicken der eingebauten Links verfügbar. Gleich am Anfang der Datei wird eine /etc/rndc.key eingebunden. Der DNS Server soll zwar dynamische Updates akzeptieren, aber natürlich nur die vom DHCP Server. Die Berechtigung kann man über IP Adressen regeln oder über Schlüssel, die beiden Seiten bekannt sein müssen. Da sich der Weg über die IP Adressen aushebeln läßt, ist die Schlüsselmethode die bessere. Dazu muss zunächst ein Schlüssel erzeugt werden. Der folgende Befehl erzeugt einen 512 Bit Schlüssel unter dem Namen /etc/rndc.key:

[root@server]# rndc-confgen -a -b 512 -r /dev/random

Der Key wird später auch für die DHCP Konfiguration noch benötigt. Die Anweisung control in der Datei /etc/named.conf veranlasst den Server auf allen Interfaces (*) des Servers auf Control Messages zu antworten, solange sie vom Server selbst kommen (localhost) und mit dem gerade erzeugten Key signiert sind.

Die nächsten beiden Anweisungen in der /etc/named.conf definieren Accesslisten, eine Art Berechtigungsgruppe. Die Gruppe local umfasst alle Clients aus dem Private und Guest LAN, die Gruppe admin nur meinen Desktop-PC. Diese Gruppen werden in dem Optionsbereich genutzt. Anfragen an den DNS Servers dürfen alle Clients im LAN Bereich stellen, einen Zonentransfer darf nur mein PC starten. In der Praxis wird ein Zonentransfer nicht benötigt, ich habe ihn mir für ‘techische Spielereien’ freigeschaltet.

Anschließend werden die Zonen definiert. Da es sich um einen “vollwertigen” DNS Server handelt, der die gesamte Namensauflösung selbst vornimmt, muss man ihm die offiziellen DNS Root-Server bekannt machen (die sich praktisch nie ändern und höchstens alle paar Jahre mal um einen erweitert werden). Dies übernimmt die Definition der Zone “.”.

Die nächsten drei Zonen-Definitionen sind für den LAN Bereich. Hier stellt sich zunächst die Frage nach der Wahl des Domainnamens. Es sollte kein Name sein, der irgendwo bereits offiziell verwendet wird, also kein registrierter Domainname. Damit diese Bedingung auch zukünftig eingehalten wird, sollte es auch ein Name sein, der nach bestem Wissen und Gewissen auch zukünftig nicht registriert wird. Ein offziell für lokale Zwecke freigegebene Name ist “localdomain”. Mir war dieser zu technisch, ich habe daher den Domainnamen “home” verwendet. Da ich nicht davon ausgehe, dass es je ein Länderkürzel mit diesem Namen gehen wird, sollte “home” ebenfalls zukunftssicher sein.

Die “normale” Auflösung eines DNS Namens läuft vom Namen zur IP Adresse. Man gibt also einen Hostnamen an und der DNS Server liefert die dazugehörige IP Adresse zurück (es können auch mehrere sein). Dies ist die Auflösung, die “der Anwender” nutzt. Services selbst nutzen gerne für die Überprüfung der Quelle einer Anfrage die Rückwärtsauflösung, also welcher Name sich hinter einer IP Adresse verbirgt. Eine fehlende Rückwärtsauflösung kann teilweise zu Wartezeiten beim erstmaligen Zugriff auf einen Service führen – je nach Konfiguration des Servers kann es auch passieren, dass ein Service ohne Rückwärtsauflösung nicht genutzt werden kann.

Eine Zone für die Rückwärtsauflösung bezieht sich immer auf ein IP Netzwerk. Die beiden Zonen 100.168.192.in-addr.arpa und 101.168.192.in-addr.arpa definieren dementsprechend die Zonen für das Private und Guest LAN. Bei diesen beiden Zonen sowie auch bei der home Zone werden dynamische DNS Updates zugelassen, sofern diese mit dem richtigen Schlüssel übergeben werden.

In der Datei home.zone wird der DSL Router sowie der Server fest eingetragen, bei beiden ist die IP Adresse auch fest konfiguriert. In der Zone gibt es noch einen MX Eintrag. Dieser Eintrag definiert den zuständigen Mail-Server für die Domäne. Ich habe ihn eingetragen für den Fall, dass ich irgendwann dem Server die Aufgabe übertragen möchte, regelmäßig meine externen POP3 Postfächer abzufragen. In dem Fall könnte man die lokale Domäne für das lokale “Routing” der Servernachrichten nutzen. Stören sollte er nicht.

Die nachfolgenden Zonen-Definitionen sind für Zonen, die ein DNS Server der Vollständigkeiten haben sollte (wobei nicht alle zwingend notwendig sind). Im Fall von Fedora Core 3 werden die dazugehörigen Zonen-Dateien mit dem DNS Server Paket mitinstalliert.

Der letzte Abschnitt behandelt das Logging. Mit den channel Angaben wird jeweils ein Ausgabemedium definiert, in diesem Fall sind dies immer Dateien. Mit den category Angaben wird das Ausgabemedium den einzelnen Kategorien zugewiesen. Zumindest für die Testphase empfiehlt sich ein Logging der Kategorien queries und update, die Kategorie security ist nie verkehrt.

Wichtig ist, dass die Logdateien – z.B. in Form von leeren Dateien – existieren müssen, damit der DNS Server sie auch nutzt. Dazu wiederrum muss man wissen, wo sie wirklich liegen. DNS Server waren schon häufiger Opfer von Attacken und selbst ein DNS Server, der von aussen nicht erreichbar ist, ist von aussen beeinflussbar (z.B. kann durch die Referenzierung von Bildern auf Webseiten der lokale DNS Server veranlasst werden, einen bestimmten externen Server zu kontaktieren). Es empfiehlt sich daher immer, den DNS Server in einer chroot-Umgebung laufen zu lassen, also einer Art Sandbox. Dazu ist dieser mit der Option ‘-t’ zu starten:

[root@server]# /usr/sbin/named -u named -t /var/named/chroot

Der Fedora Core 3 richtet den DNS Server genauso so ein und startet ihn mit dem angegebenen Befehl. Der DNS Server läuft damit mit dem User ‘named’ und kann ausserhalb des Verzeichnisses /var/named/chroot nichts mehr sehen. Das heisst natürlich auch, dass alle benötigten Dateien physikalisch unterhalb des chroot-Verzeichnisses liegen müssen, die Logdateien landen damit effektiv in dem Verzeichnis /var/named/chroot/var/log/named. Wer den Fedora Core 3 verwendet, findet alles bereits fertig eingerichtet vor.

Der Fedora Core 3 verwendet bereits SELinux, das sind Erweiterungen für eine verbesserte Sicherheit. Eine Einstellung hier veranlasst ggf. dem DNS Server die Schreibrechte auf die Zonendateien zu entziehen. Diese sind aber notwendig, damit dynamische Updates vom DNS Server gespeichert werden können. In der Datei /etc/selinux/targeted/booleans ist der Wert named_write_master_zones auf 1 zu setzen:

httpd_enable_cgi=1
httpd_enable_homedirs=1
httpd_ssi_exec=1
named_write_master_zones=1
httpd_unified=1
httpd_tty_comm=0

Zeit, den DNS Server zu starten. Eventuelle Fehlermeldungen können dem Systemlog entnommen werden:

[root@server]# mkdir -p /var/named/chroot/var/log/named
[root@server]# touch /var/named/chroot/var/log/named/queries_log
[root@server]# touch /var/named/chroot/var/log/named/update_log
[root@server]# touch /var/named/chroot/var/log/named/security_log
[root@server]# cd /var/log/named
[root@server]# ln -s /var/named/chroot/var/log/named/queries_log
[root@server]# ln -s /var/named/chroot/var/log/named/update_log
[root@server]# ln -s /var/named/chroot/var/log/named/security_log
[root@server]# /etc/init.d/named start
Starting named:                                            [  OK  ]
[root@server]# tail -20 /var/log/messages

/etc/resolv.conf

nameserver 192.168.100.253
domain home

Wenn der DNS Server rund läuft, muss man noch dafür sorgen, dass Linux ihn bei jedem Systemstart startet. Dies geht beim Fedora Core sehr einfach über das Text Mode Setup Utility (setup). Anschließend sorgt eine passende /etc/resolv.conf Konfiguration noch dafür, dass der Server sich selbst nutzt, wenn er DNS Anfragen startet.

DHCP – Automatische IP Konfiguration der Clients

DHCP steht für ‘Dynamic Host Configuration Protocol’ und tut im Prinzip genau das, wofür es steht: es konfiguriert automatisch alle Clients im Netzwerk, zumindest hinsichtlich der TCP/IP Einstellungen. Damit ist nicht alleine die Vergabe von IP Adressen gemeint, über DHCP werden auch Einstellungen wie das Default Gateway, der DNS Server oder der WINS Server vergeben. Auf der rechten Seite ist die Konfiguration zu sehen.

/etc/dhcpd.conf

# dhcpd.conf @ server

authoritative;

ddns-update-style          interim;
ddns-updates               on;
ddns-domainname            "home";

update-static-leases       true;

key "rndckey" {
  algorithm hmac-md5;
  secret "7OgN/HqPgBkkk1GGgzIldBmhrIQbJt+nCzlX5O...
};

ignore client-updates;

subnet 192.168.100.0 netmask 255.255.255.0 {

  option domain-name          "home";
  option domain-name-servers  192.168.100.253;
  option routers              192.168.100.254;
  option subnet-mask          255.255.255.0;
  option broadcast-address    192.168.100.255;
  option netbios-name-servers 192.168.100.253;

  # Known clients only
  pool {
    range 192.168.100.1 192.168.100.127;
    max-lease-time 1209600;
    max-lease-time 86400;
    deny unknown-clients;
  }

  # Known hosts
  host desktop1 {
    hardware ethernet 01:7F:2D:31:86:C1;
    fixed-address     192.168.100.1;
  }
  host desktop2 {
    hardware ethernet 01:7F:2D:31:86:C2;
    fixed-address     192.168.100.2;
  }
  host notebook {
    hardware ethernet 01:7F:2D:31:86:C3;
    fixed-address     192.168.100.3;
  }
}

subnet 192.168.101.0 netmask 255.255.255.0 {

  option domain-name          "home";
  option domain-name-servers  192.168.101.254;
  option routers              192.168.101.254;
  option subnet-mask          255.255.255.0;
  option broadcast-address    192.168.101.255;
  option netbios-name-servers 192.168.101.254;

  pool {
    range 192.168.101.128 192.168.101.191;
    max-lease-time 3600;
  }
}

zone home. {
  primary 127.0.0.1;
  key "rndckey";
}

zone 100.168.192.in-addr.arpa. {
  primary 127.0.0.1;
  key "rndckey";
}

zone 101.168.192.in-addr.arpa. {
  primary 127.0.0.1;
  key "rndckey";
}

# End of file

Mit dem authoritative Statement sagt man dem DHCP Server, dass er für die weiter unten konfigurierten Netzwerke der einzig zuständige ist. Damit entzieht er z.B. einem Client, der vorgibt von einem DHCP Server eine Lease bekommen zu haben, diese, wenn sie nicht von ihm stammt. Mit einer Lease wird eine von einem DHCP Server übermittelte Konfiguration bezeichnet.

Mit den nächsten drei Anweisungen wird das für dynamische DNS Updates verwendete Verfahren festgelegt, die Updates werden aktiviert und der DNS Domain wird definiert. Die Anweisung updates-static-leases weist den DHCP Server an, auch statische Einträge in das DHCP einzutragen – also Clients, bei denen die IP Adresse fest an die Mac-Adresse gekoppelt ist. Weiterhin taucht jetzt wieder der bei der DNS Konfiguration erzeugte Schlüssel auf, damit sich der DHCP Server sauber beim DNS Server authentifizieren kann. Die Anweisung ignore client-updates verhindert, dass ein Client mitbestimmen kann, was der DHCP Server ins DNS einträgt.

Die Netze, die der DHCP Server bedienen soll, werden mit der subnet Anweisung eingestellt. In meinem Fall ist das das Netzwerk 192.168.100.0 für das Private und 192.168.101.0 für das Guest LAN (jeweils Netzmaske 255.255.255.0).

Die option Anweisungen definieren jeweils den DNS Domainnamen (unter Windows als DNS Suffix bezeichnet, wenn man ipconfig /all aufruft), den Domain Name Server, das Default Gateway, die Netzmaske, die Broadcast-Adresse sowie den WINS Server. Der WINS Server ist nur dann notwendig, wenn man mehr als ein IP Netzwerk betreibt. Die Windows Datei- und Druckdienste nutzen primär für die Namensauflösung das NETBIOS und damit Broadcast-Mechanismen. Ein Broadcast wird jedoch immer nur in dem jeweils aktuellen IP Netzwerk verteilt, ein Client im Private LAN würde damit einen Client im Guest LAN nicht sehen. Um das Problem zu lösen, muss man den Samba Service gleichzeitig auch als WINS Service nutzen. Er beantwortet dann stellvertretend die Anfragen und macht die Clients gegenseitig sichtbar.

In einem IP Netzwerk steht einem DHCP Server in der Regel eine bestimmte Anzahl an IP Adressen für die Vergabe zur Verfügung. Diese IP Adressen werden mit der Pool-Anweisung festgelegt. In dem Private LAN sorgt die Anweisung deny unknown-clients dafür, dass nur bekannte Clients überhaupt eine IP Adresse bekommen. Wer will kann mit

pool {
  range 192.168.100.128 192.168.100.191;
  max-lease-time 3600;
  allow unknown-clients;
}

einen Pool für nicht registrierte Clients definieren oder einfach die deny-Anweisung löschen, wenn kein Bedarf für eine Unterscheidung besteht.

Die nachfolgenden Host-Anweisungen registrieren die eigenen Clients. Die Registrierung erfolgt über die Mac-Adresse, gleichzeitig wird jeweils auch eine IP Adresse fest zugeordnet. Damit ist zum einem sichergestellt, dass der Client immer diese IP Adresse erhält – zum anderen, dass kein anderer Client sie bekommt. Da teilweise Zugangsberechtigungen – z.B. der Zugang zu administrativen Webinterfaces – über IP Adressen eingestellt werden, ist dies ein sehr wichtiger Aspekt.

Die Konfiguration für das Guest LAN sieht etwas einfacher aus. Hier gibt es keine registrierten Clients, es werden einfach die per DHCP übermittelten Konfigurationsdaten festgelegt und ein Pool an IP Adressen eingestellt.

Die letzten Anweisungen definieren die DNS Zonen, für die der DHCP Server Aktualisierungen vornehmen soll und weisst ihnen jeweils den oben definierten Schlüssel zu. Nun kann der DHCP Server gestartet werden, Fehlermeldungen würden wieder im Systemlog auftauchen:

[root@server]# /etc/init.d/dhcpd start
[root@server]# tail -20 /var/log/messages

Wenn der DHCP Server rund läuft, muss man noch dafür sorgen, dass Linux ihn bei jedem Systemstart startet. Dies geht beim Fedora Core sehr einfach über das Text Mode Setup Utility (setup).

Wer seinen Windows XP PC auch unabhängig vom Server nutzen möchte, sollte dort eine alternative Konfiguration eintragen (mit den gleichen Daten, wie sie auch der DHCP Server verwendet). Ein Beispiel wurde am Anfang dieser Seite gegeben.

Der Server stellt nun alle relevanten LAN Dienste bereit. Die nächsten Anforderungen haben irgendwie mit dem Internet zu tun. Entweder halten Dienste permanent eine Verbindungs ins Internet aufrecht (z.B. der IRC Proxy) und sind darüber prinzipiell angreifbar, oder es soll direkt im Internet ein Service bereitgestellt werden (z.B. der SSH Login). Diese Dienste sollen nicht direkt auf dem Hostsystem laufen, sondern innerhalb einer Sandbox in Form eines User Mode Linux. Das nächste Kapitel befasst sich damit.

20 Kommentare zum Artikel “Home Server, Teil 5 – Konfiguration: DHCP & Dynamischer DNS”

  1. Sehr schön geschrieben Meph!
    Du hast Deinen Beruf verfehlt! :)
    T.

  2. nirgens

    zu

    nirgends

    … sehr gute anleitung, gratulation

  3. ned schlecht, kann man lassen *gg*

  4. Ist es möglich, einen alternativen Router einzubinden: Dsl (Fritz Box) fällt aus, passiert bei mir leider öfter, ISDN (Opencom Telefonanlage) als Notbetrieb per Internet by call? Momentan stelle ich immer die Konfigurierung per DHCP aus und trage die Opencom statisch als Gateway bzw DNS ein, muß das dann allerdings bei jedem Rechner tun.

    • Wenn ich dich richtig verstehe, möchtest du den DHCP des Routers nutzen. Das geht prinzipiell sehr einfach: DHCP auf dem Server deaktivieren, im Router aktivieren. Im Router müßtest du dann als DNS Server deinen lokalen Server eintragen, damit die lokale Auflösung klappt. Die lokalen Hostnamen müßtest du zudem fest im DNS eintragen, da dynamisches DNS von den mir bekannten Routern (meines Wissens, nie konkrekt versucht) nicht unterstützt wird.

  5. Wird DHCP unbedingt benötigt?

    • Nein.

      DHCP sorgt dafür, dass die PCs im Netzwerk automatisch eine IP Adresse und begleitende Parameter bekommen (Router, usw). Alternativ kannst du diese Daten bei jedem PC fest einstellen oder diese Aufgabe einem eventuell vorhandenen DSL Router überlassen.

      Die Kombination aus DHCP und DNS auf dem Server hat z.B. den Vorteil, dass sich auch die lokalen PCs im Netzwerk mit Namen ansprechen lassen.

  6. Hab da auch mal noch ne kleine Frage:
    habe hier auch nen dhcpd laufen..will jedoch nicht, dass die IPs dauerhaft an MACs gebunden werden….hatte nämlich das Problem, dass allen 11 IPs in der Range eine MAC zugewiesen war und somit keine neuen Rechner (mit neuen MACs) den DHCP-Dienst nutzen konnten…
    Die Range will ich nicht vergrößern.

    Gibts da ne Möglichkeit die Zuordnung der IPs zu MACs zu löschen?

    Vielen Dank schonmal für die Antwort. :)

    Flori

    • Wenn du die ‘fixed-address’ Zeilen in den ‘host’ Definitionen weg lässt, sollte er die IP Adressen dynamisch verteilen (bestes Wissen und Gewissen, nicht getestet).

  7. Hallo,
    Habe da auch mal eine Frage und zwar möcht ich mir auch so einen Homeserver basteln. Nun hänge ich bei der konfiguration des DNS Servers fest. Ich hab SUSE 11.0 als system.
    Der Server lässt sich starten aber wenn ich mir so die message Datei anschau glaube ich nicht das alles so richtig funktioniert.
    Hier mal ein Auszug:

    May 22 14:56:40 Homeserver named[9895]: automatic empty zone: 254.169.IN-ADDR.ARPA
    May 22 14:56:40 Homeserver named[9895]: automatic empty zone: 2.0.192.IN-ADDR.ARPA
    May 22 14:56:40 Homeserver named[9895]: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA
    May 22 14:56:40 Homeserver named[9895]: automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
    May 22 14:56:40 Homeserver named[9895]: automatic empty zone: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
    May 22 14:56:40 Homeserver named[9895]: automatic empty zone: D.F.IP6.ARPA
    May 22 14:56:40 Homeserver named[9895]: automatic empty zone: 8.E.F.IP6.ARPA
    May 22 14:56:40 Homeserver named[9895]: automatic empty zone: 9.E.F.IP6.ARPA
    May 22 14:56:40 Homeserver named[9895]: automatic empty zone: A.E.F.IP6.ARPA
    May 22 14:56:40 Homeserver named[9895]: automatic empty zone: B.E.F.IP6.ARPA
    May 22 14:56:40 Homeserver named[9895]: command channel listening on 0.0.0.0#953
    May 22 14:56:40 Homeserver named[9895]: zone 0.0.127.in-addr.arpa/IN: loaded serial 42
    May 22 14:56:40 Homeserver named[9895]: named.100.168.192:3: SOA record not at top of zone (100.168.192.in-addr.arpa.32100.168.192.in-addr.arpa)
    May 22 14:56:40 Homeserver named[9895]: zone 32100.168.192.in-addr.arpa/IN: loading from master file named.100.168.192 failed: not at top of zone
    May 22 14:56:40 Homeserver named[9895]: named.200.168.192:2: SOA record not at top of zone (200.168.192.in-addr.arpa.200.168.192.in-addr.arpa)
    May 22 14:56:40 Homeserver named[9895]: zone 200.168.192.in-addr.arpa/IN: loading from master file named.200.168.192 failed: not at top of zone
    May 22 14:56:40 Homeserver named[9895]: home.zone:2: SOA record not at top of zone (home.home)
    May 22 14:56:40 Homeserver named[9895]: zone home/IN: loading from master file home.zone failed: not at top of zone
    May 22 14:56:40 Homeserver named[9895]: zone localhost/IN: loaded serial 42
    May 22 14:56:40 Homeserver named[9895]: running

    Ich kann mit der fehlermeldung “not at top of zone” nichts anfangen. Ich denke mal ich lasse das Gastserver und den Homeserver beide als master laufen und das dies probleme bereitet. Bin mir aber nicht Sicher da ich noch ein Anfänger bin was Linux betrifft.

    Danke schon mal im Vorraus für die Hilfe

    Gruss

  8. hallo,
    hab da ein verständnisproblem mit der zonendatei “named.101.168.192” dort hast du den gast server ja auf die 192.168.100.1 verwiesen (eintrag :$ORIGIN 100.168.192.in-addr.arpa.
    1 PTR server-g.)
    d.h. der rechner 1 wäre gleichzeitig dein gastserver?
    gruss

    • Ja.

      Der Server hat zwei Netzwerkschnittstellen, eine davon hängt im Gast-Netzwerk.

      • ok, soweit hab ich es verstanden, aber hattest du nicht 192.168.101.254 als gastserver? Habe das bei mir auch ausprobiert mit der konfiguration und er zeigt mir dort eine fehlermeldung”ignoring out of zone data”
        also so wie ich das bis jetzt versanden hatte müsste es doch so aussehen:

        $ORIGIN 101.168.192.in-addr.arpa.
        254 PTR server-g.

        gruss

  9. Danke. Sowas hab ich gesucht

Schreibe einen Kommentar


Beim Speichern ihres Kommentars wird auch ihre IP Adresse gespeichert (nur für den Website-Betreiber einsehbar)!