Das Domain Name System, kurz DNS, sorgt dafür, dass Sie Internetdienste über Namen wie example.com erreichen können, anstatt sich numerische IP-Adressen merken zu müssen. Hinter dieser scheinbar einfachen Übersetzung arbeitet ein weltweit verteiltes System aus Resolvern, Nameservern, Zonen, Zwischenspeichern und Delegationen. DNS liefert dabei nicht nur IP-Adressen: Je nach Abfrage stellt es auch Informationen zu Mailservern, Aliasnamen, Diensten oder anderen Eigenschaften einer Domain bereit. Für die Praxis ist diese Unterscheidung wichtig, weil nicht jedes DNS-Problem automatisch ein Ausfall des Internetanschlusses ist. Wenn Webseiten nicht erreichbar sind, können ebenso ein fehlerhafter Eintrag, ein veralteter Cache, eine gestörte Resolver-Verbindung oder eine falsche Netzwerkkonfiguration dahinterstecken. Wer die Rollen der beteiligten DNS-Komponenten kennt, kann solche Fehler wesentlich gezielter eingrenzen und Sicherheitsfunktionen wie DNSSEC, DNS over HTTPS oder DNS over TLS korrekt einordnen.
DNS-Auflösung verstehen: Hierarchie, Resolver und Cache
Was ist DNS?
DNS ist ein hierarchisch aufgebauter, verteilter Namensdienst. Er ordnet Domainnamen bestimmten Informationen zu, die in sogenannten Resource Records gespeichert werden. Besonders bekannt sind A-Records für IPv4-Adressen und AAAA-Records für IPv6-Adressen. Daneben existieren unter anderem MX-Einträge für Mailserver, CNAME-Einträge für Aliasnamen, NS-Einträge für zuständige Nameserver und TXT-Einträge für frei definierbare Textinformationen, die beispielsweise bei E-Mail-Sicherheitsverfahren eine Rolle spielen.
Eine Domain ist dabei nicht einfach ein einzelner Datenbankeintrag. Das DNS bildet einen Baum, dessen Wurzel ganz oben steht. Darunter folgen Top-Level-Domains wie .de, .com oder .org und anschließend weitere Ebenen. Zuständigkeiten können an untergeordnete Bereiche delegiert werden. Dadurch muss kein zentraler Server sämtliche Domains des Internets kennen. Stattdessen weiß jede beteiligte Ebene, welche Stelle für den nächsten Teil der Namensauflösung zuständig ist.
Wie eine DNS-Anfrage tatsächlich aufgelöst wird
Wenn Sie eine Webadresse eingeben, fragt Ihr Browser in der Regel nicht selbst nacheinander Root-, TLD- und autoritative Server ab. Das Betriebssystem beziehungsweise ein lokaler Resolver übergibt die Anfrage normalerweise an einen rekursiven DNS-Resolver. Diesen stellt häufig Ihr Internetanbieter, Ihr Router, ein Unternehmensnetzwerk oder ein ausdrücklich konfigurierter öffentlicher DNS-Dienst bereit. Der rekursive Resolver übernimmt die eigentliche Suche und liefert Ihrem Gerät möglichst direkt das Ergebnis.
- Sie rufen beispielsweise example.com auf.
- Ihr Gerät prüft zunächst vorhandene lokale Informationen und übergibt die Anfrage anschließend an den eingestellten rekursiven Resolver.
- Der Resolver prüft seinen Cache. Liegt dort noch eine gültige Antwort, kann er sie unmittelbar zurückgeben.
- Fehlen die erforderlichen Informationen, kann der Resolver einen Root-Nameserver nach der zuständigen Ebene für .com fragen.
- Der Root-Nameserver liefert eine Delegation zu den zuständigen Nameservern der Top-Level-Domain.
- Der Resolver fragt dort nach der Zuständigkeit für example.com und erhält einen Verweis auf die autoritativen Nameserver der Domain.
- Der autoritative Nameserver liefert schließlich den angefragten Resource Record oder eine andere autoritative Antwort. Der Resolver gibt das Ergebnis an Ihr Gerät zurück und kann es zeitlich begrenzt zwischenspeichern.
Wie lange ein DNS-Ergebnis zwischengespeichert werden darf, wird wesentlich durch die Time to Live (TTL) bestimmt. Solange ein Cache-Eintrag gültig ist, muss der Resolver nicht bei jeder Anfrage erneut die gesamte Hierarchie durchlaufen. Das senkt die Last und verkürzt Antwortzeiten. Die Kehrseite: Nach einer Änderung an DNS-Einträgen können einzelne Resolver noch eine Zeit lang ältere Werte aus ihrem Cache liefern. Auch negative Antworten wie „Name existiert nicht“ können zeitlich begrenzt zwischengespeichert werden.
DNS-Hierarchie und Serverrollen richtig unterscheiden
Die Bezeichnung „DNS-Server“ fasst mehrere Aufgaben zusammen, die technisch deutlich voneinander zu trennen sind. Für die Fehlersuche sollten Sie vor allem unterscheiden, ob ein Server autoritative Daten bereitstellt oder als Resolver im Auftrag eines Clients arbeitet. Ein rekursiver Resolver kann außerdem gleichzeitig einen Cache führen; „Caching-Nameserver“ und „rekursiver Resolver“ sind deshalb keine zwingend getrennten Gerätekategorien.
- Root-Nameserver: Sie liefern Informationen darüber, welche Nameserver für die nächste Ebene des DNS-Baums zuständig sind. Es gibt 13 benannte Root-Server-Autoritäten von A bis M, hinter denen weltweit zahlreiche Serverinstanzen arbeiten.
- TLD-Nameserver: Sie verwalten die Delegationen innerhalb einer Top-Level-Domain wie .de oder .com und verweisen auf die für eine untergeordnete Domain zuständigen autoritativen Nameserver.
- Autoritative Nameserver: Sie liefern die verbindlichen DNS-Daten der Zonen, für die sie zuständig sind. Das können IP-Adressen sein, aber ebenso Mail-, Alias-, Nameserver- oder andere Einträge.
- Rekursive DNS-Resolver: Sie nehmen Anfragen von Clients entgegen, ermitteln die erforderliche Antwort und speichern geeignete Ergebnisse typischerweise im Cache.
DNSSEC, DoH und DoT erfüllen unterschiedliche Aufgaben
DNS wurde ursprünglich nicht mit einer kryptografischen Prüfung der gelieferten Daten entwickelt. DNSSEC ergänzt deshalb digitale Signaturen, mit denen ein validierender Resolver die Herkunft und Integrität signierter DNS-Daten prüfen kann. Vereinfacht gesagt lässt sich damit erkennen, ob eine signierte Antwort auf dem Weg manipuliert wurde. Voraussetzung ist eine funktionierende Vertrauenskette bis zu einem bekannten Vertrauensanker. DNSSEC verschlüsselt die Abfrage jedoch nicht und verbirgt auch nicht, welchen Namen Sie auflösen möchten.
Für die verschlüsselte Übertragung zwischen Client und Resolver existieren unter anderem DNS over HTTPS (DoH) und DNS over TLS (DoT). Beide schützen den Transport auf diesem Abschnitt vor einfachem Mitlesen oder Manipulieren. Der verwendete Resolver selbst verarbeitet die Abfrage weiterhin. Prüfen Sie deshalb nicht nur, ob „sicheres DNS“ aktiviert ist, sondern auch, welcher Resolver tatsächlich genutzt wird. Browser können je nach Konfiguration einen eigenen verschlüsselten DNS-Dienst verwenden und damit von den DNS-Einstellungen des Betriebssystems oder Routers abweichen.
Typische DNS-Fehlerbilder richtig einordnen
Eine Meldung wie DNS_PROBE_FINISHED_NXDOMAIN deutet darauf hin, dass der gewünschte Name nicht erfolgreich aufgelöst wurde und eine Nicht-Existenz-Antwort im Spiel sein kann. Prüfen Sie zuerst die Schreibweise der Domain und testen Sie, ob das Problem nur diese Adresse oder viele verschiedene Domains betrifft. Ist nur ein Name betroffen, kann der Fehler auf Seiten der Domain liegen. Sind zahlreiche Namen betroffen, sollten Sie die lokale DNS- und Netzwerkkonfiguration untersuchen.
Eine Meldung wie DNS_PROBE_FINISHED_NO_INTERNET ist dagegen kein Beweis für einen defekten DNS-Server. Prüfen Sie zunächst, ob Ihr Gerät überhaupt eine funktionierende Netzwerkverbindung, eine gültige IP-Konfiguration und ein erreichbares Standardgateway besitzt. Starten Sie Router oder Modem bei Bedarf neu, führen Sie aber keinen Werksreset durch. Eine Firewall sollten Sie ebenfalls nicht pauschal deaktivieren; kontrollieren Sie stattdessen gezielt, ob Sicherheitssoftware, VPN-Programme oder Filter DNS-Verbindungen blockieren.
DNS-Serverrollen im Detail: Root, TLD, autoritativ und rekursiv
Warum der Begriff „DNS-Server“ sehr pauschal ist
Für Anwender wirkt DNS häufig wie ein einzelner Dienst: Sie tragen eine Serveradresse ein und erhalten Antworten auf Domainanfragen. Technisch können hinter dieser Bezeichnung jedoch sehr unterschiedliche Rollen stehen. Ein öffentlicher Resolver wie Google Public DNS oder Cloudflare 1.1.1.1 löst Namen rekursiv für Endgeräte auf. Der Nameserver einer eigenen Domain hat dagegen normalerweise eine autoritative Aufgabe. Diese Trennung entscheidet darüber, welche Konfiguration und welche Sicherheitsmaßnahmen sinnvoll sind.
Fragen Sie bei einer Störung deshalb zuerst: Welcher Server sollte hier welche Aufgabe erfüllen? Antwortet ein autoritativer Server falsch, liegt das Problem möglicherweise in der Zonenkonfiguration. Scheitert dagegen ein rekursiver Resolver, können dessen Cache, Weiterleitungen, Netzwerkzugang oder DNSSEC-Validierung betroffen sein. Die gleiche Fehlermeldung im Browser kann also sehr unterschiedliche Ursachen haben.
Root-Nameserver: Einstieg in die DNS-Hierarchie
Root-Nameserver bilden die oberste Delegationsebene des öffentlichen DNS. Sie speichern nicht die IP-Adresse jeder Website, sondern kennen die für Top-Level-Domains zuständigen Nameserver. Benötigt ein rekursiver Resolver beispielsweise Informationen zur Domain example.com und besitzt noch keine geeigneten Delegationsdaten im Cache, kann er über die Root-Zone erfahren, welche Server für .com zuständig sind.
Die häufig genannte Zahl von 13 Root-Servern bedeutet deshalb nicht, dass weltweit lediglich 13 physische Maschinen das DNS tragen. Es handelt sich um 13 benannte Autoritäten. Hinter diesen Namen arbeitet ein geografisch verteiltes Netz aus zahlreichen Instanzen. Für Betreiber eigener rekursiver Resolver sind sogenannte Root Hints wichtig: Sie ermöglichen dem Resolver, die Root-Server zu erreichen und die iterative Auflösung zu beginnen.
TLD-Nameserver: Delegation statt vollständiger Domain-Datenbank
TLD-Nameserver sind für Zonen wie .de, .com oder .org zuständig. Ihre zentrale Aufgabe besteht darin, Resolver zur nächsten autoritativen Ebene weiterzuführen. Fragen Sie nach einer Domain unterhalb von .de, liefern die TLD-Server typischerweise die Nameserver, an die diese Domain delegiert wurde. Die eigentliche IP-Adresse des gewünschten Webservers muss dort nicht hinterlegt sein.
Zusätzlich können sogenannte Glue Records notwendig sein. Sie liefern Adressinformationen zu Nameservern, wenn sich deren Namen innerhalb einer abhängigen Namensstruktur befinden und die Delegation andernfalls in einen Auflösungszirkel geraten könnte. Für normale Anwender bleibt dieser Mechanismus meist unsichtbar; bei fehlerhaften Delegationen gehört er jedoch zu den Punkten, die Domain- oder DNS-Administratoren prüfen sollten.
Autoritative Nameserver: verbindliche Daten einer DNS-Zone
Ein autoritativer Nameserver beantwortet Anfragen aus den Daten einer Zone, für die er zuständig ist. Dort liegen beispielsweise A- und AAAA-Einträge für Serveradressen, MX-Einträge für Mailserver, CNAME-Einträge für Aliase sowie TXT-Einträge. Entscheidend ist der Begriff autoritative Antwort: Der Server liefert die für seine Zone maßgeblichen Informationen und nicht lediglich einen zuvor zwischengespeicherten Datensatz eines fremden Servers.
Ändern Sie die IP-Adresse eines Dienstes, wird der neue Wert auf den autoritativen Servern veröffentlicht. Andere Resolver können jedoch bis zum Ablauf ihrer Cache-Frist noch den vorherigen Eintrag verwenden. Planen Sie DNS-Änderungen deshalb nicht erst unmittelbar vor einer Migration. Eine rechtzeitig reduzierte TTL kann die Übergangsphase verkürzen, erhöht während dieser Zeit aber auch die Zahl der Abfragen an die autoritative Infrastruktur.
Rekursive Resolver: DNS-Suche im Auftrag des Endgeräts
Rekursive Resolver sind für Endgeräte besonders relevant, weil sie die komplexe Auflösung übernehmen. Ihr PC, Smartphone oder Router muss dadurch nicht selbst die vollständige DNS-Hierarchie abarbeiten. Ein Resolver kombiniert aktuelle Abfragen mit vorhandenen Cache-Daten und versucht, eine vollständige Antwort auf die Anfrage des Clients zu liefern.
Sie können neben dem Resolver Ihres Internetanbieters auch öffentliche Dienste verwenden. Google Public DNS ist beispielsweise unter 8.8.8.8 und 8.8.4.4 erreichbar, Cloudflare bietet unter anderem 1.1.1.1 an. Ein Wechsel garantiert jedoch weder schnelleres Internet noch automatisch mehr Sicherheit. Antwortzeit, Datenschutzanforderungen, lokale Filter, Unternehmensrichtlinien und interne DNS-Namen können die sinnvollste Wahl beeinflussen. Nutzen Sie in einem Firmennetz interne Namen oder Active-Directory-Dienste, sollten Sie den vorgegebenen Resolver nicht unüberlegt durch einen öffentlichen Dienst ersetzen.
DNS-Caching: schneller, aber nicht immer sofort aktuell
Caching reduziert wiederholte Anfragen und beschleunigt die Namensauflösung. Ein rekursiver Resolver, der die Adresse eines häufig verwendeten Dienstes bereits kennt und dessen TTL noch nicht abgelaufen ist, kann die Anfrage unmittelbar beantworten. Auch Betriebssysteme und Anwendungen können eigene Caches führen. Dadurch existieren mehrere Ebenen, auf denen ein älterer DNS-Wert zeitweise erhalten bleiben kann.
Das Leeren des lokalen DNS-Caches ist deshalb ein gezieltes Diagnosemittel, aber kein allgemeiner Beschleunigungstrick. Unter Windows können Sie dafür in einer Eingabeaufforderung ipconfig /flushdns ausführen. Das ist vor allem sinnvoll, wenn ein veralteter oder negativer Eintrag vermutet wird. Liegt der falsche Datensatz dagegen weiterhin auf dem autoritativen Server oder in einem vorgeschalteten Resolver-Cache, behebt das Leeren Ihres lokalen Caches die Ursache nicht.
DNS verwalten und Änderungen kontrolliert durchführen
Betreiben Sie selbst DNS-Infrastruktur, sollten Sie Zonen, Delegationen, Zugriffsregeln und Aktualisierungen getrennt betrachten. Prüfen Sie nach Änderungen nicht nur, ob ein einzelner Client den gewünschten Namen auflösen kann. Kontrollieren Sie ebenso, ob die autoritativen Server konsistente Daten liefern, die Delegation stimmt und externe Resolver das erwartete Ergebnis erhalten. Bei DNSSEC kommen zusätzlich Signaturen, Schlüssel und die Vertrauenskette hinzu.
- Kontrollieren Sie A-, AAAA-, MX-, CNAME-, NS- und weitere relevante Einträge auf korrekte Ziele und sinnvolle TTL-Werte.
- Prüfen Sie Delegationen und Nameserver-Adressen nach Domain- oder Providerwechseln besonders sorgfältig.
- Halten Sie DNS-Server-Software und Betriebssystem aktuell und sichern Sie Konfigurationen beziehungsweise Zonendaten regelmäßig.
- Überwachen Sie Fehlerraten, Antwortzeiten, ungewöhnliche Anfragevolumina und Änderungen an sicherheitsrelevanten DNS-Einträgen.
- Nutzen Sie Diagnosewerkzeuge wie
nslookup,Resolve-DnsNameoder auf geeigneten Systemendig, um gezielt bestimmte Resolver, Record-Typen und autoritative Server zu testen.
DNS-Sicherheit und Fehlerdiagnose in der Praxis
Manipulation, Hijacking und DDoS-Angriffe unterscheiden
DNS-Manipulation kann unterschiedliche Formen annehmen. Beim Cache-Poisoning versucht ein Angreifer, gefälschte Informationen in einen Resolver-Cache einzuschleusen. DNS-Hijacking beschreibt allgemeiner Situationen, in denen Anfragen oder Einstellungen so verändert werden, dass Nutzer unerwartete DNS-Antworten erhalten. Das kann beispielsweise durch kompromittierte Geräte, manipulierte Routereinstellungen oder unbefugte Änderungen an einer Domainkonfiguration entstehen. DNSSEC kann manipulierte signierte DNS-Daten erkennbar machen, wenn die Validierung korrekt funktioniert, verhindert aber nicht jede Form eines kompromittierten Endgeräts oder Kontos.
Eine weitere Gefahr sind Denial-of-Service-Angriffe auf DNS-Infrastruktur. Fällt ein für eine Domain erforderlicher autoritativer Dienst aus und stehen keine ausreichend verteilten Alternativen bereit, kann die Domain trotz funktionierender Webserver praktisch unerreichbar werden. Offen erreichbare rekursive Resolver können zudem für Reflexions- oder Verstärkungsangriffe missbraucht werden. Betreiben Sie einen eigenen Resolver, sollten Sie rekursive Abfragen deshalb nur für die vorgesehenen Clients oder Netze erlauben.
Schutzmaßnahmen passend zur DNS-Rolle auswählen
Eine wirksame DNS-Absicherung besteht nicht aus einer einzelnen Funktion. DNSSEC, verschlüsselte Resolver-Verbindungen, Zugriffskontrollen, Updates und Überwachung lösen jeweils unterschiedliche Probleme. Besonders wichtig ist die Serverrolle: Einen rekursiven Resolver sollten Sie nicht ohne Grund für beliebige externe Clients öffnen. Ein öffentlich autoritativer Nameserver muss dagegen von außen erreichbar sein, sonst könnte er seine eigentliche Aufgabe nicht erfüllen.
- DNSSEC validieren: Nutzen Sie einen Resolver mit DNSSEC-Validierung, wenn Sie die Authentizität signierter DNS-Daten prüfen möchten.
- Transportverschlüsselung einordnen: Verwenden Sie DoH oder DoT, wenn DNS-Abfragen zwischen Client und Resolver verschlüsselt übertragen werden sollen. Verwechseln Sie diese Funktion nicht mit DNSSEC.
- Rekursion begrenzen: Erlauben Sie rekursive Abfragen auf eigenen Resolvern nur für berechtigte Clients und Netze.
- Systeme aktuell halten: Installieren Sie Sicherheitsupdates für DNS-Software, Betriebssystem und Router zeitnah und schützen Sie Administrationszugänge mit starken Zugangsdaten.
- Änderungen überwachen: Prüfen Sie Domain-, Registrar- und DNS-Konten regelmäßig. Unautorisierte Änderungen an Nameservern oder Einträgen können den gesamten Datenverkehr einer Domain betreffen.
- Protokolle auswerten: Ungewöhnliche Fehlerraten, extreme Abfragespitzen oder wiederholte Validierungsfehler können auf Fehlkonfigurationen oder Angriffe hinweisen.
DNS-Probleme systematisch eingrenzen
Bei einer Störung sparen Sie Zeit, wenn Sie nicht sofort DNS-Einstellungen ändern, sondern zunächst den Umfang des Problems bestimmen. Prüfen Sie, ob nur eine einzelne Domain, ein Browser, ein Gerät oder das gesamte Heimnetz betroffen ist. Testen Sie anschließend die grundlegende IP-Konfiguration. Unter Windows zeigt ipconfig /all unter anderem IP-Adresse, Standardgateway und konfigurierte DNS-Server. Fehlt bereits dort eine plausible Netzwerkkonfiguration, liegt die Ursache wahrscheinlich vor der eigentlichen DNS-Auflösung.
| Fehlerbild | Was es nahelegt | Prüfen Sie zuerst | Sinnvoller nächster Schritt |
|---|---|---|---|
| Nur eine Domain funktioniert nicht | Domain-, Record- oder Cacheproblem möglich | Schreibweise und Auflösung auf einem zweiten Gerät oder Resolver | Mit nslookup oder dig die konkrete Domain und bei Bedarf den Record-Typ prüfen |
| Viele Domains lassen sich nicht auflösen | Resolver oder lokale Netzwerkkonfiguration kann betroffen sein | IP-Adresse, Gateway und eingestellte DNS-Server | Konfigurierten Resolver testen und anschließend mit einem bekannten alternativen Resolver vergleichen |
| Nur ein Browser ist betroffen | Browsercache, Erweiterung, Proxy, VPN oder Secure-DNS-Konfiguration möglich | Anderen Browser und dessen DNS-/Proxy-Einstellungen | Browserbezogene Einstellungen gezielt prüfen, statt den Router zurückzusetzen |
| Kein Internetdienst funktioniert | Allgemeines Verbindungsproblem wahrscheinlicher als reiner DNS-Fehler | WLAN/LAN-Verbindung, Routerstatus und Gateway | Router beziehungsweise Modem neu starten und die Anschlussverbindung prüfen |
| Nach DNS-Änderung erscheint noch der alte Server | Gültiger Cache-Eintrag kann noch vorhanden sein | TTL und autoritative Antwort | Cacheablauf berücksichtigen; lokalen Cache nur bei begründetem Verdacht leeren |
Mit nslookup example.com können Sie unter Windows prüfen, welche Antwort der aktuell verwendete DNS-Server liefert. Möchten Sie zum Vergleich ausdrücklich einen anderen Resolver abfragen, lässt sich dessen Adresse zusätzlich angeben. Unterschiedliche Ergebnisse sind ein Hinweis, aber noch kein endgültiger Beweis für die Fehlerursache: Unternehmensnetze, VPN-Verbindungen oder Filter können absichtlich andere Antworten liefern oder direkte Anfragen an externe Resolver blockieren.
Vermuten Sie einen veralteten lokalen Cache, können Sie unter Windows ipconfig /flushdns einsetzen und die Abfrage wiederholen. Löschen Sie den Cache jedoch nicht reflexartig bei jedem Verbindungsproblem. Der Befehl ändert weder einen fehlerhaften DNS-Eintrag beim Domainbetreiber noch repariert er einen ausgefallenen Router oder eine gestörte Internetleitung.
Ein temporärer Vergleich mit einem öffentlichen Resolver kann bei der Diagnose helfen. Liefert der reguläre Resolver keine Antwort, während ein anderer Resolver denselben Namen korrekt auflöst, sollten Sie den ursprünglich verwendeten DNS-Dienst genauer untersuchen. Ändern Sie die DNS-Konfiguration in Firmennetzen oder bei speziellen Filter- und Jugendschutzlösungen aber nicht dauerhaft ohne Prüfung: Lokale Namen, interne Dienste oder bewusst eingesetzte Filter können davon abhängen.
Beziehen Sie auch VPN-, Proxy- und Sicherheitssoftware in die Fehlersuche ein. Solche Programme können einen eigenen Resolver verwenden oder DNS-Verkehr gezielt umleiten. Statt die Firewall vollständig auszuschalten, prüfen Sie deren Regeln und Protokolle. Ein vollständiges Deaktivieren beseitigt zwar unter Umständen kurzfristig einen Filtereffekt, schafft aber gleichzeitig ein vermeidbares Sicherheitsrisiko und sagt wenig darüber aus, welche einzelne Regel tatsächlich verantwortlich war.
Entscheidend ist die Reihenfolge: Klären Sie zuerst, ob die Netzwerkverbindung grundsätzlich funktioniert, grenzen Sie anschließend Gerät, Anwendung und betroffene Domains ein und testen Sie erst danach gezielt Resolver und DNS-Records. So vermeiden Sie unnötige Werksresets, wahllose Serverwechsel und pauschales Abschalten von Sicherheitsfunktionen. DNS wirkt im Alltag unsichtbar, lässt sich mit einer sauberen Trennung von Client, rekursivem Resolver, Cache und autoritativer Quelle jedoch sehr präzise diagnostizieren.
Werbung
(**) UVP: Unverbindliche Preisempfehlung
Preise inkl. MwSt., zzgl. Versandkosten