Wir haben bis jetzt alle Dienste angelegt, die ein Firewallrouter braucht um ein Netzwerk vom Internet abzuschotten und Daten von Innen nach Aussen weiterzuleiten.
Was uns jetzt noch fehlt ist die Namensauflösung. Mit wh1te-rabbit.de kann unser System noch nicht umgehen, also zeigt unser Browser auch noch keine Internetseiten an, obwohl wir eigentlich schon verbunden sind.
Auch die E-Mails können noch nicht empfangen oder versendet werden, weil in Deinem E-Mail Programm wahrscheinlich ein Name wie imap.meinprovider.de für den Empfang eingetragen ist, und keine IP.
Dem helfen wir jetzt ab und installieren einen Nameserver, Bind9. Wenn wir mehr als einen Tag pause gemacht haben wieder mit apt update zuvor…bitte.
gateway: ~ #apt install bind9
Zum Thema Nameserver möchte ich etwas ausholen:
Was macht der Nameserver im Detail? Nehmen wir zunächst das Verhalten des Nameservers auf einem Plasterouter. Dort nimmt er die Rolle eines sogenannten Cache-Forward ein.
Das heisst, er nimmt die Anfragen aus dem lokalen Netz entgegen und reicht sie weiter an den Nameserver des Internetproviders, wenn das nicht geändert wurde. Der kann jetzt entweder die Anfrage direkt beantworten, oder er fragt den nächsthöheren Nameserver, usw, bis die Anfrage beantwortet werden kann. Nun gibt er die Antwort an den anfragenden Rechner weiter und speichert die Antwort zusätzlich in seinem „Cache“ für eine gewisse Zeit. Bei der nächsten Anfrage zu dieser Adresse antwortet er dann direkt.
Frage: wh1te-rabbit.de –> Nameserver antwortet –> 81.169.232.111 –> unser Browser kann nun wh1te-rabbit.de erreichen.
Da diese Anfragen unverschlüsselt laufen, kann theoretisch jeder unsere Anfragen mitlesen. In jedem Fall aber sieht der Internetprovider alle Internetseiten die wir besuchen.
Stört Dich das? Vertraust Du ihm? Deine Entscheidung.
Wir haben aber die Wahl welche Nameserver wir anfragen wollen, Internetprovider, Google ( meistens schneller ) oder Cloudflare?
Cloudflare ist auch schnell, gibt uns dazu ein Privacy-Versprechen. Es gibt noch viele weitere Nameserver, teils mit Blockingservices, mit und ohne Privacy-Versprechen, mit und ohne Verschlüsselung.
Hier muss grundsätzlich unterschieden werden zwischen der verschlüsselten Übertragung der Anfrage und der Absicherung der Namensauflösung selber durch Zertifikate.
Letzeres, DNSsec, muss vom Provider umgesetzt werden. In der Schweiz läuft dies schon ganz gut, in Deutschland sind wir wie so oft sehr weit hinterher. Die Provider scheuen natürlich diesen Aufwand solange der Nutzer diesen nicht einfordert und andernfalls halt abwandert zu anderen Providern, die dies schon umsetzen. wh1te-rabbit.de ist z.B. bei Strato gehostet und Strato liefert auf Nachfrage seit Jahren sinngemäß die immergleiche Standardantwort:
“ Wir wissen das, wir könnten auch, aber wir machen nix. „
Wofür soll das denn überhaupt gut sein?
DNSsec sichert den Namen mit einem Zertifikat ab, ganz ähnlich wie eine Webseite abgesichert wird. Hierdurch wird z.B. das sogenannte DNS-Hijacking ( Namens-Entführung ) verhindert. Der Angreifer setzt sich vor den Nameserver der angefragt wird und liefert eine falsche IP für die gewünschte Webseite, man landet nicht im gewünschten Webshop, sondern in einer Kopie ganz woanders. Nun können Logindaten, Bestellungen, Bezahlungen etc. ganz einfach abgefangen werden.
Wären alle Namen jedoch mit einem vertrauenswürdigen Zertifikat abgesichert, wäre dies nicht möglich.
Aber die Webseiten sind doch abgesichert?
Theoretisch ja, aber stell Dir vor, der Angreifer leitet Dich auf eine Fake-Kopie um, die garnicht verschlüsselt ist, merkst Du das? Der Browser wird nicht unbedingt meckern…!
Die verschlüsselte Übertragung ist ein anderes Konzept, es werden nicht die Namen selber zertifiziert und deren Echtheit gewährleistet, sondern nur die Anfrage beim Nameserver verschlüsselt. Dies geht auf zwei Wegen,
DoT ( DNSoverTLS ) und
DoH ( DNSoverHTTPS )
Im Gegensatz zu DNSsec kann dies Bind9 nicht und brauch weitere Unterstützung durch nachgeschaltete Dienste wie Stubby und/oder DNScrypt. Das Konzept läuft hier wie folgt ab:
Die Einrichtung so einer Konfiguration darf ich später in den Goodies darstellen, hier soll das Prinzip nur erwähnt werden. Damit kann auf jeden Fall ausser dem Nameserver selber keiner mehr unsere DNS-Historie aufzeichnen und auswerten.
Daneben kann unser Nameserver aber auch Namen in unserem Heimnetz auflösen, so daß wir uns keine IP’s mehr merken müssen, z.B. für das NAS, die Kamera am Eingang usw.
Und zu guter Letzt kann unser Nameserver auch filtern.
Es gibt feine Listen im Netz für bekannte Webseiten, die schädlichen Inhalt oder Werbung ( ein Großteil der Malware wird sogar über Werbung ausgeliefert ) verteilen.
Unser Nameserver kann uns also auch schützen, sicher nicht zu 100%, aber einen großen Teil an Schadsoftware kann er fernhalten.
Ganz nebenbei erhalten wir auch ein Stück Werbepause zurück.
Man kennt es sicher: Die Seite der Onlinezeitung hat geladen, man liest bereits im Artikel, und dann geht das „Adhopping“ los.
Werbung wird nachgeladen und der Text „springt“ aus dem Blick.
Unser Nameserver wird dieses Nachladen umleiten ins „Nirwana“ und – jetzt kommt das Beste – die viele Webseiten und Apps merken nichts davon!
Dieses Goodie werden wir auch später gesondert betrachten, sowohl die Variante mit einer eigenen „RPZ“, als auch die Variante mit einem zusätzlichen Raspberry Pi und „Pi-Hole“ und seinen zusätzlichen Möglichkeiten.
ok, genug geschwafelt, weiter im Text:
gateway: ~ #cd /etc/bind
gateway: /etc/bind #ls
bind.keys db.127 db.empty named.conf named.conf.local rndc.key
db.0 db.255 db.local named.conf.default-zones named.conf.options zones.rfc1918
gateway: /etc/bind #
Zwei Dateien interessieren uns:
named.conf.local und named.conf.options
Drei ( Vier mit extra Domain für zweites.netz ) Dateien werden wir für unser lokales Netz erstellen:
erstes.netz.db, ( zweites.netz.db ), 0.0.10.in-addr-arpa und 1.0.10.in-addr-arpa
gateway: /etc/bind #nano named.conf.options
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// forwarders {
// 0.0.0.0;
// };
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation auto;
listen-on-v6 { any; };
};
Als erstes fällt uns auf: Die Raute kommentiert nicht mehr, es sind zwei slashes //
Wir ändern wie folgt:
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
forwarders {
1.1.1.1; 1.0.0.1;
};
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-enable yes;
dnssec-validation auto;
listen-on-v6 { none; };
listen-on { 127.0.0.1; 10.0.0.1; 10.0.1.1; };
allow-query { 127.0.0.1; 10.0.0.0/24; 10.0.1.0/24; };
};
speichern und schliessen
Was haben wir gemacht?
Die sogenannten Forwarder eingetragen, hier Cloudflare. Gleich zwei, kann nicht schaden.
Dort wird gefragt wenn wir was nicht wissen. Am Plasterouter und am Provider vorbei. Cloudflare verspricht, keine Anfragen zu speichern oder zu personalisieren. Deine Entscheidung! 8.8.8.8 von Google geht genauso wie jeder andere Nameserver. Suche nach Nameservern; Du wirst Listen mit hunderten Einträgen finden.
dnssec-enable = Ja, das wollen wir aktivieren
dnssec-validation = Können DNS-Namen validiert werden? Mach das automatisch wenn es geht. ( Wir haben bereits key Dateien, das Thema entwickelt sich aber weiter, im Auge behalten! Webseiten sind inzwischen fast immer verschlüsselt, DNS-Anfragen leider noch nicht. Während die Verschlüsselung einer Webseite dem Webseitenbetreiber obliegt, muss die Verschlüsselung der Namensauflösung vom Hoster bereitgestellt werden. Hier ist Deutschland leider noch Entwicklungsland, die Schweiz macht es vorbildlich – es liegt am Provider. Strato wird z.B. mit seinen Standardausreden zu dem Thema langsam zum echten Ärgernis! Ich sage mal, die sind einfach zu faul oder zu geizig und können es sich leisten, da wir auch zu faul sind umzuziehen wenn sich da nichts tut… genau, ich auch……weiter:
Lausche auf Anfragen auf keinem IPv6 Interface ( wir haben eh keins )
Lausche auf Localhost, eth1 und eth2 auf DNS Anfragen, aber NICHT auf eth0!!
Erlaube Anfragen von Localhost, erstes.netz 10.0.0.0 und (zweites.netz) 10.0.1.0
Mit einem Neustart von Bind können Browser surfen und Mailprogramme arbeiten…
gateway: /etc/bind #systemctl restart bind9
Was auch immer nun unser Plasterouter am Anfang in die resolv.conf eingetragen hat, das ändern wir jetzt zu:
gateway: /etc/bind #nano /etc/resolv.conf
domain erstes.netz search erstes.netz. [zweites.netz.] Punkte am Ende nicht vergessen! nameserver 127.0.0.1 nameserver 1.1.1.1 [oder Deine Wahl, kann auch der Plasterouter bleiben. Den zweiten Eintrag nimmt er nur, wenn er den ersten, sich selber, nicht erreichen kann.] speichern und schliessen
Für einen Test fehlt uns noch nslookup:
gateway: /etc/bind #apt install dnsutils
gateway: /etc/bind #nslookup google.de
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
Name: google.de
Address: 172.217.168.163
Name: google.de
Address: 2a00:1450:4003:803::2003
gateway: /etc/bind #
Das läuft!
Unser Server fragt brav seinen eigenen Nameserver auf 127.0.0.1 (Localhost) und bekommt seine Antwort. Das hier auch die IPv6 Adresse von Google mitgeliefert wird, brauch uns nicht stören. Damit kann in unserem Netz keiner mehr was anfangen. Solange wir noch eine IPv4 Adresse bekommen, ist alles paletti. Das wird zwar nicht ewig so bleiben, aber ein definitives Ende ist noch nicht abzusehen.
So, wir sind online, jetzt zu unseren Zonendateien:
Eine Zone besteht immer aus zwei Teilen, dem Lookup – der Name wird in eine IP-Adresse aufgelöst, und dem Reverse-Lookup – die IP-Adresse wird in Namen aufgelöst.
Viele Dienste geben sich mit dem Lookup zufrieden, manche bestehen aber auch auf einem sauberen Reverse.
Für den Lookup sind die Name.db Dateien zuständig, für den Reverse die *.in-addr.arpa Dateien. Die Zuordnung dieser Zonen für unser lokales Netz findet in der named.conf.local statt.
Starten wir mit der Lookup Datei:
gateway: /etc/bind #nano erstes.netz.db
und tragen wie folgt ein:
$TTL 604800 @ IN SOA gateway.erstes.netz. root.erstes.netz. ( 8 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS localhost. @ IN A 127.0.0.1 gateway IN A 10.0.0.1 gateway IN A 10.0.1.1 meinpc IN A 10.0.0.2 ap1 IN A 10.0.0.100 ap2 IN A 10.0.1.100
Das sieht mal wieder sehr kryptisch aus, eine schöne ausführliche Erläuterung findest Du HIER. Zunächst tragen wir nur die Clients ein, die wir vorhin im DHCP mit IP-Adressen versehen haben. Später kommen hier alle weiteren Clients im Netz dazu, die wir im DHCP eintragen. Der DHCP ist auch in der Lage die aus dem Range zugeordneten IP-Adressen mit den von den Clients gemeldeten Hostnamen automatisch in die Zonendateien einzutragen, und auch wieder zu löschen, wenn die Zuteilung ( Lease ) abgelaufen ist.
Darauf gehe ich aber aus zwei Gründen nicht ein:
1. Unser Netz wird eher statisch sein und eher als Ausnahme eine IP aus dem Range bekommen. Stichwort Kontrolle. Wie soll ich mein Netz kontrollieren, wenn dort wieder mir unbekannte Systeme ihr Unwesen treiben?
2. Erfahrungsgemäss kommen die Geräte mit den abenteuerlichsten Namen daher. Was hilft es uns, wenn der DNS einen Namen wie PC-5734 oder fünfmal Samsung-irgendwas auflöst?
Ein Gerät kann mit den verschiedensten Namen im Netz unterwegs sein:
der eigene Hostname
der von uns zugeteilte DNS Name
der sich selbst zugewiesene mDNS Name, oft mit .local
der SMB Name mit SMB Domain, oft WORKGROUP
So, und was soll jetzt der ganze Quatsch?
Schnell hat heutzutage ein Netz viele Clients und auch im Heimnetz ist es praktisch sich statt IP-Adressen besser einzuprägende Namen zu merken.
So kann man mit einem sauberen DNS z.B.:
Eine Kamera mit cam1.zweites.netz oder eingangscam oder garagencam aufrufen.
Eine Webseite zur Kameraüberwachung mit zoneminder.zweites.netz aufrufen
Die Verwaltungsseite des Satellitenreceivers mit openatv.erstes.netz aufrufen
uswusf….
Tatsächlich werden nach meiner Erfahrung rund 80% der Namen im Netz nicht wirklich gebraucht. Man müsste sie also auch nicht im Nameserver eintragen.
Dem reibungslosen Ablauf eines Netzwerks tut das keinen Abbruch.
20% ruft man schonmal auf, 5% davon öfter.
Wie gesagt, meine Erfahrung. Grundsätzlich gilt:
Je mehr Geräte im Netz eine Verwaltungsseite für einen Browser darstellen, desto mehr wird ein Name helfen.
Aber auch andere Dienste können mit den Namen was anfangen:
Kann Deine digitale Fernsehzeitung Deinen Fernseher umschalten?
Dann kannst Du ihr auch TV-Wohnzimmer sagen statt 10.0.0.88.
Bevor wir weitergehen, wieder die Anmerkung zur Domain im Heimnetz:
Es ist NICHT notwendig zwei Domains ( erstes.netz, zweites.netz ) aufzusetzen um eine saubere Namensauflösung auch in zwei oder mehr Subnetzen zu bekommen. Kann man aber machen, das bleibt Dir überlassen.
Wenn Du das möchtest, dann erstellst Du jetzt eine zweite Datei „zweites.netz.db“ analog zu „erstes.netz.db“ mit den jeweils dazu passenden Einträgen.
Wer es gemerkt hat, oben haben wir bereits beide Subnetze in erstes.netz.db aufgenommen.
Beispiel für getrennte Domains:
$TTL 604800 @ IN SOA gateway.erstes.netz. root.erstes.netz. ( 8 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS localhost. @ IN A 127.0.0.1 gateway IN A 10.0.0.1 meinpc IN A 10.0.0.2 ap1 IN A 10.0.0.100
$TTL 604800 _@ IN SOA gateway.zweites.netz. root.zweites.netz. ( 8 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL _; _@ IN NS localhost. _@ IN A 127.0.0.1 _gateway IN A 10.0.1.1 _ap2 IN A 10.0.1.100 _Achtung, Fehler! wird weiter unten erklärt...
Entsprechend würden diese Dateien jetzt:
erstes.netz.db und zweites.netz.db
heissen.
Jetzt die Reverse Dateien, diese MÜSSEN immer getrennt für jedes Subnetz geführt werden.
gateway: /etc/bind #nano 0.0.10.in-addr.arpa
und tragen wie folgt ein:
; ; BIND reverse data file for local loopback interface ; $TTL 604800 @ IN SOA gateway.erstes.netz. root.erstes.netz. ( 8 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS gateway. 1.0.0 IN PTR localhost. 1 IN PTR gateway.erstes.netz. 2 IN PTR meinpc.erstes.netz. 100 IN PTR ap1.erstes.netz.
Und analog für das zweite Subnetz 10.0.1.0….bemerke: die IP-Adressen werden rückwärts gelesen….
gateway: /etc/bind #nano 1.0.10.in-addr.arpa
und tragen wie folgt ein:
; ; BIND reverse data file for local loopback interface ; $TTL 604800 @ IN SOA gateway.erstes.netz. root.erstes.netz. ( 8 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS gateway. 1.1.0 IN PTR localhost. 1 IN PTR gateway.erstes.netz. 100 IN PTR ap2.erstes.netz.
Beachte alle Punkte, KEINER ist zufällig da, wird einer vergessen, läuft schon nichts mehr wie es soll!
Im Falle der zweiten Domain wäre jetzt in der Datei 1.0.10.in-addr.arpa jedes „erstes.netz“ durch „zweites.netz“ zu ersetzen.
Damit unser Nameserver nun auch weiss das er überhaupt Zonen im Heimnetz hat, die er auflösen soll, müssen wir ihm das noch mitteilen. Dazu bearbeiten wir die Datei named.conf.local:
gateway: /etc/bind #nano named.conf.local
Das sieht unkonfiguriert erstmal so aus: // // Do any local configuration here // // Consider adding the 1918 zones here, if they are not used in your // organization //include "/etc/bind/zones.rfc1918";sie sind genutzt... Nun ergänzen wir: zone "erstes.netz" { type master; file "/etc/bind/erstes.netz.db"; }; Im Falle von zwei Domains: zone "zweites.netz" { type master; file "/etc/bind/zweites.netz.db"; }; // oder eben weglassen und hier weiter: zone "0.0.10.in-addr.arpa" { type master; file "/etc/bind/0.0.10.in-addr.arpa"; }; zone "1.0.10.in-addr.arpa" { type master; file "/etc/bind/1.0.10.in-addr.arpa"; };
Theoretisch war es das, allerdings ist ein Fehler noch im System.
Den zeige ich jetzt ganz bewusst auf, um zu veranschaulichen wie man hier vorgehen kann:
Wir haben die Dateien als root erstellt und damit in den Berechtigungen den Default root:root ( user:gruppe ) gesetzt.
Schauen wir was passiert:
gateway: /etc/bind #systemctl restart bind9.service
gateway: /etc/bind # systemctl status bind9.service
gateway: /etc/bind # systemctl restart bind9.service gateway: /etc/bind # systemctl status bind9.service ● bind9.service - BIND Domain Name Server Loaded: loaded (/lib/systemd/system/bind9.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2019-11-06 14:47:10 CET; 2s ago Docs: man:named(8) Process: 1083 ExecStart=/usr/sbin/named $OPTIONS (code=exited, status=0/SUCCESS) Main PID: 1084 (named) Tasks: 5 (limit: 1140) Memory: 12.6M CGroup: /system.slice/bind9.service └─1084 /usr/sbin/named -u bind Nov 06 14:47:10 gateway named[1084]: /etc/bind/erstes.netz.db:2: no current owner name Nov 06 14:47:10 gateway named[1084]: zone erstes.netz/IN: loading from master file /etc/bind/erstes.netz.db failed: no owner Nov 06 14:47:10 gateway named[1084]: zone erstes.netz/IN: not loaded due to errors.
Hab ich schon erwähnt das Linux sehr geschwätzig ist?
Der Nameserver läuft, aber die Zonen konnten wegen einem fehlenden Besitzer nicht geladen werden.
Na, danke, dann schauen wir mal:
gateway: /etc/bind #l
insgesamt 60
-rw-r--r-- 1 root bind 651 Nov 6 14:31 0.0.10.in-addr.arpa
-rw-r--r-- 1 root bind 598 Nov 6 14:38 1.0.10.in-addr.arpa
-rw-r--r-- 1 root root 2761 Jun 21 11:24 bind.keys
-rw-r--r-- 1 root root 237 Jun 21 11:24 db.0
-rw-r--r-- 1 root root 271 Jun 21 11:24 db.127
-rw-r--r-- 1 root root 237 Jun 21 11:24 db.255
-rw-r--r-- 1 root root 353 Jun 21 11:24 db.empty
-rw-r--r-- 1 root root 270 Jun 21 11:24 db.local
-rw-r--r-- 1 root bind 648 Nov 6 14:25 erstes.netz.db
-rw-r--r-- 1 root bind 463 Jun 21 11:24 named.conf
-rw-r--r-- 1 root bind 498 Jun 21 11:24 named.conf.default-zones
-rw-r--r-- 1 root bind 165 Jun 21 11:24 named.conf.local
-rw-r--r-- 1 root bind 941 Nov 6 13:46 named.conf.options
-rw-r----- 1 bind bind 77 Okt 24 20:14 rndc.key
-rw-r--r-- 1 root root 1317 Jun 21 11:24 zones.rfc1918
Das sieht aber gut aus, unser System war schlau genug, die Rechte hier korrekt zu setzen…( das ist nicht immer so! )
Also die erste rote Fehlermeldung kopiert und in die bevorzugte Suchmaschine übergeben, wir sind mit ziemlicher Sicherheit nicht die ersten mit diesem Problem….
und ich bin schnell fündig geworden.
In meinem Copy&Paste haben sich hier Leerzeichen am Anfang der Zeilen in allen drei Dateien eingeschlichen.
Oben habe ich es mal in den beiden Beispielen für zwei Domainnamen extra NICHT _ korrigiert, damit man noch sehen kann wie schnell man auch offensichtliche Fehler übersehen kann.
Nun sollte es aber laufen:
gateway: /etc/bind # systemctl restart bind9.service gateway: /etc/bind # systemctl status bind9.service ● bind9.service - BIND Domain Name Server Loaded: loaded (/lib/systemd/system/bind9.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2019-11-06 15:08:21 CET; 2s ago Docs: man:named(8) Process: 1177 ExecStart=/usr/sbin/named $OPTIONS (code=exited, status=0/SUCCESS) Main PID: 1178 (named) Tasks: 5 (limit: 1140) Memory: 12.7M CGroup: /system.slice/bind9.service └─1178 /usr/sbin/named -u bind Nov 06 15:08:21 gateway named[1178]: zone 127.in-addr.arpa/IN: loaded serial 1 Nov 06 15:08:21 gateway named[1178]: zone 27.172.in-addr.arpa/IN: loaded serial 1 Nov 06 15:08:21 gateway named[1178]: zone erstes.netz/IN: loaded serial 8 Nov 06 15:08:21 gateway named[1178]: all zones loaded Nov 06 15:08:21 gateway named[1178]: running Nov 06 15:08:21 gateway named[1178]: zone 0.0.10.in-addr.arpa/IN: sending notifies (serial 8) Nov 06 15:08:21 gateway named[1178]: zone 1.0.10.in-addr.arpa/IN: sending notifies (serial 8) Nov 06 15:08:21 gateway named[1178]: zone erstes.netz/IN: sending notifies (serial 8) Nov 06 15:08:21 gateway named[1178]: managed-keys-zone: Key 20326 for zone . acceptance timer complete: key now trusted Nov 06 15:08:21 gateway named[1178]: resolver priming query complete
So sieht das schon gut aus, aber testen wir das mal:
gateway: /etc/bind # nslookup meinpc Server: 127.0.0.1 Address: 127.0.0.1#53 Name: meinpc.erstes.netz Address: 10.0.0.2 gateway: /etc/bind # nslookup ap2 Server: 127.0.0.1 Address: 127.0.0.1#53 Name: ap2.erstes.netz Address: 10.0.1.100 gateway: /etc/bind # nslookup 10.0.0.2 2.0.0.10.in-addr.arpa name = meinpc.erstes.netz.
Die Namensauflösung funktioniert in beide Richtungen, so muss das sein!
Loggen wir uns einmal aus und dann wieder ein wie folgt:
ich@meinpc: ~ # ssh root@gateway
nun muss wieder die Abfrage für den Schlüsselaustausch kommen, die wir bestätigen. Damit wird der Server auch mit seinem Namen in die known_hosts Datei eingetragen.
gateway: ~ #
Damit haben wir die erste Einrichtung unseres Nameservers abgeschlossen und das Netz ist einsatzbereit.
next > Netz in Betrieb nehmen