Zum Inhalt

Block 01 – Wie funktioniert das Internet?

Lernziele

  • Du kannst den Ablauf einer HTTPS-Anfrage vom Browser bis zum Server erklären
  • Du kannst erklären was eine IP-Adresse ist und wie sie aufgebaut ist
  • Du kannst erklären was DNS macht und warum es gebraucht wird
  • Du kannst den Unterschied zwischen HTTP und HTTPS beschreiben

1. Client-Server-Architektur

Das Internet basiert auf dem Client-Server-Modell. Dabei gibt es zwei Rollen:

Rolle Beschreibung Beispiel
Client Stellt Anfragen (Requests) Browser, App
Server Beantwortet Anfragen (Responses) Webserver, Datenbankserver

Der Client nimmt immer die aktive Rolle ein – er initiiert die Verbindung. Der Server wartet passiv auf eingehende Anfragen.

sequenceDiagram
    participant C as Client (Browser)
    participant S as Server (Webserver)
    C->>S: HTTP Request (GET /index.html)
    S-->>C: HTTP Response (200 OK + HTML)

Wichtig: Client und Server müssen nicht am gleichen Ort sein. Der Server kann auf der anderen Seite der Welt stehen – das Internet verbindet sie.

2. IP-Adressen

Damit zwei Geräte miteinander kommunizieren können, braucht jedes eine IP-Adresse – eine eindeutige Adresse im Netzwerk, vergleichbar mit einer Hausnummer.

IPv4

Die verbreitete Form hat 4 Blöcke mit je einer Zahl von 0–255:

192.168.1.10
  • Private IP (nur im lokalen Netzwerk): z.B. 192.168.x.x, 10.x.x.x
  • Öffentliche IP (im Internet erreichbar): z.B. 34.65.12.100

Ports

Eine IP-Adresse allein reicht nicht – ein Server kann viele Dienste gleichzeitig anbieten. Ports unterscheiden die einzelnen Dienste:

Port Dienst
80 HTTP
443 HTTPS
22 SSH
3306 MySQL

Eine vollständige Adresse sieht so aus: 192.168.1.10:443

3. DNS – Domain Name System

Menschen merken sich Namen besser als Zahlen. DNS übersetzt Domainnamen in IP-Adressen – wie ein Telefonbuch des Internets.

sequenceDiagram
    participant B as Browser
    participant D as DNS-Server
    participant W as Webserver
    B->>D: Was ist die IP von tbz.ch?
    D-->>B: 185.60.12.44
    B->>W: Verbinde mit 185.60.12.44
    W-->>B: HTTP Response

Ablauf wenn du "tbz.ch" eingibst:

  1. Browser prüft seinen lokalen Cache
  2. Betriebssystem prüft die hosts-Datei
  3. Anfrage geht an den konfigurierten DNS-Server (z.B. vom Router)
  4. DNS-Server liefert die IP-Adresse zurück
  5. Browser verbindet sich mit der IP

Wichtige DNS-Record-Typen:

Record Bedeutung Beispiel
A Domain → IPv4 tbz.ch → 185.60.12.44
CNAME Domain → andere Domain www.tbz.ch → tbz.ch
MX Mail-Server für Domain tbz.ch → mail.tbz.ch
NS Nameserver für Domain tbz.ch → ns1.tbz.ch

Split-DNS

Split-DNS bedeutet, dass ein Domainname intern und extern auf unterschiedliche IP-Adressen aufgelöst wird.

Beispiel: Du hast einen Server mit einer öffentlichen IP 85.12.44.10 und einer privaten IP 10.0.0.5.

flowchart LR
    A[Interner Client] -->|DNS-Anfrage: server.tbz.ch| B[Interner DNS-Server]
    B -->|10.0.0.5 private IP| A

    C[Externer Client] -->|DNS-Anfrage: server.tbz.ch| D[Öffentlicher DNS-Server]
    D -->|85.12.44.10 öffentliche IP| C

Warum ist das nützlich? - Interner Traffic bleibt im lokalen Netzwerk (schneller, sicherer) - Externe Benutzer erreichen denselben Server über die öffentliche IP - Kein Hairpin-NAT nötig (wenn interner Client über öffentliche IP auf eigenen Server zugreifen müsste)

Im Modul 158 konfigurierst du genau das: Dein eigener DNS-Server (bind9) kennt die interne IP, während DynV6 die öffentliche IP verwaltet.

Kann eine interne Domain ein gültiges Zertifikat haben?

Kurze Antwort: Nein – nicht von einer offiziellen Zertifizierungsstelle (CA) wie Let's Encrypt.

Warum? Let's Encrypt und andere CAs stellen Zertifikate nur für Domains aus, die sie öffentlich verifizieren können. Bei einer internen Domain wie server.intern oder server.local gibt es keine öffentliche DNS-Eintragtung – die CA kann den Besitz nicht bestätigen.

Was sind die Optionen?

Option Beschreibung Vertrauen
Self-signed Zertifikat Selbst erstellt, keine CA ❌ Browser zeigt Warnung
Interne CA Eigene Zertifizierungsstelle, manuell auf Clients installiert ✅ Intern vertrauenswürdig
Öffentliche Domain mit Split-DNS Zertifikat für öffentliche Domain, intern auf private IP zeigen ✅ Vollständig vertrauenswürdig

Die dritte Option ist die eleganteste Lösung: Du registrierst eine öffentliche Domain (z.B. über DynV6), holst ein Let's Encrypt Zertifikat, und lässt die Domain intern per Split-DNS auf die private IP zeigen. Resultat: gültiges Zertifikat, kein externer Zugriff nötig.

Eigene öffentliche Zone mit eigenem DNS-Server verwalten

Normalerweise verwaltet der Domainregistrar (z.B. Hosttech, Cloudflare) die DNS-Zone. Es ist aber möglich, einen eigenen Nameserver als autoritativen DNS-Server für eine öffentliche Domain zu betreiben.

Voraussetzungen: 1. Eine registrierte Domain 2. Ein öffentlich erreichbarer Server mit statischer IP 3. Ein DNS-Server (z.B. bind9) 4. Mindestens zwei Nameserver (die meisten Registrare verlangen das für Redundanz)

Ablauf: 1. Beim Registrar trägst du deine eigenen Nameserver ein: ns1.deinedomain.ch 2. Du konfigurierst bind9 als autoritativen Server für deine Zone 3. Alle DNS-Anfragen für deine Domain landen bei deinem Server

GLUE Records

Hier entsteht ein Henne-Ei-Problem: Wenn dein Nameserver ns1.deinedomain.ch heisst, muss der Browser zuerst die IP von ns1.deinedomain.ch auflösen – aber genau diese Auflösung liegt bei deinem Nameserver selbst.

GLUE Records lösen dieses Problem: Der übergeordnete Nameserver (z.B. .ch) speichert zusätzlich zur NS-Eintragtung direkt die IP-Adresse des Nameservers.

deinedomain.ch.   NS    ns1.deinedomain.ch.   ← Nameserver-Eintragtung
ns1.deinedomain.ch.  A  85.12.44.10            ← GLUE Record (IP direkt beim .ch-Server)

Ohne GLUE Record wäre die Auflösung einer Domain unmöglich, wenn der Nameserver unter derselben Domain liegt.

GLUE Records werden beim Registrar eingetragen, nicht im eigenen DNS-Server.

4. HTTP und HTTPS

HTTP (HyperText Transfer Protocol) ist das Protokoll für die Kommunikation zwischen Client und Server im Web.

HTTP-Anfrage (Request)

GET /index.html HTTP/1.1
Host: tbz.ch
  • Methode: Was will der Client? (GET = lesen, POST = senden, PUT = aktualisieren, DELETE = löschen)
  • Pfad: Welche Ressource? (/index.html)

HTTP-Antwort (Response)

HTTP/1.1 200 OK
Content-Type: text/html

<html>...</html>

Wichtige Statuscodes:

Code Bedeutung
200 OK Anfrage erfolgreich
301 Moved Permanently Seite dauerhaft umgezogen (Redirect)
404 Not Found Ressource nicht gefunden
500 Internal Server Error Fehler auf dem Server

HTTP vs HTTPS

HTTP HTTPS
Verschlüsselung ❌ Keine ✅ TLS/SSL
Sichtbarkeit Daten im Klartext Daten verschlüsselt
Port 80 443
Einsatz Veraltet, unsicher Standard heute

Bei HTTPS wird die Verbindung mit TLS (Transport Layer Security) verschlüsselt. Ein Zertifikat (z.B. von Let's Encrypt) bestätigt, dass der Server wirklich derjenige ist, der er vorgibt zu sein.

TLS Handshake – wie wird eine sichere Verbindung aufgebaut?

HTTPS verwendet zwei Verschlüsselungsverfahren nacheinander – das ist der clevere Kern von TLS:

1. Asymmetrische Verschlüsselung (zum Verbindungsaufbau)

Asymmetrische Verschlüsselung verwendet ein Schlüsselpaar: einen öffentlichen Schlüssel (Public Key) und einen privaten Schlüssel (Private Key).

  • Was mit dem Public Key verschlüsselt wird, kann nur der Private Key entschlüsseln
  • Der Public Key liegt im Zertifikat und ist für alle sichtbar
  • Der Private Key liegt nur auf dem Server und verlässt ihn nie
sequenceDiagram
    participant B as Browser
    participant S as Server
    B->>S: "Hallo, ich möchte eine sichere Verbindung"
    S-->>B: Zertifikat mit Public Key
    B->>B: Zertifikat prüfen (von Let's Encrypt signiert?)
    B->>B: Zufälligen Session-Key generieren
    B->>S: Session-Key verschlüsselt mit Public Key
    S->>S: Session-Key entschlüsseln mit Private Key
    Note over B,S: Beide kennen jetzt denselben Session-Key

2. Symmetrische Verschlüsselung (für die eigentliche Kommunikation)

Sobald beide Seiten denselben Session-Key kennen, wechselt TLS auf symmetrische Verschlüsselung – derselbe Schlüssel ver- und entschlüsselt die Daten.

sequenceDiagram
    participant B as Browser
    participant S as Server
    B->>S: Daten verschlüsselt mit Session-Key
    S-->>B: Antwort verschlüsselt mit Session-Key

Warum dieser Wechsel?

Asymmetrisch Symmetrisch
Schlüssel Public + Private Key Ein gemeinsamer Key
Geschwindigkeit ❌ Langsam (rechenintensiv) ✅ Schnell
Problem Wie tauscht man den Key sicher aus? Key muss vorher sicher ausgetauscht worden sein

Asymmetrische Verschlüsselung löst das Schlüsselaustausch-Problem – man kann sicher einen gemeinsamen Key vereinbaren ohne ihn je im Klartext zu übertragen. Danach übernimmt die schnelle symmetrische Verschlüsselung für den eigentlichen Datentransfer.

Merksatz: Asymmetrisch zum Schlüssel austauschen, symmetrisch zum Daten übertragen.

Zusammenfassung

Wenn du eine URL im Browser eingibst, passiert folgendes:

  1. Der Browser fragt den DNS-Server nach der IP-Adresse der Domain
  2. Der DNS-Server liefert die IP-Adresse zurück
  3. Der Browser baut eine HTTPS-Verbindung (Port 443) zum Server auf – dabei wird ein TLS-Zertifikat geprüft
  4. Der Server antwortet mit einem HTTP-Statuscode und dem Inhalt

Mit Split-DNS kann dieselbe Domain intern und extern auf unterschiedliche IPs zeigen. Öffentliche Zertifikate (z.B. Let's Encrypt) funktionieren nur für Domains mit einem öffentlichen DNS-Eintrag. Wer einen eigenen Nameserver betreibt, benötigt GLUE Records damit die Domain überhaupt auflösbar ist.

sequenceDiagram
    participant B as Browser
    participant D as DNS
    participant S as Webserver
    B->>D: DNS-Anfrage: tbz.ch?
    D-->>B: IP: 185.60.12.44
    B->>S: HTTPS Request (Port 443)
    Note over B,S: TLS-Verbindung wird aufgebaut
    S-->>B: HTTPS Response (200 OK)

Testfragen

  1. Erkläre in eigenen Worten was passiert, wenn du https://tbz.ch in den Browser eingibst. Gehe auf DNS, IP-Adresse und HTTPS ein.
  2. Was ist der Unterschied zwischen einer privaten und einer öffentlichen IP-Adresse?
  3. Warum braucht es DNS – könnte man nicht einfach die IP-Adresse direkt eingeben?
  4. Was bedeutet der HTTP-Statuscode 301? In welchem Zusammenhang begegnet dir dieser im Modul 158?
  5. Erkläre den Unterschied zwischen HTTP und HTTPS. Warum sollte heute kein produktiver Webserver mehr auf HTTP laufen?
  6. Erkläre den TLS Handshake: Warum wird zuerst asymmetrische und danach symmetrische Verschlüsselung verwendet?
  7. Was ist Split-DNS und in welcher Situation macht es Sinn?
  8. Du hast einen internen Server mit der Domain server.local. Kann dieser ein gültiges Let's Encrypt Zertifikat erhalten? Begründe deine Antwort und erkläre eine mögliche Alternative.
  9. Was sind GLUE Records und warum sind sie notwendig?