Hier entwirfst du die Namen von HLG: öffentlich für Kunden, intern für den Betrieb und dynamisch für das Stationsbüro.
Sprint 2Brückenstufe 2
Eure Story: Als IT-Leitung HLG will ich, dass die Welt track.hlg.example findet und jeder Standort ins Netz kommt, damit Kunden ihre Sendung rund um die Uhr sehen.
Input · Namen auflösen. Holt ihn euch, wenn eure Storycard danach fragt. Zahlt ein auf AB 4 bis 7.
Du verfolgst die Auflösungskette im Mitschnitt, liest und schreibst eine Zone, rechnest mit TTL-Werten und richtest Zone, Split-DNS und DDNS im Labor ein.
0 von 7 AB abgehakt AB-Liste öffnen
Der wichtigste Satz auf dieser Seite: Ein Name ist eine Zusage: Wer ihn eintippt, landet am richtigen Ort. Die TTL entscheidet, wie lange eine Änderung braucht, bis alle sie sehen.
Am Ende hast du: ein Namenskonzept für hlg.example mit internen und externen Einträgen, Split-DNS für die Sendungsverfolgung und DDNS für station.hlg.example, eingerichtet und mit Abfragen von außen und innen nachgewiesen.
Karte „Adressen und Routing kompakt“: Was du aus dem Netzaufbau brauchst, auf einer Seite: Adressen, Subnetze, Routing, die drei Standorte. Die Karte steht im Wissensspeicher.
Erst du, dann die anderen
Die IT-Leitung fragt: „Wer soll unsere Namen im Internet beantworten, wir selbst oder jemand anderes?“ Wie würdest du vorgehen?
So gehen andere vor. Such dir einen Weg aus.
- DNS-Anbieter betreibt die öffentliche Zone. Zwei oder mehr Server an verschiedenen Orten, Pflege über eine Oberfläche oder Schnittstelle. Ausfallsicher und wenig Aufwand. Der Preis: Abhängigkeit vom Anbieter, und DDNS muss er unterstützen.
- HLG betreibt die Zone selbst im Hub. Volle Kontrolle, Zone als Datei, DDNS direkt. Der Preis: Fällt das Hub aus, ist auch der Name weg; mindestens ein zweiter Server an einem anderen Ort ist Pflicht.
- Verborgener Primärserver. HLG pflegt die Zone als Datei auf einem internen Server, der Anbieter übernimmt sie als Sekundärserver und beantwortet alle Fragen. Kontrolle und Ausfallsicherheit zusammen. Der Preis: mehr Einrichtung und eine Zonenübertragung, die abgesichert sein muss.
Es gibt hier nicht den einen richtigen Weg. Die Referenzlösung lässt die öffentliche Zone beim Anbieter und betreibt intern.hlg.example selbst. In Aufgabe 4.6 entscheidet ihr.
Gegebene Werte: Namen und Adressen · aufklappen, wenn du sie brauchst
Gegebene Werte: Namen und Adressen
- Öffentlich
- track und Zone selbst 203.0.113.3, mail 203.0.113.4, vpn 203.0.113.2, station dynamisch
- IPv6 (Unterrichtswert)
- track 2001:db8:5a1:10::10, mail 2001:db8:5a1:10::20
- Namensserver öffentlich
- ns1.anbieter.example (198.51.100.53), ns2.anbieter.example
- Resolver intern
- 10.10.40.53 im Server-Netz des Hub, bedient alle drei Standorte
- Split-DNS
- track.hlg.example intern 172.16.10.10, außen 203.0.113.3
- DDNS
- station.hlg.example, TTL 60 s, Router meldet eine neue Adresse binnen 30 s (Unterrichtswert)
- Wartungsfenster
- nachts zwischen 23 und 5 Uhr, Lastspitze 5 bis 6 und 22 bis 23 Uhr
Die Domäne hlg.example ist für Dokumentation reserviert und wird im echten Internet nicht aufgelöst. Im Labor spielt dein eigener Server alle Rollen.
Dein Lernprodukt im Einzelnen
Dein Lernprodukt
Namenskonzept hlg.example
Darauf laufen die Aufgaben dieses Lernangebots zu. Die Aufgaben sind die Stufen dorthin, das Lernprodukt ist das Ergebnis.
Es besteht aus
- der öffentlichen Zone mit SOA, NS, A, AAAA, MX, CNAME, TXT und begründeter TTL je Eintrag
- den internen Einträgen: Unterzone intern.hlg.example und Split-DNS für track.hlg.example
- DDNS für station.hlg.example mit Ablauf, Schlüssel und TTL
- den Nachweisen: Abfrage von außen und von innen, Mitschnitt der Auflösung, Adresswechsel der Station im Test
Zur Dokumentation
Eine Tabelle der Einträge (Name, TTL, Typ, Wert, Wozu), die Zonendatei und die Abfrageergebnisse mit Datum. Eingerichtet einmal über eine Oberfläche, einmal über eine Konfigurationsdatei.
Das Namenskonzept geht in Meilenstein M2 ein. In Teil 3 kommen die Einträge für Mail und Telefonie hinzu, in Teil 5 das Zertifikat für track.hlg.example.
Die Beispielzone hlg.example
So sieht die öffentliche Zone als Konfigurationsdatei aus (Format nach RFC 1035, wie BIND sie liest). Die Tabelle darunter erklärt jeden Eintrag.
$TTL 3600 ; Standard: eine Stunde
$ORIGIN hlg.example.
@ IN SOA ns1.anbieter.example. hostmaster.hlg.example. (
2026110501 ; Seriennummer: Datum plus Zähler
7200 ; Refresh: Sekundärserver fragt alle 2 h
900 ; Retry: nach Fehler alle 15 min
1209600 ; Expire: nach 14 Tagen ohne Primärserver aufgeben
300 ) ; negative TTL: "gibt es nicht" 5 min merken
@ IN NS ns1.anbieter.example.
@ IN NS ns2.anbieter.example.
@ IN MX 10 mail.hlg.example.
@ IN TXT "v=spf1 mx -all"
@ IN A 203.0.113.3
track 300 IN A 203.0.113.3
track 300 IN AAAA 2001:db8:5a1:10::10
www IN CNAME track.hlg.example.
mail IN A 203.0.113.4
mail IN AAAA 2001:db8:5a1:10::20
vpn IN A 203.0.113.2
station 60 IN A 198.51.100.77 ; DDNS, Router aktualisiert
intern IN NS ns.intern.hlg.example. ; nur intern erreichbar| Name | TTL | Typ | Wert | Wozu |
|---|---|---|---|---|
| hlg.example | 3600 | SOA | ns1.anbieter.example, Serie 2026110501 | Verwaltungsdaten der Zone |
| hlg.example | 3600 | NS | ns1.anbieter.example, ns2.anbieter.example | wer für die Zone zuständig ist |
| hlg.example | 3600 | MX | 10 mail.hlg.example | wohin Mail für @hlg.example geht |
| hlg.example | 3600 | TXT | v=spf1 mx -all | nur der MX darf als hlg.example senden |
| track | 300 | A | 203.0.113.3 | Sendungsverfolgung, IPv4 |
| track | 300 | AAAA | 2001:db8:5a1:10::10 | Sendungsverfolgung, IPv6 ohne Übersetzung |
| www | 3600 | CNAME | track.hlg.example | zweiter Name für dieselbe Seite |
| 3600 | A, AAAA | 203.0.113.4, 2001:db8:5a1:10::20 | Mail-Relay | |
| vpn | 3600 | A | 203.0.113.2 | VPN-Ende der Firewall |
| station | 60 | A | 198.51.100.77 | dynamisch, per DDNS |
Die interne Zone intern.hlg.example
$TTL 3600
$ORIGIN intern.hlg.example.
@ IN SOA ns.intern.hlg.example. hostmaster.hlg.example. (
2026110501 3600 900 604800 300 )
@ IN NS ns
ns IN A 10.10.40.53
fs IN A 10.10.40.10
pbx IN A 10.10.30.10
nvr IN A 10.10.50.10
gw-hub IN A 10.10.0.1
gw-station IN A 10.20.0.1
gw-lager IN A 10.30.0.1
; Split-DNS: der interne Resolver beantwortet track.hlg.example mit 172.16.10.10Mitschnitt D: Ein Kunde löst track.hlg.example auf
Zusammengefasst aus dem Mitschnitt am Resolver eines Anbieters. Die Adressen von Wurzel und Endungsserver lassen wir weg.
| Nr. | Messpunkt | Quelle (Adresse:Port) | Ziel (Adresse:Port) | Protokoll | Info |
|---|---|---|---|---|---|
| D1 | Kunde | 198.51.100.200:53001 | Resolver Anbieter :53 | UDP | Abfrage A track.hlg.example |
| D2 | Resolver | Resolver | Wurzelserver :53 | UDP | Frage, Antwort verweist auf Server für .example |
| D3 | Resolver | Resolver | Server für .example :53 | UDP | Frage, Antwort verweist auf ns1.anbieter.example |
| D4 | Resolver | Resolver | ns1.anbieter.example (198.51.100.53):53 | UDP | Frage, autoritative Antwort A 203.0.113.3, TTL 300 |
| D5 | Kunde | Resolver Anbieter :53 | 198.51.100.200:53001 | UDP | Antwort: A 203.0.113.3 |
| D6 | Kunde | 198.51.100.200:61022 | 203.0.113.3:443 | TCP | SYN, weiter wie Mitschnitt B |
Mitschnitt E: Ein Büro-PC im Hub löst denselben Namen auf
| Nr. | Messpunkt | Quelle (Adresse:Port) | Ziel (Adresse:Port) | Protokoll | Info |
|---|---|---|---|---|---|
| E1 | innen | 10.10.10.30:53877 | 10.10.40.53:53 | UDP | Abfrage A track.hlg.example |
| E2 | innen | 10.10.40.53:53 | 10.10.10.30:53877 | UDP | Antwort: A 172.16.10.10 (Split-DNS) |
| E3 | innen | 10.10.10.30:52210 | 172.16.10.10:443 | TCP | SYN, direkt in die DMZ |
| außen | nichts | kein Paket verlässt das Hub |
Deine Aufgaben
4.1Verfolge die Auflösungskette
Jetzt bist du dran · Allein · 4 Arbeitsschritte
zahlt ein auf AB 4Öffnen ▾Schließen ▴
Aufgabe 4.1
Verfolge die Auflösungskette:
- Ordne zu: jedes Paket aus Mitschnitt D einer Station im Bild der Auflösungskette.
- Unterscheide: rekursive Abfrage (Kunde an Resolver) und iterative Abfragen (Resolver an die Server).
- Erkläre: woran du in D4 erkennst, dass die Antwort autoritativ ist.
- Beschreibe: was bei einer zweiten Abfrage nach 120 s anders läuft.
Allein Diese Aufgabe bearbeitest du allein.
4.2Lies die Beispielzone
Jetzt seid ihr dran · Zu zweit · 4 Arbeitsschritte
zahlt ein auf AB 5Öffnen ▾Schließen ▴
Aufgabe 4.2
Lies die Beispielzone:
- Erkläre: die fünf Zahlen im SOA-Eintrag.
- Ordne zu: welcher Eintrag welche Frage beantwortet (Wohin geht Mail? Welche IPv6-Adresse hat track? Wer ist zuständig?).
- Begründe: weshalb www als CNAME und nicht als zweiter A-Eintrag angelegt ist.
- Prüfe: ob ein CNAME für hlg.example selbst erlaubt wäre.
Zu zweit Diese Aufgabe bearbeitet ihr zu zweit.
4.3Berechne die Folgen der TTL
Jetzt seid ihr dran · Zu zweit · 4 Arbeitsschritte
zahlt ein auf AB 4Öffnen ▾Schließen ▴
Aufgabe 4.3
Berechne die Folgen der TTL:
- Berechne: wie lange Resolver nach einem Wechsel von station.hlg.example höchstens die alte Adresse liefern, mit TTL 60 s und mit TTL 3600 s.
- Plane: den Umzug von track.hlg.example auf 203.0.113.6 in der Nacht von Samstag auf Sonntag um 2:00 Uhr; berechne, bis wann die TTL spätestens gesenkt sein muss und ab wann alle Caches die neue Adresse haben.
- Berechne: wie lange ns2 höchstens veraltete Daten liefert, wenn die Benachrichtigung nach einer Änderung verloren geht.
- Begründe: weshalb ein Name, der vor dem Anlegen schon abgefragt wurde, bis zu 300 s „gibt es nicht“ liefert.
Zu zweit Diese Aufgabe bearbeitet ihr zu zweit.
4.4Entwirf das Namenskonzept für hlg.example
Jetzt seid ihr dran · Im Team · 4 Arbeitsschritte
zahlt ein auf AB 4Öffnen ▾Schließen ▴
Aufgabe 4.4
Entwirf das Namenskonzept für hlg.example:
- Lege fest: die öffentlichen Einträge mit Typ, Wert und TTL.
- Lege fest: die internen Einträge und die Antwort für track.hlg.example von innen.
- Begründe: jede TTL in einem Satz.
- Prüfe: ob jede öffentliche Adresse in deiner Zone zu einer Zeile deiner Übersetzungstabelle aus 3.4 passt.
Im Team Diese Aufgabe bearbeitet ihr im Team.
4.5Richte die Zone ein und weise die Auflösung nach
Jetzt seid ihr dran · Im Team · 5 Arbeitsschritte
zahlt ein auf AB 5 und 6Öffnen ▾Schließen ▴
Aufgabe 4.5
Richte die Zone ein und weise die Auflösung nach:
- Richte ein: die Zone hlg.example als Konfigurationsdatei in BIND (Docker).
- Richte ein: Split-DNS für track.hlg.example und die Unterzone intern.hlg.example einmal über die Oberfläche eines Resolvers.
- Prüfe: mit Abfragen von außen und von innen, ob track.hlg.example 203.0.113.3 und 172.16.10.10 liefert.
- Schneide mit: eine Auflösung mit Wireshark und vergleiche sie mit Mitschnitt D und E.
- Richte ein: DDNS für station.hlg.example mit Schlüssel und weise einen Adresswechsel nach.
Im Team Diese Aufgabe bearbeitet ihr im Team.
Laborvorschlag (zweimal 90 Minuten)
Konfigurationsdatei: BIND in einem Docker-Container als autoritativer Server für hlg.example, die Zonendatei oben als Vorlage. Prüfen mit dig @127.0.0.1 track.hlg.example A und dig ... AAAA, MX, SOA. Die Zone vor dem Laden mit named-checkzone hlg.example db.hlg.example prüfen.
Oberfläche: Unbound als Resolver, entweder in einem zweiten Container mit Weiterleitung an den BIND-Container oder über die Oberfläche von OPNsense (Eintrag für track.hlg.example als lokale Überschreibung auf 172.16.10.10, Weiterleitung von intern.hlg.example an 10.10.40.53).
DDNS: Schlüssel mit tsig-keygen erzeugen, in BIND für station.hlg.example erlauben, Wechsel mit nsupdate nachstellen, danach mit dig abfragen. Mitschnitt mit Wireshark, Filter dns.
4.6Entscheide, wie HLG seine Namen betreibt
Jetzt seid ihr dran · Im Team · 3 Arbeitsschritte
zahlt ein auf AB 6 und 7Öffnen ▾Schließen ▴
Aufgabe 4.6
Entscheide, wie HLG seine Namen betreibt:
- Vergleiche: die drei Wege aus „Erst du, dann die anderen“ nach Ausfallsicherheit, Aufwand und Abhängigkeit.
- Vergleiche: Split-DNS für einzelne Namen und eine getrennte Unterzone intern.hlg.example.
- Entscheide: begründet für HLG und benenne, was ihr dafür in Kauf nehmt.
Im Team Diese Aufgabe bearbeitet ihr im Team.
Stufen: 4.1 und 4.2 sind Abfolge (Stufe I), 4.3 bis 4.5 Algorithmus (Stufe II), 4.6 ist eine offene Entscheidung (Stufe III).
Veränderter Fall
Das Stationsbüro bekommt keine eigene öffentliche Adresse mehr, nur eine geteilte hinter Carrier-NAT. Prüfe: Worauf zeigt station.hlg.example nach dem nächsten DDNS-Update, und was erreicht ein Kunde dort? Beurteile, ob der Name bleiben soll. Leite die Änderung in deinem Namenskonzept ab.