hwr-notes/Netzwerke/zusammenfassungen/nw5 - zusammenfassung.md

# Netzwerktechnik – Vorlesung 5: Layer 4 (TCP/UDP), Layer 3 (NAT), Layer 7 (DNS)

**Modul:** IT2221 – Netwerktechnik  
**Dozentin:** Gabriele Schrenk (e_schrenk@doz.hwr-berlin.de)  
**Datum:** 20.03.2026

-----
## LAYER 4 – Transport Layer (Transportschicht)

### Wiederholung TCP/IP Referenzmodell – Schicht 4

Schicht 4 (Transport) ist zuständig für die Verbindung zwischen Endsystemen. Die Dateneinheit auf dieser Schicht heißt **Segment**. Die Transportschicht stellt Dienstgüte (Quality of Service) und Zuverlässigkeit sicher.

Das OSI-Modell von oben nach unten: Application → Presentation → Session → **Transport** → Network → Data Link → Physical.

-----

### TCP – Transmission Control Protocol

TCP ist Teil der Protokollfamilie TCP/IP und ermöglicht **Ende-zu-Ende-Kommunikation**. Der Datenstrom wird auf verschiedene Anwendungen aufgeteilt. Daten werden mit einem TCP-Header versehen und anschließend an das IP-Protokoll übergeben. Datenpakete werden beim Sender sortiert und an adressierte Anwendungen (identifiziert über **Portnummern**) geschickt.

#### Wichtigste Eigenschaften von TCP

- **Verbindungsmanagement:** TCP ist verbindungsorientiert und stellt die richtige Reihenfolge der Daten sicher.
- **Flusskontrolle (Flow Control):** Schützt gegen Pufferüberlauf beim Empfänger.
- **Zeitüberwachung (Timer):** Überwacht, ob Bestätigungen rechtzeitig eintreffen.
- **Fehlerbehandlung (Retransmission):** Verlorene oder fehlerhafte Pakete werden durch Neuübertragung korrigiert.

-----

### Aufbau des TCP-Headers

Der TCP-Header besteht aus folgenden Feldern:

|Feld                      |Beschreibung                                                         |
|--------------------------|---------------------------------------------------------------------|
|**Quell-Port / Ziel-Port**|Identifizieren die sendende und empfangende Anwendung                |
|**Sequenz-Nummer**        |Nummer des ersten Bytes im aktuellen Segment                         |
|**Acknowledgement-Nummer**|Nummer des nächsten erwarteten Datenpakets                           |
|**Data-Offset**           |Anzahl der 32-bit-Blöcke im TCP-Header (entspricht der Header Length)|
|**Flags**                 |SYN, ACK, FIN, RST, URG, PSH, ECE, CWR                               |
|**Window-Größe**          |Größe des Empfangs-Puffers (für Flusskontrolle)                      |
|**Check-Summe**           |Prüfsumme zur Fehlererkennung                                        |
|**Urgent-Pointer**        |Zeigt auf das Ende dringender Daten (schnelle Zustellung)            |
|**Options**               |Optionale Felder wie Max. Segment Size (MSS), Window Scale, Timestamp|

Aufbau als Tabellenstruktur:

```
| Quell-Port          | Ziel-Port           |
| Sequenz-Nummer                            |
| Acknowledgement-Nummer                    |
| Data-Offset | Reserviert | Flags | Window |
| Check-Summe         | Urgent-Pointer      |
| Option / Füllbits                         |
| Daten...                                  |
```

-----

### TCP – Portnummern

Ports werden von der **Internet Assigned Numbers Authority (IANA)** für alle Transportprotokolle vergeben. Es gibt drei Bereiche:

|Bereich                        |Portnummern|Beschreibung                               |
|-------------------------------|-----------|-------------------------------------------|
|**Well-Known Ports**           |0–1023     |Standardisierte, allgemein bekannte Dienste|
|**Registered Ports**           |1024–49151 |Registrierte Dienste und Anwendungen       |
|**Dynamically Allocated Ports**|49152–65535|Dynamisch zugewiesene (ephemere) Ports     |

#### Beispiele für TCP-Ports

|Port|Protokoll|Anwendung                                   |
|----|---------|--------------------------------------------|
|21  |FTP      |Dateitransfer                               |
|22  |SSH      |Secure Shell Service                        |
|23  |Telnet   |Konsole                                     |
|25  |SMTP     |Simple Mail Transfer Protocol               |
|80  |HTTP     |Hypertext Transfer Protocol (World Wide Web)|
|110 |POP3     |Post Office Protocol v3 für E-Mail          |
|123 |NTP      |Dienst zur Zeitsynchronisierung             |
|179 |BGP      |Border Gateway Protocol                     |
|220 |IMAP3    |Internet Message Access Protocol für E-Mail |
|443 |HTTPS    |HTTP Secure                                 |

-----

### TCP – Acknowledgement-Mechanismus

TCP verwendet Sequenz- und Acknowledgement-Nummern zur zuverlässigen Datenübertragung.

**Ablauf-Beispiel:**

1. Sender schickt Paket mit Seq=10 (Source-Port 1028, Dest-Port 23, Ack=1).
2. Empfänger empfängt Paket #10 und antwortet mit Ack=11 (Source-Port 23, Dest-Port 1028, Seq=1, Ack=11). Die Ack-Nummer 11 bedeutet: „Ich erwarte als nächstes Paket #11.”
3. Sender sendet nächstes Paket mit Seq=11 (Ack=2).

Die **Acknowledgement-Nummer** gibt immer die Sequenznummer des **nächsten erwarteten** Pakets an.

-----

### TCP – Verbindungsaufbau (Three-Way-Handshake)

Der TCP-Verbindungsaufbau erfolgt in drei Schritten:

**Schritt 1:** Client (Host A) sendet ein **SYN**-Paket an den Server (Host B).

- `seq=100, ctl=SYN`

**Schritt 2:** Server empfängt das SYN und antwortet mit **SYN+ACK**.

- `seq=300, ack=101, ctl=SYN,ACK`
- Der Server bestätigt den Empfang (ACK) und schickt gleichzeitig seinen eigenen Verbindungswunsch (SYN). Die ack=101 bestätigt, dass seq=100 empfangen wurde und als nächstes seq=101 erwartet wird.

**Schritt 3:** Client bestätigt mit **ACK**. Die Verbindung ist hergestellt.

- `seq=101, ack=301, ctl=ACK`

Zusammenfassung: Client sendet SYN → Server antwortet SYN+ACK → Client bestätigt ACK → Datenaustausch möglich.

-----

### TCP – Verbindungsabbau (4-Way-Handshake)

Der Verbindungsabbau ist dem Aufbau ähnlich, aber umgekehrt und benötigt **vier Schritte**:

**Schritt 1:** Host A sendet **FIN** (Verbindungsabbauwunsch).

- `seq=101, ctl=FIN`

**Schritt 2:** Host B empfängt FIN und bestätigt mit **ACK**.

- `seq=300, ack=101, ctl=ACK`

**Schritt 3:** Host B sendet seinerseits **FIN** (eigener Abbauwunsch).

- `seq=301, ack=101, ctl=FIN`

**Schritt 4:** Host A bestätigt mit **ACK**. Die Verbindung ist beendet.

- `seq=102, ack=302, ctl=ACK`

-----

### TCP – Sliding Window

#### Motivation

- TCP muss die Menge an gleichzeitig übertragenen Bytes verarbeiten.
- Es gibt Methoden zur Bestätigung der Pakete und Flusskontrolle.
- Bei **Paketverlust** wird ab dem verlorenen Paket erneut übertragen (erkannt durch ausbleibende ACKs oder Timeout) → Garantie, dass alle Pakete ankommen.
- Pakete werden in der richtigen Reihenfolge an die Anwendungsschicht übergeben und müssen daher zwischengepuffert werden → Risiko eines **Pufferüberlaufs**.

#### Sliding Window Mechanismus

- Das Sliding Window regelt die **Senderate** in Bezug auf den Buffer des Empfängers.
- Der TCP-Stack hat unterschiedlich viel Speicher.
- Wird Verlust festgestellt, wird der Sender informiert.
- Der Sender **reduziert** daraufhin die Anzahl der zu sendenden Pakete pro Zeiteinheit.

#### Fenster-Größe = 1 (Stop-and-Wait)

Bei Fenstergröße 1 wird jeweils nur ein Paket gesendet und auf dessen ACK gewartet, bevor das nächste Paket gesendet wird. Bei Paketverlust: der **Retransmission-Timer** läuft ab und das Paket wird erneut gesendet.

**Beispiel mit Paketverlust (Fenstergröße 1):**

- Sender sendet Paket 1 → Empfänger bestätigt mit ACK 2.
- Sender sendet Paket 2 → Paket geht verloren.
- Retransmission-Timer läuft ab → Sender sendet Paket 2 erneut.
- Empfänger empfängt Paket 2 → Sendet ACK 3.

**Variante:** Das ACK geht verloren statt des Datenpakets. Der Sender sendet Paket 2 erneut, der Empfänger empfängt es doppelt (verwirft das Duplikat dank Sequenznummer) und sendet erneut ACK 3.

#### Fenster-Größe = 3

Mit einer größeren Fenstergröße können **mehrere Pakete** gleichzeitig gesendet werden, ohne auf einzelne ACKs zu warten.

- Das Fenster (Sliding Window) liegt über den zu sendenden Paketen.
- Alle Pakete innerhalb des Fensters werden verschickt.
- Beispiel mit Fenstergröße 3: Die ersten 3 Pakete werden verschickt. Paket 4 geht erst raus, wenn das ACK für Paket 1 eingetroffen ist.
- Pakete, für die kein ACK vorliegt, werden **nochmals verschickt**.

**Beispiel mit Paketverlust (Fenstergröße 3):**

- Sender sendet Pakete 1, 2, 3.
- Paket 2 geht verloren. Empfänger empfängt 1 und 3, sendet ACK 2 (fordert Paket 2 erneut an).
- Nach Empfang von ACK 2 sendet der Sender erneut Pakete 2, 3, 4.
- Empfänger empfängt 2, 3, 4 → Sendet ACK 5.

**Beispiel mit ACK-Verlust (Fenstergröße 3):**

- Sender sendet Pakete 1, 2, 3 → Empfänger empfängt alle, sendet ACK 4.
- ACK 4 geht verloren → Retransmission-Timer läuft ab.
- Sender sendet Paket 1 erneut → Empfänger empfängt 1 erneut, sendet ACK 4.
- Sender empfängt ACK 4 → Sendet Paket 4.

#### Gruppenaufgaben

**Aufgabe 1:** Sender sendet drei Pakete (seq=100, 101, 102; alle mit ack=5). Alle drei kommen beim Empfänger an.
**Lösung:** Empfänger antwortet mit `seq=5, ack=103, ctl=ACK` (erwartet als nächstes Paket 103).

**Aufgabe 2:** Sender sendet drei Pakete (seq=100, 101, 102; alle mit ack=5). Paket 101 geht verloren (nur 100 und 102 kommen an).
**Lösung:** Empfänger antwortet mit `seq=5, ack=101, ctl=ACK` (fordert Paket 101 erneut an, da es fehlt).

-----

### TCP – Flusskontrolle

- Pakete und Meldungen werden mit **Sequenznummern** versehen.
- Mögliche Übertragungsprobleme: doppelte Datenpakete, doppelte Quittierungen.
- Durch Nummern ist Reihenfolge und Zuordnung bekannt.
- Es folgen erst wieder Datenpakete, wenn das erste ACK kommt.
- Die **Fenstergröße wird während der Übertragung angepasst** durch:
  - **Slow Start:** Exponentielles Wachstum der Fenstergröße bis zum Threshold.
  - **Fast Retransmit:** Sofortige Neuübertragung ohne Warten auf den Timer, wenn **3 doppelte ACKs** empfangen werden.
  - **Additive Erhöhung (Congestion Avoidance):** Lineares Wachstum der Fenstergröße nach dem Threshold für faire und effiziente Zuteilung der Bandbreite.

#### CWND (Congestion Window) zur Vermeidung von Überlast

Das CWND beschreibt die Menge der unbestätigten Pakete. Der Verlauf über die Zeit:

1. **Slow-Start-Phase:** CWND wächst exponentiell (Verdopplung pro RTT).
2. Ab dem **Threshold** wechselt es in die **Congestion Avoidance** Phase: CWND wächst linear.
3. Bei **Fast Retransmit** (3 doppelte ACKs): CWND wird halbiert, neuer Threshold wird gesetzt, dann wieder lineares Wachstum.

-----

### UDP – User Datagram Protocol

#### Eigenschaften von UDP

- **Kein** Verbindungs-Aufbau / -Management (verbindungslos).
- **Ungesicherter Dienst** (keine Garantie für Zustellung).
- Verzichtet auf den bei TCP notwendigen Overhead.
- Für **Multicast** und **Broadcast** nutzbar.

#### UDP – Funktionsweise

UDP hat im Vergleich zu TCP die gleichen grundlegenden Funktionen (Port-Zuordnung, Datenweiterleitung), aber **keine**:

- Kontrollfunktion
- Sicherstellung von Datenempfang
- Nummerierung der Datenpakete

UDP ist **schlanker und einfacher** zu verarbeiten. Daten werden direkt an die Anwendungen weitergeleitet. Die Anwendung trägt selbst die Verantwortung für die Sicherstellung der Übertragung, zum Beispiel durch einen **Jitterbuffer**, der Laufzeitvarianzen ausgleicht.

Typische Einsatzgebiete: DNS-Anfragen, Echtzeit Audio-/Video-Streaming, VPN.

#### UDP-Header

Der UDP-Header ist mit nur **8 Byte** sehr schlank:

|Feld       |Größe |Beschreibung                           |
|-----------|------|---------------------------------------|
|Quell-Port |2 Byte|Source Port                            |
|Ziel-Port  |2 Byte|Destination Port                       |
|Länge      |2 Byte|Gesamtlänge von Header und Datenbereich|
|Check-Summe|2 Byte|CRC zur Fehlererkennung                |

Danach folgen die Daten.

#### Beispiele für UDP-Ports

|Port|Protokoll|Anwendung                                   |
|----|---------|--------------------------------------------|
|53  |DNS      |Domain Name Server                          |
|67  |DHCP     |Dynamic Host Configuration Protocol (Server)|
|68  |DHCP     |Dynamic Host Configuration Protocol (Client)|
|69  |TFTP     |Trivial File Transfer Protocol              |
|161 |SNMP     |Simple Network Management Protocol          |

-----

### SCTP – Stream Control Transmission Protocol

SCTP wurde im Jahr 2000 von der IETF als Transportprotokoll standardisiert. Eigenschaften:

- **Zuverlässig und verbindungsorientiert** (wie TCP).
- Unterstützt das Konzept von **Assoziationen** (logische Verbindungen).
- **Multistreaming:** Mehrere Datenströme gleichzeitig über eine einzige Assoziation möglich.
- **Multihoming:** Unterstützt mehrere IP-Adressen pro Endpunkt für Ausfallsicherheit.
- Dienstgüte ähnlich wie TCP (Fluss-/Überlastkontrolle).

Einsatzgebiete:

- Signalübertragung zwischen RAN und EPC in **LTE**.
- Transportprotokoll für das **Diameter-Protokoll** (AAA: Authentifizierung, Autorisierung, Abrechnung) in LTE.
- Control Plane Protokoll im **5G Core Netz**.
- Robuste **IoT-Anwendungen** (Internet of Things).

-----

## LAYER 3 – Network Layer (Vermittlungsschicht) – NAT

### Konzept von NAT in IPv4

**NAT (Network Address Translation)** wird in IPv4-Netzwerken verwendet, um die Anzahl benötigter öffentlicher IP-Adressen zu **minimieren** und gleichzeitig **Sicherheit** und **Flexibilität** des Netzwerks zu erhöhen.

NAT ermöglicht, dass mehrere Systeme in einem privaten Netzwerk über eine **einzige öffentliche IP-Adresse** auf das Internet zugreifen.

Hauptfunktionen:

- **Adressübersetzung:** Private IP-Adressen der internen Systeme werden in eine öffentliche IP-Adresse übersetzt.
- **Verstecken der internen Struktur:** Interne IP-Adressen sind von außen nicht sichtbar → erhöht die Sicherheit.
- **Verwaltung von IP-Adressen:** Organisationen können ihre internen Netzwerke unabhängig von den öffentlichen IP-Adressen verwalten.

-----

### Arten von NAT

|NAT-Typ                                          |Beschreibung                                                                                                   |
|-------------------------------------------------|---------------------------------------------------------------------------------------------------------------|
|**Static NAT**                                   |Feste 1:1-Zuordnung zwischen einer privaten und einer öffentlichen IP-Adresse                                  |
|**Dynamic NAT**                                  |Zuordnung von mehreren privaten IP-Adressen zu einer Gruppe (Pool) von öffentlichen IP-Adressen                |
|**PAT (Port Address Translation) / NAT Overload**|Mehrere private IP-Adressen teilen sich **eine einzige** öffentliche IP-Adresse, unterschieden über Portnummern|

-----

### Prozess der NAT-Umsetzung (PAT-Beispiel)

Szenario: Internes Netzwerk mit PC1 (192.168.1.2), PC2 (192.168.1.3), PC3 (192.168.1.4). Router hat die öffentliche IP-Adresse 203.0.113.5 und verwendet PAT.

**Ausgehender Verkehr (PC1 → Webserver 93.184.216.34):**

1. PC1 sendet ein Paket an 93.184.216.34. Das Paket hat Quell-IP 192.168.1.2.
2. Der Router empfängt das Paket und erkennt die private Quelladresse.
3. Er ändert die Quell-IP-Adresse auf seine öffentliche Adresse **203.0.113.5** und weist eine eindeutige L4-Portnummer zu (z.B. **10001**).
4. Das Paket wird mit der neuen Quelladresse 203.0.113.5:10001 ins Internet gesendet.

**Eingehender Verkehr (Antwort vom Webserver):**

1. Der Webserver antwortet an 203.0.113.5:10001.
2. Der Router empfängt die Antwort und schaut in seiner **NAT-Tabelle** nach.
3. Er übersetzt die Zieladresse zurück zu 192.168.1.2, indem er die Portnummer 10001 verwendet, um den richtigen internen PC zu identifizieren.

PC2 und PC3 erhalten eigene Portnummern (z.B. 10002, 10003). Der Router verwendet die **gleiche** öffentliche IP-Adresse, aber **verschiedene Ports** für die Zuordnung.

-----

### Zuweisung der Portnummer im Detail

- Die Portnummer wird vom **Router** während des NAT-Prozesses zugewiesen, wenn ein internes System eine Verbindung zu einem externen Server initiiert.
- Der Router führt eine Übersetzung der **Quell-IP-Adresse** und der **Quell-Portnummer** durch.
- Ein Eintrag in einer **NAT-Tabelle** wird erstellt, der die Zuordnung von interner IP:Port zu externer IP:Port speichert.
- Portnummern werden auf der **Transport-Schicht (Schicht 4)** des OSI-Modells zugewiesen und sind im **Transport-Header** (TCP oder UDP) des IP-Pakets kodiert.

**Konkretes Beispiel:**

- PC mit IP 192.168.1.2 und Quellport 50000 möchte zu Webserver 93.184.216.34 (Port 80 HTTP).
- IP-Paket enthält: IP-Header (Quell-IP 192.168.1.2, Ziel-IP 93.184.216.34) + TCP-Header (Quellport 50000, Zielport 80).
- Router ändert Quell-IP auf 203.0.113.5 und weist neuen Quellport 10001 zu.
- NAT-Tabelle: 192.168.1.2:50000 ↔ 203.0.113.5:10001.
- Paket wird gesendet mit Quell-IP 203.0.113.5, Quellport 10001. Die **Zielportnummer bleibt unverändert** (80).

-----

### Sicherheitskonzept hinter NAT

#### 1. Verstecken interner IP-Adressen

- NAT verbirgt die internen IP-Adressen der Systeme (**Anonymität**).
- Alle Systeme greifen mit der öffentlichen IP-Adresse des Routers auf das Internet zu.
- Angreifer können nicht direkt auf interne Systeme zugreifen, da die IP-Adressen nicht bekannt sind.
- Für mehrere Systeme (PCs, Smartphones etc.) sieht ein externer Server nur die öffentliche IP-Adresse des Routers.
- Interne Adressen (z.B. 192.168.1.2, 192.168.1.3) sind für den externen Server **unsichtbar**.

#### 2. Einschränkung eingehender Verbindungen

- NAT erlaubt standardmäßig **keine eingehenden Verbindungen** von externen Quellen.
- Nur **intern initiierte** Verbindungen erhalten eine Rückantwort.
- Ein Angreifer kann keine Verbindung nach intern herstellen, **außer** eine spezifische **Portweiterleitung** oder Regel wurde konfiguriert.
- Ein Webserver im Internet kann seine Antwort nur an die öffentliche IP-Adresse des Routers senden.

#### 3. Port Address Translation (PAT)

- Bei PAT (NAT Overload) nutzen alle Systeme dieselbe öffentliche IP-Adresse mit **verschiedenen Portnummern**.
- Erhöht die Sicherheit durch **Verringerung der Angriffsvektoren**.
- Ein Angreifer, der eine Verbindung zu 203.0.113.5 versucht, hat keine Information darüber, welches interne Gerät auf welchem Port aktiv ist.

#### 4. Einfachheit der Konfiguration

- NAT-Implementierungen bieten oft eine **eingebaute Firewall-Funktionalität**.
- Der NAT-Router blockiert automatisch unerwünschte eingehende Verbindungen.
- Viele Angriffsarten (z.B. Port-Scanning-Versuche) werden erschwert.

**Wichtig:** NAT ist **kein vollständiger Ersatz** für Sicherheitslösungen wie Firewalls oder Intrusion Detection Systems, sondern nur eine **weitere Ergänzung** der Sicherheitsarchitektur.

-----

### NAT in IPv6

Bei IPv6 wird die Notwendigkeit für NAT oft in Frage gestellt, da IPv6 einen nahezu **unbegrenzten Adressraum** bietet. NAT bleibt jedoch in bestimmten Szenarien relevant. Die relevanten Konzepte sind **NAT64** und **NPTv6**.

#### NAT64

NAT64 ermöglicht **IPv6-Clients den Zugriff auf IPv4-Ressourcen**.

Funktionsweise:

1. Ein IPv6-Client möchte auf einen IPv4-Webserver zugreifen (z.B. 203.0.113.10).
2. Der NAT64-Router übersetzt die Ziel-IPv4-Adresse in ein IPv6-Format. Die IPv4-Adresse 203.0.113.10 wird in das Well-Known IPv6-Präfix **64:ff9b::** eingebettet (Ergebnis z.B. 64:ff9b::cb00:710a).
3. Der Webserver sendet die Antwort zurück an die IPv4-Adresse des NAT64-Routers.
4. Der NAT64-Router übersetzt die Antwort von IPv4 zurück zu IPv6 und leitet sie an den Client weiter.

Vorteile von NAT64:

- **Interoperabilität:** IPv6-Clients erhalten Zugriff auf IPv4-Ressourcen.
- **Keine Änderungen an IPv4-Servern** nötig.
- **Erleichtert den Übergang** von IPv4 zu IPv6, da bestehende IPv4-Dienste weiterhin nutzbar bleiben.

#### NPTv6 (Network Prefix Translation)

NPTv6 ist eine Art NAT, die **nur das Präfix** einer IPv6-Adresse ändert (der Interface-Identifier bleibt gleich).

Anwendungsfall: Ein Netzwerk wechselt den ISP. Der neue ISP vergibt ein neues IPv6-Präfix (z.B. 2001:0db8:1234::/48 statt des alten 2001:0db8:abcd::/48). Der NPTv6-Router wird so konfiguriert, dass er eingehende/ausgehende Pakete mit dem alten Präfix in das neue Präfix übersetzt.

Beispiel: Quelladresse 2001:0db8:abcd:0001::1 wird zu 2001:0db8:1234:0001::1 übersetzt.

Vorteile von NPTv6:

- **Einfache Migration:** Internes Adressschema kann trotz ISP- oder Präfix-Wechsel beibehalten werden.
- **Minimale Änderungen:** Keine Neukonfiguration aller internen Geräte nötig.
- **Transparente Übersetzung:** Geschieht transparent für die internen Geräte, keine Änderungen an Anwendungen oder Diensten.

#### Warum NAT auch bei IPv6 noch relevant ist

- **Transition IPv4→IPv6:** In der Übergangsphase existieren noch viele IPv4-Ressourcen → NAT64 nötig.
- **Sicherheitsaspekte:** NAT verbirgt die interne Netzwerkstruktur. Auch wenn IPv6 Sicherheit durch IPsec bietet, möchten Organisationen möglicherweise zusätzliche Schutzmaßnahmen.
- **Routenmanagement:** NPTv6 ermöglicht präfixbasierte Strategien, die Routing und Netzwerkinfrastruktur vereinfachen.
- **Flexibles Adressmanagement:** Organisationen können Adressierungssysteme anpassen, ohne interne Strukturen zu beeinträchtigen → NPTv6.
- **Legacy-Systeme:** Viele bestehende Systeme sind noch auf IPv4 konfiguriert → NAT64 ermöglicht den gleichzeitigen Betrieb.

-----

## LAYER 7 – Application Layer (Anwendungsschicht) – DNS

### Domain Name Service (DNS) – Grundlagen

DNS ist ein **hierarchisches System** zur Namensauflösung. Es wandelt **Domainnamen** (z.B. www.example.com) in **IP-Adressen** (z.B. 192.0.2.1) um. Der Zweck ist die Verwendung leicht merkbarer Domainnamen statt numerischer IP-Adressen, was eine benutzerfreundliche Navigation im Internet ermöglicht.

Zwei Kernkomponenten:

- **Name-Server:** Software/Server zum Beantworten von DNS-Anfragen. Pro Zone gibt es einen primären Server.
- **Resolver:** Software zum Auflösen von Rechnernamen. Ergebnisse werden im Cache gespeichert (Caching).

-----

### DNS-Struktur (Hierarchien)

Das DNS ist hierarchisch aufgebaut:

- **Root-Domain:** Höchste Ebene, dargestellt als Punkt (.). Umfasst alle TLDs. Der Root-Server ist der Ausgangspunkt für alle DNS-Abfragen.
- **Top-Level-Domains (TLD):** z.B. .com, .net, .edu, .org, .gov, .de. Umfassen verschiedene Kategorien von Domains.
- **Second-Level-Domains:** z.B. example.com. Typischerweise der Name einer Organisation oder eines Unternehmens.
- **Subdomains:** z.B. www.example.com, mail.example.com. Befinden sich unter der Second-Level-Domain und dienen zur Strukturierung von Inhalten.

```
Root-Domain (.)
├── Top-Level-Domain (TLD)
│   ├── .com
│   ├── .org
│   └── .net
└── Second-Level-Domain
    ├── example.com
    └── test.org
        └── sub.test.org
```

-----

### FQDN – Fully Qualified Domain Name

- Besteht aus **Hostname** und **Domain-Name**.
- Domain-Name besteht aus Subdomain(s) und Toplevel-Domain.
- Trennung durch Punkte, der absolute Pfad endet mit einem **Punkt**.
- Format: `Hostname.Subdomain.Toplevel-Domain.` → Beispiel: `mail.example.com.`
- **Maximale Länge:** 255 Zeichen.
- Jede **Subdomain** ist 1 bis 63 Zeichen lang.
- **Protokoll:** UDP-Port 53 für normale Anfragen, TCP-Port 53 für Zonentransfer.

-----

### Root-DNS-Server

- Es gibt **13 Gruppen** von Root-DNS-Servern weltweit verteilt, bezeichnet mit Buchstaben **A bis M** (z.B. a.root-servers.net, b.root-servers.net usw.).
- Diese Root-Server sind **nicht speziell** für .com zuständig, sondern sind die erste Anlaufstelle für alle TLD-Anfragen.
- Aktuell bestehen die 13 Gruppen aus **1.907 Instanzen**, verwaltet von **12 Organisationen**.
- Die Verwaltung wird von der **ICANN** (Internet Corporation for Assigned Names and Numbers) koordiniert – einer gemeinnützigen Organisation, zuständig für die Koordination von IP-Adressen und Domainnamen.
- Website: root-servers.org
- **RIPE** (Réseaux IP Européens): 1989 gegründeter gemeinnütziger Verein als Forum zur technischen Koordination des Internets. **RIPE NCC** (RIPE Network Coordination Centre) hat seinen Sitz in Amsterdam.

-----

### DNS-Record-Typen

#### A-Record (Address Record)

- Verknüpft einen Domainnamen mit einer **IPv4-Adresse**.
- Eintrag: `example.com. IN A 192.0.2.1`
- Wenn jemand example.com eingibt, wird er zur IP-Adresse 192.0.2.1 geleitet.

#### AAAA-Record (IPv6 Address Record)

- Verknüpft einen Domainnamen mit einer **IPv6-Adresse**.
- Eintrag: `example.com. IN AAAA 2001:0db8:85a3:0000:0000:8a2e:0370:7334`

#### CNAME-Record (Canonical Name Record)

- Erstellt einen **Alias** für einen anderen Domainnamen.
- Eintrag: `www.example.com. IN CNAME example.com.`
- Zugriff auf www.example.com wird auf example.com umgeleitet. Alle Anfragen werden an die IP-Adresse von example.com weitergeleitet.

#### MX-Record (Mail Exchange Record)

- Gibt den **Mailserver** für die Domain an.
- Eintrag: `example.com. IN MX 10 mail.example.com.`
- E-Mails an example.com werden an mail.example.com weitergeleitet.
- Die Zahl (10) gibt die **Priorität** an: niedrigere Zahlen = höhere Priorität.

#### NS-Record (Name Server Record)

- Zeigt, welche DNS-Server **autoritativ** für die Domain sind.
- Eintrag: `example.com. IN NS ns1.exampledns.com.`

#### PTR-Record (Pointer Record)

- Auflösung einer **IP-Adresse zu einem Domainnamen** (Reverse DNS).
- Eintrag: `1.2.0.192.in-addr.arpa. IN PTR example.com.`
- IP-Adresse 192.0.2.1 wird auf example.com aufgelöst.

#### SOA-Record (Start of Authority Record)

- Enthält **administrative Informationen** über die Domain, einschließlich des primären DNS-Servers und der Kontaktinformationen.
- Eintrag: `example.com. IN SOA ns1.exampledns.com. hostmaster.example.com. (2023010101 ; Serial  3600 ; Refresh  1800 ; Retry  604800 ; Expire  86400 ; Minimum TTL)`

Felder des SOA-Records:

- **Name:** Domainname
- **TTL bei Antwort:** Wie lange Informationen gespeichert werden
- **Zonen-Klasse (IN):** Steht für Internet
- **Primärer Server:** Domain Name des primären DNS-Servers (Master)
- **Verantwortlicher:** E-Mail-Adresse des Administrators (mit `.` statt `@`)
- **Seriennummer:** Nummer der Zonendatei, anhand derer Secondary-Server erkennen, ob eine Aktualisierung nötig ist
- **Refresh-Zeit:** Zeit in Sekunden, die ein Secondary Server wartet, bevor er erneut die Seriennummer abfragt (typisch 1–12h)
- **Retry-Zeit:** Erneuter Versuch, wenn Refresh nicht erfolgreich war
- **Expire-Zeit:** Gültigkeitsdauer in Sekunden. Nach Ablauf gibt der Secondary keine Antworten mehr
- **TTL bei keiner Antwort (Minimum):** Dauer der Speicherung von „Domain existiert nicht”-Antworten. Verhindert Überlastungen

Beispiel SOA-Record für google.com (abfragbar mit `nslookup –type=SOA google.com`):

```
google.com.  21599  IN  SOA  ns1.google.com. dns-admin.google.com.
    2023032701 ; serial
    7200       ; refresh (2 hours)
    1800       ; retry (30 minutes)
    604800     ; expire (1 week)
    60         ; minimum (1 minute)
```

-----

### DNS-Server und Resolver

#### Aufgaben eines DNS-Servers

- Hostet die DNS-**Zonendateien**.
- Ist **autoritativ** für bestimmte Domains.
- Liefert Informationen über Domainnamen und deren zugehörige IP-Adressen.

#### Aufgaben eines DNS-Resolvers

- Ist **nicht autoritativ**, bearbeitet Anfragen von Clients.
- Liefert IP-Adressen an den Client.
- Fungiert als **Vermittler** zwischen dem Client und den DNS-Servern.

#### DNS-Resolver Installation

- Kann ein öffentlicher DNS-Resolver eines ISPs sein.
- Kann ein separater, lokaler Server in einem Unternehmensnetzwerk sein.
- Cloud Provider bieten DNS-Resolver als Teil ihres Services an.

-----

### DNS-Namensauflösung – Zwei Methoden

#### 1. Rekursive Anfrage (Verantwortung beim DNS-Resolver)

Der Resolver übernimmt die **komplette Auflösung** im Auftrag des Clients:

1. Benutzer fragt im Browser nach www.example.com → Client fragt den lokalen DNS-Resolver.
2. Resolver prüft seinen **Cache**. Falls vorhanden: IP-Adresse direkt zurückgeben.
3. Falls nicht im Cache: Resolver fragt einen **Root-DNS-Server** → dieser gibt den TLD-Server für .com zurück.
4. Resolver fragt den **TLD-Server** → dieser gibt den autoritativen DNS-Server für example.com zurück.
5. Resolver fragt den **autoritativen DNS-Server** → dieser gibt die IP-Adresse zurück.
6. Resolver gibt die IP-Adresse an den Client und **speichert sie im Cache**.

#### 2. Iterative Anfrage (Anfrage an andere Server)

Der Resolver fragt nur **einmal** den bekannten DNS-Server. Hat der Server die Antwort nicht, gibt er entweder die IP-Adresse eines anderen Servers zurück oder einen Fehler.

Ablauf:

1. Client-Anfrage geht ein, Resolver prüft den Cache.
2. Sendet Abfrage an den **Root-DNS-Server**.
3. Root-Server liefert die Adresse des **TLD-Servers** (nicht die finale Antwort).
4. Resolver muss dann **separat** den TLD-Server anfragen.
5. Falls der TLD-Server die Antwort nicht hat, verweist er auf den autoritativen Server → Resolver stellt **erneute Anfrage**.
6. IP-Adresse wird an den Client geliefert, nachdem alle Anfragen durchgeführt sind.

**Vergleich:**

- **Rekursiv** wird verwendet, wenn eine vollständige Auflösung gewünscht ist → Standardkonfiguration der meisten DNS-Resolver der ISPs.
- **Iterativ** wird in bestimmten Architekturen verwendet, mit eventuellen Vorteilen bei Ressourcennutzung, Kontrolle, Sicherheit und Performance.

-----

### DNS – Root Zone Management

Die **IANA** (Internet Assigned Numbers Authority) ist verantwortlich für das Management der DNS Root Zone. Sie weist Operators zu Top-Level Domains zu und verwaltet die administrativen Details → **Root Zone Database**.

IANA-Whois-Service zeigt Informationen zu TLDs:

- **.com** (USA): Registriert 1985, Organisation: VeriSign Global Registry Services, Reston VA.
- **.cn** (China): Registriert 1990, Organisation: China Internet Network Information Center (CNNIC), Beijing.
- **.de** (Deutschland): Registriert 1986, Organisation: DENIC eG, Frankfurt am Main.

-----

### DNS-Zone

- Eine Zone ist der **Teil des Domain-Baumes**, für den ein Server zuständig ist.
- Ein Server kann **primäre und sekundäre** Zonen verwalten.
- Daten werden in der **primären Zone** gepflegt.
- Übertragung an Secondary DNS-Server erfolgt über **Zonentransfer** (Backup-Server).

**Zwei Mechanismen für Zonentransfer:**

1. **Benachrichtigung durch Master (Push):** Der Master (Primary) unterrichtet die Slaves (Secondaries) über Änderungen. Der Slave fordert dann die geänderten Daten oder die komplette Zone an.
2. **Daten werden vom Slave angefordert (Pull):** Der Secondary DNS-Server fordert regelmäßig den **SOA-Record** an und vergleicht die **Seriennummer**. Falls die Seriennummer des Secondary kleiner ist als die des Servers → Zonentransfer wird eingeleitet.

-----

### DNS – Reverse Lookup

Reverse Lookup ist die Umsetzung einer **IP-Adresse in einen Namen** (umgekehrte Richtung zur normalen Namensauflösung).

- Zone: `in-addr.arpa.` für IPv4, `ip6.arpa.` für IPv6.
- IP-Oktette werden **von rechts nach links** aufgelöst.
  - IP: 134.30.15.41 → Reverse: `41.15.30.134.in-addr.arpa.`
- Jedes Oktett der IP-Adresse bildet eine **Ebene** in der DNS-Hierarchie.
- Adressen können in höheren Ebenen eingetragen sein.
- Feinere Unterteilungen als **/24** sind nicht möglich.

-----

### Dynamisches DNS (DDNS ≠ DynDNS)

#### Dynamische Client-Konfiguration

- Name wird vom DHCP-Server zugeordnet.
- Client behält seinen Namen und nimmt nur die IP vom DHCP-Server.

#### DynDNS

- Konstante Aktualisierung der IP-Adresse für ein Domainame
- Aktualisierung über **Web-Interface** oder **Client-Software**.
- Die letzte Zuordnung bleibt bestehen.
- Verwendet **sehr kurze TTL**, damit Änderungen schnell wirksam werden.

#### DDNS

- Aktualisierung **direkt beim Name-Server** (standardisiertes DNS-Update-Protokoll).
- Aktualisierungen werden an andere Server der Zone **weitergereicht**.
- Erfordert **Authentifizierung**.

-----

### DNS – Service Record (SRV)

SRV-Records ermöglichen es, **Dienste dynamisch zu lokalisieren**. Sie sind ein spezieller Typ von DNS-Eintrag, der Informationen über Dienste bereitstellt. Clients können den Standort eines bestimmten Dienstes (z.B. VoIP, Instant Messaging) finden, ohne im Voraus zu wissen, auf welchem Server der Dienst läuft.

#### Struktur eines SRV-Records

|Feld        |Beschreibung                                                   |
|------------|---------------------------------------------------------------|
|**Service** |Name des Dienstes (z.B. `_sip` für SIP)                        |
|**Protocol**|Verwendetes Protokoll (z.B. `_tcp`, `_udp`)                    |
|**Name**    |Domainname, für den der SRV-Record gilt                        |
|**Priority**|Priorität des Dienstes (niedrigere Werte = höhere Priorität)   |
|**Weight**  |Gewicht für Lastenausgleich zwischen Servern gleicher Priorität|
|**Port**    |Port, über den der Dienst erreichbar ist                       |
|**Target**  |Zielhost, der den Dienst bereitstellt                          |

#### Beispiel: SRV-Record für VoIP über UDP

```
_sip._udp.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com.
```

Erklärung der Felder:

- `_sip._udp`: SIP-Dienst über UDP-Protokoll. Der Unterstrich `_` kennzeichnet einen speziellen Dienst.
- `example.com.`: Domain, die den VoIP-Dienst bereitstellt.
- `3600`: TTL in Sekunden (1 Stunde).
- `IN`: Klasse Internet.
- `SRV`: Record-Typ.
- `10`: Priorität (höhere Priorität als z.B. ein Eintrag mit 20).
- `60`: Gewicht für Lastverteilung (höherer Wert = höhere Wahrscheinlichkeit, ausgewählt zu werden).
- `5060`: Port für SIP über UDP.
- `sipserver.example.com.`: Hostname des SIP-Servers.

SRV-Records sind besonders nützlich für VoIP-Dienste, da sie Clients ermöglichen, dynamisch den richtigen Server zu finden.

-----

### Sicherheitsaspekte von DNS

#### 1. DNS Spoofing (Cache Poisoning)

- **Angriff:** Angreifer sendet **gefälschte DNS-Antworten** an einen DNS-Resolver, um dessen Cache zu manipulieren.
- **Auswirkung:** Benutzer werden auf gefälschte oder schadhafte Websites umgeleitet.
- **Schutzmaßnahmen:**
  - **DNSSEC** (Domain Name System Security Extensions): Fügt **digitale Signaturen** zu DNS-Daten hinzu, um deren Authentizität zu überprüfen. Stellt sicher, dass die Daten nicht manipuliert wurden.

#### 2. DDoS-Angriffe (Distributed Denial of Service)

- **Angriff:** DNS-Server werden mit einer großen Anzahl von Anfragen **überflutet**. Richtige Anfragen erhalten keinen Zugriff auf den Dienst.
- **Schutzmaßnahmen:**
  - **Lastverteilung** auf mehrere Server (Minimierung der Auswirkung).
  - **Rate-Limiting:** Begrenzt die erlaubte Anzahl der Anfragen einer IP-Adresse in einem bestimmten Zeitraum.
  - Spezialisierte **DDoS-Schutzlösungen** (z.B. Cloudflare, Akamai, AWS Shield), die Traffic in Echtzeit analysieren und Angriffe abwehren.

#### 3. DNS-Tunneling

- **Angriff:** Angreifer installiert Malware, die **Daten über DNS-Anfragen und -Antworten** sendet. Daten werden in kleinen DNS-Paketen übertragen (Datenexfiltration oder Command-and-Control-Kommunikation).
- **Schutzmaßnahmen:**
  - Überwachung des DNS-Verkehrs auf **ungewöhnliche Muster**.
  - Mittels **Firewall-Regeln** DNS-Anfragen auf autorisierte Server begrenzen.

#### 4. Man-in-the-Middle-Angriffe

- **Angriff:** Abfangen der Kommunikation zwischen Client und DNS-Server. **Manipulation** der DNS-Anfragen oder Weiterleiten auf schädliche Webseiten.
- **Schutzmaßnahmen:**
  - Verwendung von **DNSSEC** stellt sicher, dass DNS-Antworten authentisch sind.
  - **Verschlüsselung** der DNS-Kommunikation durch DNS-over-HTTPS (DoH) oder DNS-over-TLS (DoT).

#### 5. Phishing über DNS

- **Angriff:** Nutzung gefälschter DNS-Einträge (z.B. A-Record oder SRV-Record), um Benutzer auf **bösartige Websites** umzuleiten (z.B. gefälschte Bank-Website). Benutzer werden dazu gebracht, Anmeldedaten einzugeben.
- **Schutzmaßnahmen:**
  - **Bewusstsein und Schulung:** Benutzer sollten über die Risiken von Phishing informiert und geschult werden, um verdächtige Links zu erkennen.
  - **DNS-Filtering:** Technologien, die den Zugriff auf bekannte bösartige Domains blockieren.