DNS-Suche

Funktionsweise

1. Eine Domain eingeben: Tippen Sie einen beliebigen Domain-Namen (einschließlich Subdomains) in das Eingabefeld.
2. Eintragstypen auswählen: Wählen Sie, welche DNS-Eintragstypen abgefragt werden sollen: A, AAAA, MX, CNAME, TXT, NS, SOA oder alle.
3. Ergebnisse ansehen: Die Ergebnisse werden von einem öffentlichen DNS-over-HTTPS-Anbieter abgerufen und mit TTL-Werten und Eintragsdaten angezeigt.
4. Probleme diagnostizieren: Vergleichen Sie Ergebnisse von verschiedenen Eintragstypen, um Fehlkonfigurationen, Propagations-Verzögerungen oder fehlende Einträge zu identifizieren.

Warum DNS-Lookup verwenden?

DNS-Probleme gehören zu den häufigsten Ursachen für Website-Ausfälle, E-Mail-Zustellungsfehler und Domain-Migrationsprobleme. Die Möglichkeit, DNS-Einträge direkt aus dem Browser abzufragen, ohne Befehlszeilen-Tools wie dig oder nslookup: ist wertvoll für Entwickler, DevOps-Ingenieure und Sysadmins. Dieses Tool fragt Einträge über DNS-over-HTTPS für Datenschutz und Firewall-Umgehung ab. Verwenden Sie es, um MX-Einträge nach einem Wechsel des E-Mail-Anbieters zu verifizieren, A/CNAME-Einträge nach einer DNS-Migration zu bestätigen, TXT-Einträge für die SPF/DKIM-E-Mail-Authentifizierung zu prüfen und Propagations-Verzögerungen zu diagnostizieren.

DNS-Eintragstypen

• A: IPv4-Adresse für eine Domain
• AAAA: IPv6-Adresse für eine Domain
• MX: Mail-Server-Einträge für E-Mail-Routing
• CNAME: kanonischer Namens-Alias, der auf eine andere Domain zeigt
• TXT: Text-Einträge für SPF, DKIM, Domain-Verifizierung
• NS: autoritative Nameserver für die Domain

40 Jahre DNS: von RFC 882 bis DNS über QUIC

Das Domain Name System wurde von Paul Mockapetris an der USC/ISI entworfen und in RFC 882 und RFC 883 (November 1983) spezifiziert, womit die flache HOSTS.TXT-Datei abgelöst wurde, der das ARPANET entwachsen war. Das System wurde in RFC 1034 und RFC 1035 (November 1987) überarbeitet und formalisiert; diese Dokumente werden noch heute zitiert. Jon Postel koordinierte die Zuweisung der ursprünglichen 13 Root-Nameserver, beschriftet von a.root-servers.net bis m.root-servers.net, eine Anzahl, die nicht durch die Kapazität, sondern durch die UDP-Paketgrößenbeschränkung von 512 Byte der damaligen Zeit festgelegt wurde. Zwei große Erschütterungen prägten das DNS in diesem Jahrhundert um. Im Juli 2008 veröffentlichte Dan Kaminsky einen Cache-Poisoning-Angriff, mit dem Angreifer innerhalb von Sekunden gefälschte Datensätze in Resolver einschleusen konnten. Die Industrie reagierte mit einem koordinierten Patch (Source-Port-Randomisierung) und erneuertem Interesse an DNSSEC (RFC 4033-4035, März 2005), das Datensätze kryptografisch signiert. Die zweite Erschütterung war die Privatsphäre: Anfragen wanderten 35 Jahre lang im Klartext über UDP-Port 53. DNS over TLS (DoT, RFC 7858, Mai 2016) verpackt Anfragen in TLS auf Port 853. DNS over HTTPS (DoH, RFC 8484, Oktober 2018) tunnelt Anfragen über HTTPS auf Port 443 und verbirgt sogar die Tatsache, dass DNS stattfindet. DNS over QUIC (RFC 9250, Mai 2022) ist das neueste, das denselben Transport verwendet, der HTTP/3 antreibt. Die öffentlichen Resolver 1.1.1.1 (Cloudflare, gestartet am 1. April 2018), 8.8.8.8 (Google Public DNS, Dezember 2009) und 9.9.9.9 (Quad9, November 2017) unterstützen heute alle DoH und DoT.

Datensatztypen im Detail

• A (RFC 1035). 32-Bit-IPv4-Adresse. Eine Domain kann viele A-Datensätze für Lastausgleich haben; Resolver rotieren durch sie (Round-Robin-DNS).
• AAAA (RFC 3596, 2003). 128-Bit-IPv6-Adresse. Ausgesprochen «Quad-A». Stand 2024 sind etwa 45 % des Google-Traffics IPv6.
• CNAME (RFC 1035). Alias: «Folge diesem Namen und schau stattdessen seine Datensätze nach». Kann mit keinem anderen Datensatz unter demselben Namen koexistieren. Deshalb kann example.com nicht gleichzeitig einen CNAME und einen MX oder A am Apex haben; moderne Alternativen verwenden ALIAS oder ANAME (anbieterspezifisch) oder HTTPS-Datensätze (RFC 9460, 2023).
• MX (RFC 1035, aktualisiert durch RFC 7505 «null MX»). Mail-Austauschserver mit einem Prioritätswert. Niedrigere Priorität wird bevorzugt; Gleichstände werden zufällig gewählt. 0 . (RFC 7505, Juni 2015) sagt explizit «diese Domain empfängt keine E-Mail» und blockiert Spam an Domains ohne Postfach.
• TXT (RFC 1035). Freiformat-Textzeichenfolgen. Trägt jetzt kritische Authentifizierung: SPF (RFC 7208, 2014), DKIM (RFC 6376, 2011), DMARC (RFC 7489, 2015) und Eigentumsverifizierung für Google Search Console, Microsoft 365, ACME (Let's Encrypt) DNS-01-Challenges.
• NS (RFC 1035). Namen der autoritativen Nameserver. Immer mindestens zwei für Redundanz. Die «Glue-Records» in der übergeordneten Zone liefern IPs, damit ein rekursiver Resolver den Nameserver ohne zirkuläre Lookups erreichen kann.
• SOA (RFC 1035). Start of Authority. Ein einziger Datensatz pro Zone, der den primären Nameserver, die Admin-E-Mail (mit dem ersten . ersetzt durch @), die Seriennummer (bei Änderungen erhöht), Refresh, Retry, Expire und Minimum-TTL auflistet.
• CAA (RFC 8659, 2019; ursprünglich RFC 6844, 2013). Certificate Authority Authorisation. Listet auf, welche CAs Zertifikate für die Domain ausstellen dürfen. Verpflichtende Prüfung durch die Baseline-Anforderungen des CA/Browser Forums seit September 2017.
• SRV (RFC 2782, 2000). Service-Lokalisierung: Protokoll, Priorität, Gewicht, Port, Ziel-Host. Microsoft Active Directory, XMPP, SIP, Matrix-Föderation verwenden alle SRV-Datensätze zur Diensterkennung.
• PTR (RFC 1035). Reverse-DNS. Mappt eine IP zurück auf eine Domain. Lebt in den Zonen in-addr.arpa (IPv4) oder ip6.arpa (IPv6). Wird von vielen Mailservern benötigt, um E-Mails anzunehmen; ein fehlender PTR ist ein häufiges Spam-Signal.
• DNSKEY / DS / RRSIG (RFC 4034-4035). DNSSEC-Klempnerei. Der DNSKEY veröffentlicht die Signaturschlüssel der Zone; DS in der übergeordneten Zone ist der kryptografische «hier ist das nächste Glied der Kette»-Zeiger; RRSIG trägt die tatsächliche Signatur für jeden Datensatzsatz.

Wo DNS-Lookup wirklich hilft

• E-Mail auf einer neuen Domain einrichten. Überprüfen Sie, ob MX-Datensätze auf den richtigen Anbieter zeigen (Google Workspace aspmx.l.google.com, Microsoft 365 example-com.mail.protection.outlook.com, Fastmail, ProtonMail). Prüfen Sie SPF (v=spf1 include:_spf.google.com ~all), DKIM (selector._domainkey), DMARC (_dmarc TXT).
• Domain-Migration und Propagation. Nach der Aktualisierung der Nameserver beim Registrar fragen Sie sowohl die alten als auch die neuen autoritativen Server ab, um zu bestätigen, dass die Änderung global propagiert wurde. Verschiedene Resolver cachen für unterschiedliche Dauern (die TTL ist ein Hinweis, kein Vertrag).
• TLS-/SSL-Zertifikatsfehlersuche. Die ACME DNS-01-Challenge, die von Let's Encrypt und ähnlichen verwendet wird, erfordert das Platzieren eines TXT-Datensatzes unter _acme-challenge.example.com. Überprüfen Sie den Wert vor dem Auslösen der Zertifikatsausstellung, um verschwendete Rate-Limit-Versuche zu vermeiden.
• Erkennung von Subdomain-Übernahme-Risiken. Ein CNAME, der auf einen nicht registrierten Dienst zeigt (gelöschte Heroku-App, freigegebener S3-Bucket), lässt Angreifer ihn registrieren und Inhalte auf Ihrer Subdomain bereitstellen. Ein schnelles CNAME-Audit erfasst hängende Zeiger.
• CDN- und Load-Balancer-Verifizierung. Bestätigen Sie, dass eine Domain auf den richtigen Cloudflare-, Fastly-, Akamai-, CloudFront- oder Vercel-Endpunkt nach dem Deployment CNAMEt. Erkennen Sie, wenn Staging versehentlich auf Produktion zeigt.
• Geografischer DNS-Vergleich. Einige Sites liefern verschiedene A-Datensätze nach Region (GeoDNS). Abfragen von verschiedenen DoH-Endpunkten (Cloudflare 1.1.1.1 vs Google 8.8.8.8) deuten an, wie ein Nutzer in Frankfurt vs Mumbai die Site sieht.
• Sicherheit und Incident Response. Suchen Sie nach unerwarteten NS-Datensätzen (Registrar-Hijack), verdächtigen TXT-Datensätzen oder kürzlich hinzugefügten MX-Datensätzen. Verwenden Sie die SOA-Seriennummer, um nachzuverfolgen, wann sich eine Zone zuletzt geändert hat.

DNS-Fehler, die Sites und E-Mails kaputt machen

• CNAME am Apex. RFC 1034 verbietet das Platzieren eines CNAME auf example.com selbst (nur auf Subdomains wie www.example.com). Cloudflare, Route 53, DNSimple umgehen dies mit CNAME-Flattening oder ALIAS-Datensätzen; Vercel, Netlify verwenden HTTPS-Service-Binding-Datensätze (RFC 9460). Es im DNS-Panel eines einfachen Registrars zu versuchen, bricht E-Mails stillschweigend.
• Vergessen, die TTL vor einer Migration zu senken. Wenn Ihr A-Datensatz TTL 86400 (24 Stunden) hat und Sie ihn am Morgen des Umstiegs ändern, werden Resolver weltweit die alte IP bis zu einem Tag lang weiter ausgeben. Senken Sie TTLs einige Tage vor der Änderung auf 300 Sekunden.
• SPF-Datensatz mit zu vielen DNS-Lookups. RFC 7208 begrenzt SPF auf 10 DNS-Lookups pro Auswertung. Verketten Sie zu viele include:-Direktiven und Ihr SPF-Datensatz schlägt mit permerror fehl, was DMARC als Fehlschlag behandelt. Flachen Sie ab oder konsolidieren Sie mit Werkzeugen wie SPF Surveyor.
• Hängender CNAME nach Service-Abriss. Heroku-App gelöscht, aber der CNAME app.example.com zeigt immer noch auf example.herokuapp.com? Jeder kann diesen App-Namen registrieren und seinen Inhalt auf Ihrer Subdomain hosten. Auditieren und entfernen Sie verwaiste CNAMEs.
• Kein CAA-Datensatz. Ohne einen CAA-Datensatz kann jede CA im WebPKI (~50 weltweit) ein Zertifikat für Ihre Domain ausstellen. Sperren Sie es auf eine oder zwei vertrauenswürdige CAs: 0 issue "letsencrypt.org". Verpflichtende CA-Prüfung seit September 2017.
• Wildcard-Datensätze, die fehlende Einträge maskieren. Ein *.example.com A-Datensatz lässt jede Tippfehler-Subdomain auflösen und versteckt echte Konfigurationsfehler. Kombinieren Sie sorgfältig mit expliziten MX-Regeln, um Spam an Tippfehler-Adressen zu vermeiden.
• Mischen von DNSSEC und unsignierten Zonen während des Cutovers. Das Aktivieren von DNSSEC beim Registrar, bevor die neuen Nameserver signierte Datensätze liefern, erzeugt SERVFAIL für jeden validierenden Resolver (Cloudflare 1.1.1.1, Quad9). Signieren Sie immer zuerst, veröffentlichen Sie dann den DS-Datensatz.

Weitere häufig gestellte Fragen

Verwandte Tools