„Das Internet geht nicht“ ist eine Beobachtung mit zu wenig Auflösung. Vielleicht existiert kein Funksignal, vielleicht keine Route, vielleicht liefert DNS den falschen Namen, vielleicht lehnt TLS das Zertifikat ab oder die Anwendung antwortet mit einem Fehler. Netzwerkkompetenz heißt, aus einem Symptom die nächste prüfbare Grenze zu machen.
Paketreise ohne Sieben-Schichten-Ritual
Eine Anwendung erzeugt Daten für ein Protokoll wie HTTP. Der Transport ordnet sie einer Verbindung oder einem Datagramm zu. IP adressiert Hosts über Netze hinweg; eine lokale Verbindung bringt Frames zum nächsten Hop. Auf jedem Abschnitt können andere Geräte und Regeln wirken.
RFC 1122 strukturiert Hostanforderungen in Link-, Internet-, Transport- und Anwendungsschicht. [1] Das OSI-Modell ist feiner und didaktisch nützlich, sollte aber nicht als Behauptung gelesen werden, jedes reale System besitze sieben unabhängig sichtbare Kästen.
Name, Adresse, Route und Port
| Begriff | Frage | Typischer Irrtum |
|---|---|---|
| DNS-Name | Welche Ressource wird benannt? | Name sei die Adresse selbst |
| IP-Adresse | Welcher Netzendpunkt ist erreichbar? | Adresse identifiziere dauerhaft eine Person |
| Route | Über welchen nächsten Hop geht das Paket? | alle Pakete nähmen denselben Weg |
| Port | Welcher Dienst am Host soll Daten erhalten? | Port sei ein physischer Anschluss |
| Socket | Welche lokale/ferne Adress- und Transportkombination? | ein Socket sei eine einzelne Datei im Netz |
DNS ist verteilte Zuständigkeit
DNS übersetzt nicht bloß Namen in IPv4-Adressen. Es verwaltet verschiedene Ressourcentypen in einer delegierten Hierarchie und arbeitet mit Caches und Gültigkeitszeiten. RFC 1034 beschreibt diesen Namensraum und seine Nameserver. [2]
Eine Änderung kann daher korrekt autoritativ veröffentlicht sein und trotzdem in einem Cache noch fehlen. Diagnose trennt Resolverantwort, autoritative Zone und anschließend die Erreichbarkeit der gelieferten Adresse.
TLS schafft einen geschützten Kanal
TLS 1.3 handelt kryptografische Parameter aus, authentifiziert typischerweise den Server über Zertifikate und schützt Integrität sowie Vertraulichkeit der übertragenen Daten. [3] Es verhindert, dass ein Zwischenknoten Klartext beliebig liest oder unbemerkt ändert.
TLS sagt aber nicht, ob die Website wahr, die Anwendung sicher programmiert oder der eingeloggte Nutzer berechtigt ist. Das Schloss im Browser ist ein Transportbefund, kein allgemeines Seriositätssiegel.
Zero Trust ist keine Produktbox
Traditionell galt ein internes Netz oft als relativ vertrauenswürdig. Zero Trust nimmt keinen Netzstandort als ausreichenden Beleg. NIST formuliert stattdessen explizite Authentifizierung und Autorisierung von Subjekt und Gerät vor dem Zugriff auf Ressourcen. [4]
Das bedeutet nicht, jedes Paket mit Misstrauen zu kommentieren. Es bedeutet kurze, prüfbare Vertrauensentscheidungen, minimale Rechte, Segmentierung und Telemetrie – mit Datenschutz und Ausfallsicherheit als eigenen Anforderungen.
Diagnose vom Nahen zum Fernen
- Prüfe lokalen Link und eine gültige Schnittstellenkonfiguration.
- Teste die Erreichbarkeit eines bekannten IP-Ziels und die Route.
- Frage DNS separat nach dem betroffenen Namen.
- Prüfe Transportverbindung und TLS-Aushandlung.
- Erst danach interpretiere HTTP- oder Anwendungsfehler.
Internetstandards und Sicherheitsarchitektur
- IETF RFC 1122 – Requirements for Internet Hosts (standard-primary)
- IETF RFC 1034 – Domain Names (standard-primary)
- IETF RFC 8446 – TLS 1.3 (standard-primary)
- NIST SP 800-207 – Zero Trust Architecture (standard-primary)
- Open Source Initiative – Open Source Definition (standard-primary)
Recherche- und Redaktionsstand: 15. August 2026. Redaktionell verantwortlich: Benjamin Metzig.