Gib eine Domain oder IP-Adresse ein, um DNS-Abfragen zu starten.
DNS Toolkit
DNS Toolkit
Alle DNS-Records abfragen, Mail-Security analysieren, Netzwerk-Sicherheit prüfen – direkt im Browser, kostenlos und ohne Registrierung.
Gib eine Domain oder IP-Adresse ein, um DNS-Abfragen zu starten.
Das DNS ist das Telefonbuch des Internets. Jedes Mal, wenn Sie eine Website aufrufen, eine E-Mail versenden oder einen Cloud-Dienst nutzen, sorgt das Domain Name System im Hintergrund dafür, dass Ihr Gerät die richtige Adresse findet. Es übersetzt für Menschen lesbare Domainnamen wie codemeta.de in maschinenlesbare IP-Adressen wie 185.199.108.153.
Ohne DNS müssten Sie sich die numerischen Adressen jedes Servers merken – bei Milliarden von Websites im Internet eine unmögliche Aufgabe. Das DNS arbeitet dabei hierarchisch: Anfragen werden von lokalen Resolvern über Root-Server, TLD-Server (z.B. für .de oder .com) bis zu den autoritativen Nameservern der jeweiligen Domain weitergeleitet.
Der grundlegendste Record-Typ. Er bildet einen Domainnamen auf eine IPv4-Adresse ab (z.B. 93.184.216.34). Jede Website, die über das Internet erreichbar sein soll, benötigt mindestens einen A-Record. Für Hochverfügbarkeit werden oft mehrere A-Records mit unterschiedlichen IPs konfiguriert (Round-Robin-DNS).
Das IPv6-Äquivalent zum A-Record. Mit dem Wachstum des Internets werden IPv4-Adressen knapp. AAAA-Records verweisen auf 128-Bit lange IPv6-Adressen (z.B. 2606:2800:220:1:248:1893:25c8:1946). Ein Server mit sowohl A- als auch AAAA-Record unterstützt den sogenannten Dual-Stack-Betrieb.
Mail Exchange Records bestimmen, welche Server für den E-Mail-Empfang einer Domain zuständig sind. Jeder MX-Eintrag hat eine Priorität (niedrigerer Wert = höhere Priorität). So können Backup-Mailserver definiert werden, die einspringen, wenn der primäre Server nicht erreichbar ist.
TXT-Records speichern beliebige Textinformationen zu einer Domain. Sie werden für Domain-Verifizierungen (Google, Microsoft 365), SPF-Records zur Mail-Authentifizierung, DKIM-Signaturen und DMARC-Policies verwendet. Pro Domain können beliebig viele TXT-Records existieren.
Ein Canonical Name Record erstellt einen Alias, der auf eine andere Domain verweist. Beispiel: www.codemeta.de kann als CNAME auf codemeta.de zeigen. Wichtig: Ein CNAME kann nicht am Zonen-Apex (der nackten Domain) existieren und lässt sich nicht mit anderen Record-Typen kombinieren.
Nameserver Records definieren die autoritativen DNS-Server für eine Domain. Diese Server sind die Quelle der Wahrheit für alle DNS-Einträge einer Zone. Typischerweise werden mindestens zwei NS-Server konfiguriert, um Redundanz sicherzustellen.
Der Start of Authority Record enthält administrative Informationen zur DNS-Zone: den primären Nameserver, die E-Mail-Adresse des Administrators, die Seriennummer der Zone sowie Timer für Refresh, Retry, Expire und die negative Cache-TTL. Pro Zone existiert genau ein SOA-Record.
Service Records ermöglichen das Auffinden von Netzwerkdiensten über DNS. Sie definieren Hostname, Port, Priorität und Gewichtung für Dienste wie SIP (VoIP), XMPP (Chat), LDAP (Verzeichnisdienst) oder Microsoft Active Directory. Das Format ist _service._proto.name.
Certification Authority Authorization Records legen fest, welche Zertifizierungsstellen (CAs) SSL/TLS-Zertifikate für eine Domain ausstellen dürfen. Dies ist ein wichtiger Sicherheitsmechanismus gegen die Ausstellung nicht autorisierter Zertifikate. Seit 2017 müssen CAs den CAA-Record vor der Zertifikatsausstellung prüfen.
Pointer Records ermöglichen die Reverse-DNS-Auflösung: Sie bilden eine IP-Adresse zurück auf einen Hostnamen. PTR-Records sind essenziell für die Reputation von Mailservern – viele empfangende Server prüfen, ob der PTR-Record der sendenden IP mit dem HELO/EHLO-Hostnamen übereinstimmt.
E-Mail-Sicherheit basiert auf einem Zusammenspiel mehrerer DNS-basierter Authentifizierungsprotokolle. Diese Technologien schützen Ihre Domain vor Missbrauch durch Phishing und Spoofing und verbessern gleichzeitig die Zustellbarkeit Ihrer E-Mails.
SPF definiert über einen TXT-Record, welche Server E-Mails im Namen Ihrer Domain versenden dürfen. Der empfangende Server prüft, ob die IP-Adresse des sendenden Servers in der SPF-Policy gelistet ist. Wichtig ist, dass der SPF-Record nicht mehr als 10 DNS-Lookups verursacht – sonst schlägt die Validierung fehl. Typische Mechanismen sind include: (andere Domains einbeziehen), ip4:/ip6: (direkte IPs) und der Qualifier am Ende: ~all (Softfail) oder -all (Hardfail).
DKIM nutzt kryptographische Signaturen, um die Authentizität und Integrität von E-Mails zu gewährleisten. Der sendende Server signiert ausgehende E-Mails mit einem privaten Schlüssel. Der zugehörige öffentliche Schlüssel wird als TXT-Record unter selector._domainkey.domain.de veröffentlicht. Der Empfänger kann damit die Signatur verifizieren und sicherstellen, dass die E-Mail nicht manipuliert wurde.
DMARC vereint SPF und DKIM zu einer übergeordneten Policy. Über den TXT-Record unter _dmarc.domain.de definiert der Domaininhaber, wie mit E-Mails umgegangen werden soll, die weder SPF- noch DKIM-authentifiziert sind. Die drei Policy-Stufen sind p=none (nur beobachten), p=quarantine (in Spam verschieben) und p=reject (ablehnen). Zusätzlich ermöglicht DMARC das Empfangen von aggregierten Berichten über den E-Mail-Versand.
BIMI ist der neueste Standard und ermöglicht es Unternehmen, ihr Logo direkt im E-Mail-Posteingang anzuzeigen. Voraussetzung ist eine funktionierende DMARC-Policy mit p=quarantine oder p=reject. Der BIMI-Record verweist auf ein SVG-Logo und optional auf ein VMC (Verified Mark Certificate), das die Echtheit des Logos bestätigt.
MTA-STS (Mail Transfer Agent Strict Transport Security) erzwingt die TLS-Verschlüsselung beim E-Mail-Transport zwischen Servern. Ohne MTA-STS können Angreifer durch einen Downgrade-Angriff die Verschlüsselung entfernen. TLS-RPT (TLS Reporting) ermöglicht es, Berichte über fehlgeschlagene TLS-Verbindungen zu empfangen, um Konfigurationsprobleme frühzeitig zu erkennen.
DNSSEC (DNS Security Extensions) schützt die Integrität von DNS-Antworten durch kryptographische Signaturen. Ohne DNSSEC sind DNS-Abfragen anfällig für Cache-Poisoning-Angriffe, bei denen ein Angreifer gefälschte DNS-Antworten einschleust, um Benutzer auf bösartige Server umzuleiten. DNSSEC stellt sicher, dass die empfangene DNS-Antwort tatsächlich vom autoritativen Nameserver stammt und nicht manipuliert wurde.
Blacklist-Checks (RBL – Realtime Blackhole Lists) sind für den Betrieb von Mailservern unerlässlich. Wenn die IP-Adresse Ihres Servers auf einer Blacklist steht, werden Ihre E-Mails von vielen Empfängern automatisch abgelehnt. Die gängigsten Listen wie Spamhaus ZEN, Barracuda und SpamCop sollten regelmäßig geprüft werden.
Nameserver-Konsistenz ist ein oft übersehener Aspekt der DNS-Verwaltung. Wenn die autoritativen Nameserver einer Domain unterschiedliche Antworten liefern, spricht man von „Lame Delegation" oder Synchronisationsfehlern. Dies kann zu unvorhersehbarem Verhalten führen – manche Benutzer sehen die Website, andere nicht.
Das CODEMETA DNS Toolkit ist ein professionelles, kostenloses Werkzeug für Systemadministratoren, IT-Dienstleister, Webentwickler und alle, die DNS-Konfigurationen prüfen oder Netzwerkprobleme diagnostizieren möchten. Sämtliche Abfragen werden über die DNS-over-HTTPS (DoH) Protokolle von Google Public DNS und Cloudflare DNS durchgeführt, was maximale Privatsphäre und Zuverlässigkeit gewährleistet.
Das Tool wurde von CODEMETA entwickelt – einem Softwareunternehmen, das sich auf Business-Management-Lösungen für IT-Dienstleister spezialisiert hat. Wir verstehen die täglichen Herausforderungen von IT-Profis und haben dieses Tool entwickelt, um schnelle, zuverlässige DNS-Diagnostik direkt im Browser zu ermöglichen.