Übungsaufgaben zu Netzwerkdiensten: DHCP, DNS, ARP, APIPA und NTP

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „Netzwerkdienste: DHCP, DNS, ARP,
APIPA und NTP“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/dhcp-dns-arp
- https://oer-informatik.de/routing
- Stilbeispiel: https://oer-informatik.de/dhcp-dns-arp-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- DHCP
- DNS
- ARP
- APIPA
- NTP
- DHCP-Relay
- DHCP-Reservierung
- DNS-Forwarder
- Split-horizon DNS
- DNSSEC

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

Angaben (je 1 Punkt, drei aus):

• IPv4-Adresse aus dem Werkstattnetz (192.168.40.23 statt 169.254.37.201)

• Subnetzmaske 255.255.255.128 (beim PC 255.255.0.0)

• Standardgateway 192.168.40.1 (beim PC leer)

• DNS-Server 192.168.40.1 (beim PC fehlt er)

• Lease mit Beginn und Ablauf (beim PC keine)

Herkunft der Adresse (2 Punkte): Der PC steht auf automatischem Adressbezug, hat auf seine DHCP-Anfragen aber keine Antwort bekommen. Statt ohne Adresse zu bleiben, hat er sich selbst eine verbindungslokale Adresse aus 169.254.0.0/16 gegeben (APIPA, „Autokonfiguration“) und vorher per ARP geprüft, dass sie frei ist. Die Zeile „DHCP-Server“ fehlt, weil kein Server beteiligt war. Das Tablet bezieht seine Adresse übrigens auch per DHCP, sie ist dort als Reservierung hinterlegt.

Je Ursache 1 Punkt, je passende Prüfung 1 Punkt, zwei aus:

• ipconfig /renew (1 Punkt; unter Linux z. B. nmcli connection up <name> oder dhclient)

• den DHCP-Server, hier der Router 192.168.40.1 (1 Punkt)

• Befehl (1 Punkt): ipconfig /all (Zeile „Physische Adresse“) oder getmac /v; unter Linux ip link.

• Aufbau (1 Punkt): Die ersten drei Bytes 00-40-8C sind die Herstellerkennung (OUI, von der IEEE vergeben), die letzten drei Bytes 1D-72-E9 vergibt der Hersteller fortlaufend für jede Netzwerkkarte.

• Prüfung (1 Punkt): In der MAC-Adresstabelle des Switches die Adresse am fraglichen Port ablesen. Stimmt sie vollständig mit der Kamera überein, ist es die Kamera; passt nur die OUI, ist es zumindest ein Gerät desselben Herstellers, eine andere OUI schließt die Kamera aus. (MAC-Adressen lassen sich fälschen, die Prüfung ersetzt also keine Anmeldung per 802.1X.)

Je Feld 1 Punkt (Fehler mit Begründung und Korrektur):

• IP-Adresse: .95 liegt im DHCP-Bereich .81 bis .126; der Router könnte sie einem anderen Gerät zuteilen. Richtig ist eine freie Adresse von .2 bis .79, z. B. 192.168.40.30 (nicht .23 und nicht .80, die sind vergeben).

• Subnetzmaske: Das Netz ist ein /25, also 255.255.255.128. Mit /24 hält das Gerät auch .128 bis .254 für eigene Nachbarn.

• Standardgateway: .126 ist eine Adresse aus dem DHCP-Bereich, nicht der Router; richtig ist 192.168.40.1.

• DNS-Server: Ohne Eintrag kann das Gerät keine Namen auflösen; einzutragen ist 192.168.40.1.

Richtig sind 2 und 4 (je 1 Punkt). Zu 1: Eine APIPA-Adresse hat kein Gateway und keinen DNS-Server, das Gerät erreicht nur Nachbarn mit APIPA-Adresse. Zu 3: Eine von Hand eingetragene Adresse braucht keinen DHCP-Server.

• Das Terminal wollte Daten an 10.110.0.31 senden und hat mit seiner Subnetzmaske festgestellt, dass das Ziel im eigenen Netz liegt. (1 Punkt)

• Es hat per ARP-Request als Broadcast gefragt, wer 10.110.0.31 hat; das Gerät mit dieser Adresse hat per ARP-Reply seine MAC-Adresse 00-80-92-5c-31-07 genannt. Das Terminal hat das Paar als „dynamisch“ im ARP-Cache gespeichert. (1 Punkt)

• Im LAN werden Frames an MAC-Adressen zugestellt; ohne die MAC-Adresse könnte das Terminal den Frame nicht adressieren. (1 Punkt)

Je Gerät 1 Punkt (IP- und MAC-Adresse mit Begründung):

• CHK-01: 10.110.0.21 und 3C-22-FB-10-00-01. Die eigene IP-Adresse steht hinter „Schnittstelle“, die eigene MAC-Adresse nicht in der ARP-Tabelle, sondern in ipconfig /all unter „Physische Adresse“.

• Firewall: 10.110.0.1 und 00-1a-8c-0a-6e-01, denn 10.110.0.1 ist laut ipconfig /all das Standardgateway.

• CHK-02: 10.110.0.22 und 3c-22-fb-10-00-02. Die ersten drei Bytes stimmen mit CHK-01 überein (gleicher Hersteller, gleiches Modell).

• DR-01: 10.110.0.31 und 00-80-92-5c-31-07, die einzige verbleibende Zeile mit einer anderen Herstellerkennung. Sicher bestätigen lässt es sich z. B. mit einer Statusseite, die der Drucker ausdruckt.

Der Browser kennt nur den Namen anmeldung.barcamp.example. Das Terminal fragt den eingetragenen DNS-Server nach der zugehörigen IP-Adresse (1 Punkt) und baut erst mit dieser Adresse die Verbindung zum Webserver auf (1 Punkt).

• Der Info-Server liegt nicht im eigenen Netz 10.110.0.0/24, sondern in 10.140.0.0/28; das erkennt das Terminal mit seiner Subnetzmaske. (1 Punkt)

• Pakete in fremde Netze gehen an das Standardgateway. Das Terminal hat daher per ARP nur die MAC-Adresse der Firewall 10.110.0.1 ermittelt (00-1a-8c-0a-6e-01) und den Frame an sie geschickt. (1 Punkt)

• ARP funktioniert nur im eigenen Netzabschnitt; die MAC-Adresse des Info-Servers kennt nur die Firewall in ihrem VLAN 140. (1 Punkt)

Von oben nach unten: DNS, DHCP, ARP, NTP, APIPA (je 1 Punkt).

• NTP (Network Time Protocol), bei einfachen Geräten auch SNTP (1 Punkt).

• Begründung (2 Punkte, z. B.): Nur mit gleicher Zeit lassen sich Check-in-Zeiten, Aufnahmen und Protokolle verschiedener Geräte einander zuordnen, etwa um bei einer Störung nachzuvollziehen, was wann passiert ist. Außerdem setzen verschlüsselte Verbindungen (HTTPS) eine richtige Uhrzeit voraus, sonst gelten Zertifikate als ungültig.

• Rolle von 10.110.0.1 (2 Punkte): Das ist die Firewall-Schnittstelle im VLAN 110, auf der das Relay läuft. Sie ist Absender der Anfragen an dhcp-bc und trägt sich zusätzlich in das Feld Gateway-IP (giaddr) ein. Der Server sucht den Bereich, zu dem diese Adresse gehört (10.110.0.0/24), und bietet daraus 10.110.0.120 an. Die Antworten schickt er an das Relay zurück, nicht an den Client.

• Warum aus VLAN 120 und 130 nichts ankommt (2 Punkte): Die Clients senden ihr DHCPDISCOVER als Broadcast. Broadcasts enden an der Firewall-Schnittstelle ihres VLANs; ohne Relay auf dieser Schnittstelle leitet niemand sie an 10.140.0.4 weiter. Die Clients erhalten keine Antwort und geben sich APIPA-Adressen.

• Noch einzurichten (2 Punkte): auf den Firewall-Schnittstellen der VLANs 120 und 130 je ein DHCP-Relay mit Ziel 10.140.0.4; die Firewall-Regeln müssen DHCP (UDP 67) von diesen Schnittstellen zu dhcp-bc und zurück erlauben, und auf dhcp-bc müssen die Bereiche für 10.120.0.0/24 und 10.130.0.0/24 aktiv sein.

Je Zeile 1 Punkt. Zwischen Relay und Server läuft alles als Unicast; nur im Netz des Clients wird gebroadcastet, weil der Client noch keine Adresse hat. Ob die Antworten an den Client als Unicast oder Broadcast gehen, hängt davon ab, ob der Client das Broadcast-Bit gesetzt hat.

Der Client besitzt beim Start noch keine IP-Adresse (er sendet von 0.0.0.0) und kennt weder Maske noch Gateway (1 Punkt). Ein Paket an 10.140.0.4 in einem fremden Netz müsste er an das Gateway schicken, das er erst durch DHCP erfährt; außerdem könnte ihn eine Antwort ohne eigene Adresse nicht erreichen. Er kann daher nur alle Geräte im eigenen Netz per Broadcast (255.255.255.255, Ziel-MAC ff:ff:ff:ff:ff:ff) ansprechen (1 Punkt).

• Statisch: Adresse, Maske, Gateway und DNS-Server werden an jedem Schild einzeln eingetragen; das Schild braucht keinen DHCP-Server. (1 Punkt)

• Reservierung: Im DHCP-Server wird zur MAC-Adresse jedes Schilds eine feste IP-Adresse hinterlegt; das Schild bezieht weiter per DHCP und erhält immer dieselbe Adresse. (1 Punkt)

• Begründung (2 Punkte): Bei zwölf Geräten sind Reservierungen günstiger: alle Zuordnungen stehen zentral an einer Stelle, Änderungen (z. B. neuer DNS-Server, Austausch eines Schilds gegen das Ersatzschild) erfolgen einmal im Server statt an jedem Akku-Gerät, Tippfehler und Doppelvergaben werden vermieden. Ein Argument für statische Adressen wäre, dass die Schilder auch ohne DHCP-Server arbeiten; bei einer Veranstaltung mit überwachtem Server wiegt das weniger.

• Das Schild prüft, ob die zugeteilte Adresse wirklich frei ist: Antwortet ein anderes Gerät, ist sie schon belegt (z. B. durch eine statisch eingetragene Adresse), und das Schild lehnt sie per DHCPDECLINE ab. (2 Punkte)

• Ist sie frei, teilt es mit der Ankündigung allen Geräten im Netz seine Zuordnung von IP- und MAC-Adresse mit, sodass diese ihren ARP-Cache aktualisieren, etwa wenn die Adresse vorher einem anderen Gerät gehörte. (1 Punkt)

• Bedeutung (1 Punkt): Die Firewall lernt für 10.120.0.57 abwechselnd zwei verschiedene MAC-Adressen und überschreibt jedes Mal ihren ARP-Eintrag. Zwei Geräte nutzen also dieselbe IP-Adresse.

• Beteiligte (1 Punkt): b8:27:eb:3a:10:07 ist INFO-07 (statisch, Herstellerteil eines Raspberry Pi), 24:6f:28:40:0a:12 laut Lease-Liste das Türschild ts-b201, das .57 vom DHCP-Server erhalten hat, weil die statische Adresse des Monitors mitten im Bereich .20 bis .200 liegt. Vermutlich hat das Schild die Adresse bekommen, als der Monitor ausgeschaltet war; seine Prüfung per ARP blieb deshalb unbeantwortet.

• Folge (1 Punkt): Pakete an .57 gehen an das Gerät, dessen MAC-Adresse gerade im ARP-Cache der Firewall steht. Steht dort das Türschild, erreicht der Ping den Monitor nicht. Weil Linux eine statische Adresse ohne Konfliktprüfung weiter nutzt, wechselt der Zustand ständig.

• Entscheidung (1 Punkt): INFO-07 behält .57. Die Adresse ist am Monitor fest eingetragen und vermutlich in Dokumentation, Firewall-Regeln oder der Software für die Inhalte hinterlegt; das Türschild holt seine Adresse ohnehin per DHCP und kann jede andere bekommen.

• Dauerhafte Lösung (2 Punkte, sinngemäß):

  • Im DHCP-Server .57 aus dem Bereich ausschließen, besser den Bereich so verkleinern, dass alle statischen Adressen außerhalb liegen (z. B. statische Geräte von .2 bis .99, Bereich .100 bis .200), und die statischen Adressen in der Netzdokumentation pflegen.
  • Die Lease von ts-b201 löschen und das Schild neu verbinden lassen, damit es eine freie Adresse erhält.
  • Den ARP-Eintrag der Firewall für .57 löschen (oder ablaufen lassen) und die Erreichbarkeit von INFO-07 und ts-b201 per Ping prüfen.

Je 1 Punkt, drei aus:

• Bereich erschöpft, alle Adressen sind verliehen.

• DHCP-Dienst gestoppt oder Server (unter Windows im Active Directory) nicht autorisiert.

• Firewall blockiert UDP 67/68 zwischen Relay und Server.

• Bereich mit falschem Gateway oder falscher Maske angelegt.

• Ein zweiter, nicht berechtigter DHCP-Server (z. B. mitgebrachter Router) antwortet schneller und verteilt fremde Adressen.

Je Beispiel 1 Punkt, zwei aus:

• Interne Server werden über Namen angesprochen, z. B. das NAS als nas.dev.letsmeet.example; Lesezeichen, Skripte und Netzlaufwerke müssen bei einem Adresswechsel nicht angepasst werden.

• Die Windows-Clients finden den Domänencontroller für Anmeldung und Gruppenrichtlinien über DNS-Einträge der Zone letsmeet.example (SRV-Einträge); ohne DNS scheitert die Anmeldung an der Domäne.

• Rückwärtsauflösung: Protokolle von Firewall und Servern zeigen Gerätenamen statt nur IP-Adressen.

• Interne Dienste wie der Testserver test.letsmeet.example sind intern unter einer anderen Adresse erreichbar als von außen.

• Aufbau (1 Punkt): hierarchisch, von rechts nach links gelesen, Teile durch Punkte getrennt; ganz rechts steht die (meist weggelassene) Root.

• Je 1 Punkt: example Top-Level-Domain, letsmeet Domain (Second-Level-Domain), dev Subdomain, nas Hostname.

• Ursache (2 Punkte): Der öffentliche DNS-Server kennt die interne Zone letsmeet.example mit dem Eintrag für nas.dev.letsmeet.example nicht. Internetnamen löst er auf, interne Namen nicht; deshalb ist das NAS nur noch per IP-Adresse erreichbar.

• Lösung (1 Punkt): DNS-Server automatisch beziehen lassen bzw. 172.18.4.10 eintragen, danach ipconfig /flushdns und erneut testen.

• Weiterer Grund (1 Punkt, z. B.): Die Anmeldung an der Domäne scheitert, weil Clients den Domänencontroller per DNS finden; Filter und Protokollierung des internen DNS werden umgangen.

• Reihenfolge (3 Punkte; je ein Punkt für C–F–B, H–D und A–G–E): C, F, B, H, D, A, G, E.

• Rekursive Anfrage (1 Punkt): C und E. Das Notebook stellt eine einzige Frage und erwartet eine fertige Antwort; alle Zwischenschritte übernimmt dc01.

• Verweise (1 Punkt): B und D. Root- und TLD-Server kennen die Antwort nicht, sondern nennen nur den nächsten zuständigen Server; dc01 folgt diesen Verweisen iterativ. G ist die eigentliche Antwort, die dc01 für die Dauer der TTL in seinen Cache übernimmt.

Bewertung (4 Punkte, je sinnvoller vergleichender Aussage 1 Punkt), z. B.:

Empfehlung (2 Punkte, begründet; andere begründete Empfehlungen sind ebenfalls richtig): Variante 3 mit einem Anbieter in der EU und einem zweiten Forwarder als Ersatz. Das kleine Büro gewinnt Schutz vor Schadsoftware-Domains, braucht nur eine Firewall-Regel und muss keinen eigenen Aufwand betreiben; die Abhängigkeit wird durch den zweiten Eintrag gemildert.

• Zweck (2 Punkte): Der Cache speichert Antworten für die Dauer ihrer TTL. Bei erneuter Anfrage kommt die Antwort lokal aus dem Cache, ohne erneute Anfrage an den Nameserver; das ist schneller und entlastet die Server.

• Alte Adresse (1 Punkt): Anhs Rechner (oder ein Resolver) hat den alten Eintrag noch im Cache, dessen TTL nicht abgelaufen ist.

• Befehl (1 Punkt): ipconfig /flushdns.

Der DNS-Server dc01 ist erreichbar und hat geantwortet (1 Punkt), kennt den Namen tset.letsmeet.example aber nicht, weil er falsch geschrieben ist (Tippfehler statt test); ohne Auflösung kann keine Verbindung aufgebaut werden (1 Punkt).

• Büro (1 Punkt): Clients fragen dc01, der die interne Fassung der Zone führt, und erhalten 172.18.6.3; sie erreichen den Server direkt im LAN.

• Internet (1 Punkt): Externe Resolver landen über die öffentliche Delegation beim Provider und erhalten 192.0.2.10; die Portweiterleitung bringt die Verbindung zum Server. Dieselbe Zone liefert also je nach Herkunft der Anfrage unterschiedliche Antworten (Split-horizon DNS).

• Vorteil (1 Punkt, einer aus): ein Name und dieselben Links für alle; interner Verkehr bleibt im LAN; interne Namen wie nas.dev und private Adressen erscheinen nicht in der öffentlichen Zone.

• Ursache (2 Punkte): nslookup fragt den eingetragenen DNS-Server dc01 und bekommt die interne Antwort. Der Browser umgeht mit DNS über HTTPS den Resolver des Betriebssystems, fragt den öffentlichen Anbieter und erhält die öffentliche Antwort 192.0.2.10. Die Verbindung geht dann aus dem Büro an die öffentliche Adresse des eigenen Routers; ohne NAT-Loopback leitet er sie nicht weiter, es kommt keine Antwort.

• Behebung (je 1 Punkt, zwei aus): DNS über HTTPS im Browser abschalten bzw. für Firmengeräte per Richtlinie deaktivieren oder auf den internen Server umstellen; dem Browser dc01 als DoH-Server anbieten; NAT-Loopback am Router einrichten (funktioniert, ist aber ein Umweg über den Router); test.letsmeet.example vorübergehend in die hosts-Datei eintragen (nur als Notlösung).

Je Anforderung 1 Punkt (Funktion mit kurzer Begründung):

1. WLAN-Accesspoint mit Gastzugang: Die Gäste erhalten ein eigenes, vom Firmennetz getrenntes Netz mit reinem Internetzugang.

2. VPN-Gateway: Ein verschlüsselter Tunnel zur Zentrale verbindet beide Standorte; die Buchungen laufen geschützt durch das Internet.

3. DHCP-Server: Er teilt dem Tablet Adresse, Maske, Gateway und DNS-Server automatisch zu.

4. DNS-Server (DNS-Proxy mit Cache): Er beantwortet Anfragen aus dem Cache und leitet Namen der Zentrale über das VPN an den internen DNS-Server, andere an den Provider weiter.

5. NTP-Server: Der Router holt die genaue Zeit aus dem Internet; die Kasse gleicht ihre Uhr regelmäßig mit ihm ab.

Übrig bleibt der DynDNS-Client (siehe Teilaufgabe b).

Weil sich die öffentliche Adresse ändert, kann die Zentrale den Showroom nicht dauerhaft unter einer festen Adresse ansprechen (1 Punkt). Der DynDNS-Client meldet nach jeder Änderung die neue Adresse an einen DynDNS-Dienst, der den DNS-Eintrag (z. B. showroom.dyndns-anbieter.example) mit kurzer TTL aktualisiert (1 Punkt). Das VPN-Gateway der Zentrale baut die Verbindung zu diesem Namen auf und erreicht so immer die aktuelle Adresse (1 Punkt).

• NTP (Network Time Protocol) bzw. SNTP (1 Punkt), UDP Port 123 (1 Punkt).

• Hierarchie in Strata (1 Punkt): Stratum 0 sind Referenzuhren (Atomuhr, GPS, DCF77), Stratum-1-Server sind direkt daran angeschlossen, Stratum-2-Server holen die Zeit von Stratum 1 usw.; der Router holt sie z. B. aus dem NTP-Pool und gibt sie weiter.

Je 2 Punkte, zwei aus:

• Nur mit synchroner Zeit lassen sich Kamerabilder eindeutig den Kassenvorgängen oder Ereignissen (z. B. einem Diebstahl) zuordnen.

• Log-Einträge von Router, VPN und Kasse lassen sich bei einer Störung oder einem Sicherheitsvorfall nur mit gleicher Zeit nachvollziehen.

• Zertifikate (VPN, HTTPS zum Kassen-Backend) werden anhand der Uhrzeit geprüft; bei falscher Zeit gelten sie als ungültig, Verbindungen scheitern.

• Kassenbelege und Buchungen müssen mit korrektem Datum und Uhrzeit erfasst werden.

Je Anforderung 1 Punkt (Typ und sinnvoller Eintrag):

1. A: shop.csb-rad.example. A 203.0.113.140

2. AAAA: shop.csb-rad.example. AAAA 2001:db8:40::140

3. CNAME: www.csb-rad.example. CNAME shop.csb-rad.example. (der Alias folgt jeder Änderung von shop)

4. MX: csb-rad.example. MX 10 mail.csb-rad.example. (dazu braucht mail.csb-rad.example einen A- bzw. AAAA-Eintrag)

5. PTR: 140.113.0.203.in-addr.arpa. PTR shop.csb-rad.example. Diese Rückwärtszone verwaltet der Inhaber des Adressblocks, hier der Cloud-Anbieter; der Eintrag wird dort beantragt.

6. TXT: csb-rad.example. TXT "pruefcode=7f3a91c2"

1. Der Mailserver fragt per DNS den MX-Eintrag der Domain radhaus-bielefeld-sued.example ab und erhält den Namen des zuständigen Mailservers (bei mehreren den mit der kleinsten Prioritätszahl). (1 Punkt)

2. Er löst diesen Namen per A- bzw. AAAA-Eintrag in eine IP-Adresse auf. (1 Punkt)

3. Er liefert die Mail per SMTP an diese Adresse aus; der Empfänger kann über den SPF-Eintrag (TXT) von csb-rad.example prüfen, ob der Absender-Server berechtigt ist. (1 Punkt)

SPF prüft, ob der Server, der eine Mail einliefert, für die Absenderdomain senden darf; die erlaubten Server stehen im TXT-Eintrag der Absenderdomain, hier nur die Mailserver aus dem MX-Eintrag von csb-rad.example (1 Punkt). Bei der Weiterleitung liefert aber der Server des Händlers die Mail an post.zweirad-gruppe.example ein, und zwar weiterhin mit dem Absender @csb-rad.example. Seine Adresse steht nicht im SPF-Eintrag; wegen -all lehnt der Empfänger die Mail ab (1 Punkt).

• Bewertung (2 Punkte): Mit ~all (softfail) werden Mails nicht berechtigter Server nicht mehr abgewiesen, sondern nur als verdächtig markiert. Die Rechnungen kämen dann eher an, landen aber womöglich im Spam. Gleichzeitig schwächt die Änderung den Schutz gegen gefälschte Absender @csb-rad.example bei allen Empfängern. Als Lösung für eine einzelne Weiterleitung ist das daher ungeeignet.

• Besseres Verfahren (1 Punkt, eines aus): DKIM: Der Mailserver der CSB-Rad GmbH signiert jede Mail, der öffentliche Schlüssel steht als TXT-Eintrag im DNS; die Signatur bleibt bei einer unveränderten Weiterleitung gültig (zusammen mit einer DMARC-Richtlinie, die DKIM als Nachweis genügen lässt). Alternativ schreibt der weiterleitende Server den Absender um (SRS, Sender Rewriting Scheme); das muss allerdings der Händler einrichten.

• Unterschied (1 Punkt): nslookup fragt direkt den DNS-Server (172.20.127.254) und bekommt die richtige Adresse. ping und der Browser nutzen den Namensdienst von Windows, der vor jeder DNS-Anfrage die lokale hosts-Datei (C:\Windows\System32\drivers\etc\hosts) liest.

• Ursache (1 Punkt): In der hosts-Datei dieses Tablets steht ein Eintrag 198.51.100.66 shop.csb-rad.example, vermutlich von Schadsoftware eingetragen. Weil nur dieses Gerät betroffen ist und der DNS-Server richtig antwortet, liegt der Fehler nicht im DNS.

• Maßnahmen (2 Punkte, zwei aus): Tablet vom Netz nehmen und auf Schadsoftware prüfen bzw. neu aufsetzen; Eintrag entfernen und ipconfig /flushdns ausführen; prüfen, ob am Tablet Zahlungs- oder Zugangsdaten eingegeben wurden, und diese sperren bzw. ändern; Benutzerkonten ohne Administratorrechte verwenden, damit die hosts-Datei nicht verändert werden kann; die gefälschte Seite dem Provider bzw. dem Shop-Betreiber melden.

1. Der Resolver prüft die RRSIG-Signatur über den A-Eintrag mit dem öffentlichen Schlüssel mit der Kennung 41022 (DNSKEY 256). Passt sie nicht, wurde der Eintrag verändert, und der Resolver verwirft die Antwort. Dabei achtet er auch auf den Gültigkeitszeitraum der Signatur (hier 01.03. bis 01.04.2027). (1 Punkt)

2. Er prüft, ob die DNSKEY-Einträge selbst echt sind: Der Schlüssel 30907 (DNSKEY 257) signiert die Schlüsselliste der Zone, und sein Hashwert muss mit dem DS-Eintrag übereinstimmen, den die übergeordnete Zone example. veröffentlicht. (1 Punkt)

3. Den DS-Eintrag prüft er auf dieselbe Weise mit den Schlüsseln von example., deren DS wiederum in der Root-Zone steht. Den Schlüssel der Root kennt der Resolver fest (Trust Anchor). Ist die ganze Kette lückenlos, stammt die Antwort nachweislich aus der Zone csb-rad.example. (1 Punkt)

Nein (1 Punkt). Die falsche Adresse stammt aus der hosts-Datei des Tablets und nicht aus einer DNS-Antwort. Windows befragt den DNS-Server für diesen Namen gar nicht, eine Signaturprüfung findet deshalb nicht statt. Außerdem validiert in der Regel der Resolver (hier der Router oder der Provider), nicht das Tablet selbst; gegen Manipulationen auf dem Endgerät hilft DNSSEC nicht (1 Punkt).