Jo's Linux Firewall Howto: Nameserver
Der eigene Nameserver
Der Nameserver stellt die Zuordnung zwischen IP-Adressen (192.168.0.1) und symbolischen Namen (klaus.t-online.de) her. Dieser Vorgang funktioniert in beide Richtungen! Es ist also mit einem Nameserver auch möglich, den zu einer IP-Adresse gehörenden Namen herauszubekommen. Ein lokaler Nameserver bietet 2 Vorteile: Er cached Nameserverzugriffe, also beantwortet Fragen lokal, wenn er die Antwort bereits kennt und muß somit nicht die ISDN-Leitung öffnen bzw. belasten; Außerdem bietet er die Möglichkeit, im lokalen Netz symbolische Namen zu verwenden, z. B. um den lokalen Proxy nicht immer mit 1 Nummer ansprechen zu müssen, sondern z.B. mit wwwproxy.localnet.home.
Inhaltsübersicht
- Grundsätzliches zum DNS
- Der Nameserver Daemon
- Die Konfigurationsdatei (/etc/named.conf)
- Die Hinweise zu den Root-Nameservern (root.hint)
- Der eigene Host (127.0.0.1)
- Die lokale Zone (192.168.0.0)
- Die Inbetriebnahme
- weitere Dokumentation
Grundsätzliches zum DNS
Der DNS ist der Domain Name Service. (Und nicht der Domain Name Server) Dieser Namensservice besteht nämlich aus einem System von Servern und Diensten, die sich über das gesamte Internet erstrecken. Prinzipiell kann man jeden Rechner (Web Server, ...) über seine IP-Adresse ansprechen. Dies ginge sogar etwas schneller, da die Adressumsetzung wegfällt. Aber dies ist zum einen recht unübersichtlich (www.jwiesemann.de ist eindeutig besser zu merken, als 195.20.225.124) und zum anderen nicht so langzeitstabil. Sobald ein Dienst auf einen anderen Rechner verlagert wird (z. B. Providerwechsel) oder der Rechner in ein anderes Subnet (z. B. Umzug) ändert sich die IP-Adresse. Nun müßten alle, die diesen Dienst weiter nutzen wollen über die neuen Adresse informiert werden.
Der Domain Name Service definiert ein hirarchische Namenssystem und die Dienste, welche dem Auflösen dieser Namen in Adressen dienen. Die Namen der Rechner sind nach Ebenen sortiert, wobei die einzelnen Ebenen (Level) durch Punkte getrennt werden und die höchste Ebene (Top Level) am Ende steht. Für jede Domain (Namensbereich) einer jeden Ebene gibt es einen Master Nameserver, der alle Einträge für diese Domain kennt. Alle anderen Nameserver fragen diesen Master, wenn sie nach einem Namen gefragt werden, den sie nicht kennen. Allerdings ist der Dienst so schlau, bei der nächsten Anfrage die Antwort von letzten Mal zu verwenden, um so die Abfragen zu verringern. Wegen der Umzugsproblematik gibt es aber eine Zeitspanne, die eine solche gemerkte (cached) Information maximal gültig bleibt. Danach wird sicherheitshalber neu nachgefragt. (Beim Wechsel 1 IP-Adresse sollten spätestens 8 Stunden nach dem neuen Eintrag beim Master alle Name Server in Internet über die neue Adresse verfügen!)
Eigentlich muß man nun nur definieren, welcher Name in welche Adresse umgesetzt werden muß. Dem aufmerksamen Leser wird aber weiter unten auffallen, das auch die umgekehrte Zuordnung definiert wird. Dies erlaubt es, herauszufinden, wer sich hinter einer bestimmten Ip-Adresse verbirgt. Bei einigen Systemen wird dies verwendet um die Zulässigkeit von Zugriffen zu prüfen. So akzeptieren z. B. viele Mailserver nur Mail von Adressen, die auch per reverse lookup (engl. für umgekehrt nachschlagen) zu identifizieren sind. Für ein stabiles System ist es daher unablässig, jeweils beide Einträge zu erzeugen.
Prinzipiell müssen nicht alle Rechner aus einem Subnet (Adressbereich, z.B. 192.168.0.x) in der selben Domain (Namensbereich, z.B. ?.jo.home) liegen. Wenn man es so einrichten kann, erleichtert dies aber den Überblick. Auch kann es zu jeder Adresse mehrere Namen geben (um Dienste logisch zu adressieren und sie später ohne Änderungen auf einen anderen Rechner verlagern zu können) und auch zu einem Namen mehrere Adressen (Wenn sich mehrer Server die Arbeit teilen).
Nun ein paar Überlegungen zu den lokalen Namen und Festlegungen. Es ist nützlich, damit es keine Konfusion mit Namen und Domains im Internet gibt, lokal Bezeichnungen zu verwenden, welche es im Internet mit Sicherheit nicht gibt. Im wesentlichen trifft dies auf die Top Level Domain zu. Sinnvoll ist hier z. B. ".home" oder ".lan", derartige Namen gibt es im Internet nicht und wird es voraussichtlich in absehbarer Zeit nicht geben. Für die einzelnen Funktionen in Netz sollte man jeweils 1 eigenen Namen vergeben. Dies bietet die Möglichkeit jederzeit die eine oder andere Funktion auf 1 anderen Rechner zu verlagern, ohne übermäßig Umkonfigurieren zu müssen.
Also kommen im ersten Ansatz folgende Namen zusammen:
Name | Adresse | Bemerkung |
gateway.jo.home | 192.168.0.1 | Firewall |
www.jo.home | (192.168.0.1) | Verweis auf Firewall |
proxy.jo.home | (192.168.0.1) | Verweis auf Firewall |
mailserver.jo.home | (192.168.0.1) | Verweis auf Firewall |
jo.jo.home | 192.168.0.2 | mein PC |
nic.jo.home | 192.168.0.3 | Nic's PC |
Grundsätzliches zum Nameserver Daemon
Die zentrale Konfigurationsdatei ist /etc/named.conf. Hier wird eingetragen, wie sich der Nameserver verhalten soll und was und wem er served. Dazu kommt dann noch 1 Satz Dateien, in dem die Wissensbasis über die lokalen Domains verborgen ist. Diese Dateien sind ein bißchen kompliziert, wegen ihrer abwegigen Syntax. Es ist aber durchaus zu schaffen.
Die Konfigurationsdatei /etc/named.conf
So, nun zur named.conf (Wo steht die doch gleich? Richtig, in /etc):
Zum Download - oder vergleichen: eine vollständige Datei (in einem eigenen Brauserfenster): named.conf
Und hier die Erklärungen zu den wichtigsten Einstellungen:
options { |
In diesem Bereichen stehen allgemeine Optionen für den Nameserver.
directory "/var/named"; |
Das Verzeichnis, in dem die Zonen-Dateien stehen.
pid-file "/var/named/slave/named.pid"; |
Die Datei, in der sich der Daemon seine pid merkt. Das Verzeichnis muß existieren und der Named muß Schreibrechte in diesem Verzeichnis haben (Siehe Inbetriebnahme).
forwarders { 194.25.2.129; }; |
Hier wird angegeben, welcher externe Nameserver gefragt werden soll, wenn die Antwort auf eine Anfrage nicht lokal gefunden werden kann. Es können auch mehrere Adressen angegeben werden. Diese hier ist der Nameserver von t-online. An erster Stelle sollte immer der Nameserver des eigenen Zugangsproviders stehen, da dieser meist am schnellsten erreichbar ist.
Normalerweise wird bei Wählverbindungen die Adresse des zu verwendenden Nameservers beim Verbindungsaufbau mit übertragen. Damit könnte dann bei jedem Verbindungsaufbau die named.conf neu erzeugt und eingelesen werden. (Dies kann aus dem ip-up Skript geschehen.) Allerdings würde dabei jedesmal der gesamte Cache (Zwischenspeicher) gelöscht, was einen lokalen Nameserver ziemlich überflüssig macht. Da sich die Adressen der Nameserver selten (wirklich) Ändern, ist es günstiger, man trägt sie fest ein. Die Idee, die named.conf nur neu zu erzeugen und einzulesen, wenn eine andere Nameserver-Adresse als beim letzten Einwählen gemeldet wird, hilft leider auch nicht viel: Manche Provider haben mehrere Nameserver und vergeben jedesmal 1 zufällige Adresse. Dann ist man wieder da, wo man nicht hinwollte. |
listen-on { 127.0.0.1/32; 192.168.0.0/24; }; |
Hier wird eingestellt, für wen Anfragen bearbeitet werden. Die /32 bzw. /24 gibt die Anzahl der zu wertenden Adressbits von links an. /24 entspricht somit der Netmask 255.255.255.0.
cleaning-interval 720; statistics-interval 720; |
Bei einer Heimanwendung wird der Nameserver meistens nur in den Abendstunden benötigt. Hier ist es recht unwahrscheinlich, daß sich in dieser Zeit eine IP-Adresse ändert. Daher ist es hier ganz sinnvoll, die Abfragen dadurch zu verringern, daß gemerkte Einträge für 12 Stunden (=720 Minuten) gültig sind. Am nächsten Tage werden dann alle Einträge wieder aktualisiert.
} |
Hiermit wird der "options"-Bereich beendet.
Nun folgen die Zonen-Definitionen. Hier werden die einzelnen Zonen (Subnets = Adressbereiche und Domains = Namesbereiche) definiert.
zone "." IN {
type hint; file "root.hint"; }; |
Das ist so OK. Habe ich auch nur übernommen, funktioniert aber bisher problemslos. (Man muß nicht immer alles verstehen - solange es funktioniert ;-)
zone "localhost" IN {
type master; file "localhost.zone"; check-names fail; allow-update { none; }; }; |
Diese Zone definiert alle Namen, die mit localhost enden.
zone "0.0.127.in-addr.arpa" IN {
notify no; type master; file "127.0.0.zone"; }; |
Alle Adressen im Subnet (Bereich) 127.0.0.x werden in dieser Zonendatei beschrieben. Sie ist das Gegenstück zu der darüber. Die Adressen müssen hier rückwärts angegeben werden, da auch die Auflösung von hinten her erfogt. Der Name der Datei ist beliebig - es bietet sich aber an, hier ein halbwegs übersichtliches Schema zu verwenden, sonst verliert man leicht den Überblick.
zone "jo.home" IN {
notify no; type master; file "jo.home.zone"; }; |
Hier werden die Namen, die mit .jo.home enden, definiert.
zone "0.168.192.in-addr.arpa" IN {
notify no; type master; file "192.168.0.zone"; }; |
Entsprechend ist dies die Zonendatei, die dem reverse lookup der Adressen im Subnet 192.168.0.x dient.
Die Hinweise zu den Root-Nameservern
Zum Download - oder vergleichen: eine vollständige Datei:
root.hint
Diese Datei muß im Verzeichnis /var/named stehen (vgl.
Einstellungen in named.conf).
Diese Datei wird mit dem Namesever ausgeliefert und sollte somit schon vorhanden sein. An ihr ist nichts weiter einzustellen, daher werde ich sie auch nicht weiter erklären.
Der eigene Host (127.0.0.1)
Zum Download - oder vergleichen: zwei vollständige Dateien (jeweils in einem eigenen Brauserfenster): localhost.zone und 127.0.0.zone. Diese Dateien müssen im Verzeichnis /var/named stehen (vgl. Einstellungen in named.conf).
localhost.zone
Diese Datei beschreibt die Namen im Bereich "localhost". Hier wird zu jedem Namen eine Adresse angegeben. Da localhost der einzige Rechner in einer "top level domain" ist, geht das recht einfach ab.
Und hier die Erklärungen zu den wichtigsten Einstellungen:
$ORIGIN localhost. |
Hier wird die Basisadresse dieser Zone festgelegt. In diesem Fall ganz einfach.
@
1D IN SOA @ root ( 42 ; serial (d. adams) 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum |
Dieser Block gehört hier hin! Lediglich die erste Zeile muß angepaßt werden: Der erste Eintrag hinter SOA ist der Name des Rechners, die für diese Zone zuständig ist. (Der Klammeraffe "@" wird in diesen Dateien jeweils durch die Basis ersetzt.) Der zweite Name ist die eMail- Adresse des Verantwortlichen für diese Zone. Da der Klammeraffe "@" in diesen Dateien eine besondere Bedeutung hat, muß aus "root@localhost" "root.localhost" werden. Da bei allen Adressen, die nicht mit einem Punkt enden .Basis angehängt wird, reicht hier der Eintrag root. Die erste Zeile hätte auch lauten können:
@ 1D IN SOA localhost. root.localhost. ( |
Wichtig sind die Punkte jeweils am Ende des Namens bzw. der Adresse. Diese stellen sicher, daß nicht noch der Basisname bzw. die Basisadresse angehängt wird. Dies geschieht bei allen Namen und Adressen, die nicht mit einem Punkt enden!
1D IN NS @ |
1D IN A 127.0.0.1 |
127.0.0.zone
Diese Datei beschreibt die Adressen im Bereich "127.0.0". Hier wird zu jeder Adresse ein Name angegeben. Sie ist das Gegenstück zu localhost.zone. Da localhost der einzige Rechner in diesem Subnet ist, geht das recht einfach ab.
Und hier die Erklärungen zu den wichtigsten Einstellungen:
$ORIGIN 0.0.127.in-addr.arpa. |
Hier wird die Basisadresse dieser Zone festgelegt. Dabei ist zu beachten, daß die Adresse rückwärts geschrieben sein muß, da sie auch von hinten aufgelöst wird. Das ".inaddr.arpa." stammt noch aus der Zeit, als das Internet noch ganz klein war und Arpanet hieß. Das war lange bevor das WWW erfunden wurde.
1D IN SOA localhost. root.localhost. (
42 ; serial (d. adams) 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum |
Dieser Block gehört hier hin! Lediglich die erste Zeile muß angepaßt werden: Der erste Eintrag nach SOA ist der Name des Rechners, der für die Zone verantwortlich zeichnet. Der zweite Name ist die eMail- Adresse des Verantwortlichen für diese Zone. Da der Klammeraffe "@" in diesen Dateien eine besondere Bedeutung hat, muß aus "root@localhost" wie oben "root.localhost" werden. Da (erstmal) nur der Benutzer root Zugriff auf die Konfigurationsdateien des Nameservers hat, ist dieser eigentlich auch ein guter Ansprechpartner.
Wichtig sind die Punkte jeweils am Ende des Namens bzw. der Adresse. Diese stellen sicher, daß nicht noch der Basisname bzw. die Basisadresse angehängt wird. Dies geschieht bei allen Namen und Adressen, die nicht mit einem Punkt enden!
1D IN NS localhost. |
Hier wird der Nameserver "NS" dieser Zone angegeben. (Punkt nicht vergessen.)
1 1D IN PTR localhost. |
Dies ist der Eintrag für die Adresse Eins. (Punkt nicht vergessen).
Diese Dateien sollten eigentlich ohne Änderung überall funktionieren. Die nächsten Dateien sind da schon etwas komplizierter, sind aber (glücklicherweise ;-) nach dem gleichen Schema aufgebaut.
Die lokale Zone (192.168.0.0)
Zur Vereinfachung der Einstellung werden alle Adressen des (ersten) lokalen Subnets auch Namen in der selben Domain zugeordnet. Dies ist nicht zwingend erforderlich. Die Syntax der Dateien ändert sich dabei nicht, nur der Überblick wird etwas erschwert.
Zum Download - oder vergleichen: zwei vollständige Dateien (jeweils in einem eigenen Brauserfenster): jo.home.zone und 192.168.0.zone. Diese Dateien müssen im Verzeichnis /var/named stehen (vgl. Einstellungen in named.conf).
jo.home.zone
Diese Datei beschreibt die Namen im Bereich "jo.home". Hier wird zu jedem Namen eine Adresse angegeben. Also alle Namen wie klaus.jo.home müssen in dieser Datei definiert werden.
Nun fragt sich vermutlich mancher, ob man wirklich alle Rechner im lokalen Netz mit 1 Namen versehen muß. Muß man natürlich nicht. Aber zum 1 ist es 1 ganz gute Übung, um zu verstehen, wie 1 Nameserver funktioniert. Und zum anderen ist es bei mehreren Rechnern ganz nützlich, diese mit 1 Namen identifizieren zu können. Namen kann sich 1 menschliches Hirn nämlich besser merken, als Nummern.
Und hier die Erklärungen zu den wichtigsten Einstellungen:
$ORIGIN jo.home. |
Hier wird die Basisadresse dieser Zone festgelegt. Punkt nicht vergessen.
@
1D IN SOA gateway.jo.home jo.gateway.jo.home
42 ; serial (d. adams) 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum 1D IN TXT "Die Firewall im Heimnetz" 1D IN NS gateway 1D IN MX 10 mailserver |
Den Block hatten wir schon mal ;-)).
gateway
1D IN A 192.168.0.1
1D IN HINFO "i586" "Linux 2.2" |
Hier stehen 1 paar Informationen zu diesem Rechner. Diese werden nicht wirklich benötigt, sind aber üblich.
nameserver
1D IN A 192.168.0.1
mailserver 1D IN A 192.168.0.1 proxy 1D IN A 192.168.0.1 www 1D IN A 192.168.0.1 |
Hier nun 1 paar Namen, welche alle auf den selben Rechner zeigen. Dies wird dann nützlich, wenn mal der Mailserver oder der Webserver auf einen anderen Rechner verlagert werden soll. Dann müssen nicht alle clients von Hand umgestellt werden, sondern nur der Eintrag im Nameserver.
jo
1D IN A 192.168.0.2
1D IN HINFO "iP3" "Linux 2.4" 1D IN TXT "Jo's eigener Rechner" 1D IN MX 10 mailserver |
Nun Rechner Nummer 1 (Also außer der Firewall). Nur die erste Zeile ist wirklich nötig.
nic
1D IN A 192.168.0.3
1D IN HINFO "iP2" "Win98" 1D IN TXT "Nic's Rechner" 1D IN MX 10 mailserver |
Rechner Nummer 2 analog.
192.168.0.zone
Diese Datei beschreibt die Adressen im Bereich "192.168.0.0". Hier wird zu jeder Adresse ein Name angegeben. Sie ist das Gegenstück zu jo.home.zone. Das Subnet um das es geht ist in unserem Beispielsystem das an der (ersten) internen Netzwerkkarte.
Und hier die Erklärungen zu den wichtigsten Einstellungen:
$ORIGIN 0.168.192.in-addr.arpa. |
Hier wird die Basisadresse dieser Zone festgelegt. Dabei ist zu beachten, daß die Adresse rückwärts geschrieben sein muß, da sie auch von hinten aufgelöst wird.
@
1D IN SOA localhost. root.localhost. (
42 ; serial (d. adams) 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum |
Der erste Block ist - wie die gesamte Datei - natürlich wie oben aufgebaut. Nur daß hier auch eine eMail-Adresse angegeben werden sollte, die auch von außen zu erreichen ist. Also nicht @localhost, sondern @gateway.jo.home.
1 1D IN PTR gateway.jo.home. 1 1D IN PTR mailserver.jo.home. 1 1D IN PTR nameserver.jo.home. 1 1D IN PTR proxy.jo.home. 1 1D IN PTR www.jo.home. |
Hier werden die verschiedenen Namen der Adresse 1 zugeordnet. Dies hat allein den Zweck, später vielleicht einmal z. B. den Proxy auf einen anderen Rechner verlagern zu können. Dann müsten nur die Einträge in dieser und der inversen Datei angepaßt werden und nicht die Einstellungen eines jeden Web-Browsers. (Wie immer die abschließenden Punkte nicht vergessen.
2 1D IN PTR jo.jo.home. 3 1D IN PTR nic.jo.home. |
Hier jetzt die beiden Rechner des Beispiels. Das war es auch schon.
Die Inbetriebnahme
Der Nameserver Daemon heißt "Bind", was von seinem Ursprung, dem Berkeley Internet Name Domain Protokoll herrührt. Wird dieser vom Terminal aus gestartet (darf nur root), so können seine Ausgaben in /var/log/messages bewundert werden:
root@gateway:~ > less /var/log/messages |
Bei SuSE kann der named am einfachsten gestartet werden durch Aufruf von:
root@gateway:~ > /sbin/init.d/named start |
Hierzu muß aber in /etc/rc.config eingetragen sein, das der Nameserver gestartet werden soll. Dies kann von Hand oder mit YaST geschehen.
Wenn etwas wie der folgende Text erscheint, dann habt ihr schon gewonnen:
Jun 12 17:54:05 gateway named[154]: starting. named 8.2.2-P5 Sat Mar 11 10:37:51 GMT 2000 root@Mersenne:/usr/src/packages/BUILD/bind8-8.2.2/bin/named Jun 12 17:54:05 gateway named[154]: hint zone "" (IN) loaded (serial 0) Jun 12 17:54:05 gateway named[154]: master zone "localhost" (IN) loaded (serial 42) Jun 12 17:54:05 gateway named[154]: master zone "0.168.192.in-addr.arpa" (IN) loaded (serial 42) Jun 12 17:54:05 gateway named[154]: master zone "jo.home" (IN) loaded (serial 42) Jun 12 17:54:05 gateway named[154]: listening on [127.0.0.1].53 (lo) Jun 12 17:54:05 gateway named[154]: listening on [192.168.0.1].53 (eth0) Jun 12 17:54:05 gateway named[154]: Forwarding source address is [0.0.0.0].1024 Jun 12 17:54:06 gateway named[160]: group = named Jun 12 17:54:06 gateway named[160]: user = named Jun 12 17:54:06 gateway named[160]: Ready to answer queries. |
Bei Syntaxfehlern in einer der Dateien, werden diese hier gemeldet. Dann läßt sich zumindest auf Anhieb erkennen, in welcher Datei das Problem steckt. Im Zweifel einzelne Einträge auskommentieren. Und natürlich mit den Beispielen oben vergleichen.
Je nach Linux-Version und Distribution verwendet der named einen anderen Usernamen. Bei SuSE laufen die älteren Versionen als "root", die neueren als "named" (siehe oben). In diesem Fall muß natürlich dafür gesorgt werden, daß die Dateien für diesen User auch lesbar sind! z. B. mit
root@gateway:~ > chown user datei |
root@gateway:~ > chgrp gruppe datei |
die Gruppenzugehörigkeit der Datei ändern.
Wenn auf den ersten Blick alles gut aussieht, kann der Nameserver getestet werden. Zuerst natürlich von lokalen Host aus. Dazu nslookup starten. Mit diesem Tool lassen sich bei einem Nameserver Namen und Adressen auflösen und weitere Informationen über die Datenbasis des Named gewinnen.
Am Prompt von nslookup kann jetzt jede IP-Adresse abgefragt werden:
jo@gateway:~ > nslookup Default Server: localhost Address: 127.0.0.1 > 192.168.0.3 Server: localhost Address: 127.0.0.1 Name: nic.jo.home Address: 192.168.0.3 >exit jo@gateway:~ > |
Ebenso kann jeder Name abgefragt werden:
> jo.jo.home Server: localhost Address: 127.0.0.1 Name: jo.jo.home Address: 192.168.0.2 |
Ob man jetzt jede Adresse und jeden Namen einzeln prüft, oder aus jeder Zone nur einen ist eine Frage der persönlichen Pedanterie. Wenn einzelne Adressen bzw. Namen nicht richtig aufgelöst werden, sollte zuerst die entsprechende Zonen-Datei auf Tippfehler untersucht werden.
Anschließend kann der named von einem anderen Rechner im Netz getestet werden. Wenn der andere Rechner auch unter Linux läuft, ist das einfach. Wenn er unter Windows/NT läuft auch: da existiert auch ein nslookup. Bei anderen Betriebssystemen kann man mit Ping zumindest die Auflösung von Namen in Adressen testen.
Antwortet der Nameserver hier nicht, so sollte man prüfen, ob er diese Adresse überhaupt bedienen darf (Einstellung listen-on in /etc/named.conf).
weitere Dokumentation
Zu Nameservern gibt es eigentlich reichlich Dokumention, da diese mit das Rückgrat des Internet darstellen. Hier 1 Auswahl:
- IP-Nummern Auflösung Das Kapitel IP-Nummern Auflösung (DNS) im offiziellen ISDN-Howto.
- DSN HOWTO Das offizielle Howto in englisch.
- man nslookup Die Man Page zu nslookup. Damit läßt sich der Nameserver prüfen.
- ISC BIND Documentation Die Online-Dokumentation zu Bind 8.2.2 in englisch.
Weiter mit: Sie haben Post: eMail!
Urheber © Dr. Joachim Wiesemann
Letzte Aktualisierung: 19.11.2022
www.JWiesemann.de
Für Anregungen und Kritik: feedback@jwiesemann.de