DNS Lookup / DNS Records auslesen

Wie funktioniert DNS?

Das Domain Name System (DNS) ist das Telefonbuch des Internets. Wenn dein Browser tools.kernelhost.com aufruft, wird zuerst die Domain in eine IP-Adresse übersetzt. DNS ist dabei nicht ein einzelner Server, sondern eine hierarchische Kette: Root-Server (.), TLD-Server (.com, .de, .at) und schließlich der Authoritative Nameserver der Domain. Diese Kette wird vom Resolver durchlaufen, der das Ergebnis dann lokal cached.

Eine DNS-Abfrage besteht aus Frage und Antwort: Welche Records vom Typ X gibt es für Domain Y? Die Antwort enthält einen oder mehrere Records plus eine TTL (Time To Live), die angibt, wie lange ein Resolver den Eintrag cachen darf. änderungen an DNS sind daher nicht sofort weltweit sichtbar, sondern propagieren entlang der Cache-Hierarchie.

Unser Tool startet einen UDP/TCP-Lookup über den System-Resolver des Containers in Frankfurt FRA01. Es gibt kein Tracking, kein Logging der abgefragten Domain und keine Drittanbieter-API. Die Antwort kommt in der Regel innerhalb weniger Millisekunden, weil der Frankfurt-Knoten direkt am DE-CIX angebunden ist.

Welche Record-Typen gibt es?

Jeder DNS-Record-Typ hat eine spezifische Aufgabe. Unser Tool zeigt die acht häufigsten Typen, die du für den Betrieb einer Domain wirklich brauchst.

• A: Mappt eine Domain auf eine IPv4-Adresse. Eine Domain kann mehrere A-Records haben (Round-Robin-DNS, Loadbalancing).
• AAAA: Mappt eine Domain auf eine IPv6-Adresse. Pflicht für moderne Web-Setups, Google bewertet IPv6-Konnektivität positiv im Ranking.
• MX: Mail Exchanger. Welcher Server ist für den Empfang von E-Mails an diese Domain zuständig. Mit Priorität (kleinere Zahl = bevorzugt) für Failover.
• TXT: Beliebiger Text. In der Praxis fast ausschließlich für SPF, DKIM, DMARC, Domain-Verification (Google, Microsoft) und _acme-challenge (Let's Encrypt) genutzt.
• CNAME: Alias auf eine andere Domain. www.kernelhost.com kann ein CNAME auf kernelhost.com sein. Auf der Apex-Domain (kernelhost.com selbst) ist CNAME nicht erlaubt.
• NS: Welche Nameserver sind authoritativ für diese Domain. NS-Records werden bei der Domain-Registrierung gesetzt und definieren, wo die anderen Records gepflegt werden.
• SOA: Start Of Authority. Definiert den primären Nameserver, die Admin-E-Mail und die Refresh/Retry/Expire/Minimum-TTL-Werte für Zone-Transfers.
• CAA: Certificate Authority Authorization. Welche CAs dürfen TLS-Zertifikate für diese Domain ausstellen. Schutz vor unautorisierter Zertifikat-Ausstellung.

MX vs SPF vs DKIM vs DMARC: Email-Setup erklärt

Ein vollständiges E-Mail-Setup besteht aus vier DNS-Komponenten. Fehlt eine, landen deine Mails entweder gar nicht im Empfänger-Postfach oder direkt im Spam-Ordner.

• MX (Empfang): Sagt der Welt, welcher Server eingehende E-Mails für deine Domain annimmt. Ohne MX kann dir niemand schreiben. MX zeigt typischerweise auf einen Hostnamen wie mx.kernelhost.com, der dann per A/AAAA aufgelöst wird.
• SPF (Versand-Authentifizierung): TXT-Record mit v=spf1, der angibt, von welchen IPs Mails für deine Domain rechtmäßig versendet werden dürfen. -all am Ende ist Pflicht (sonst kann jeder beliebige IP für dich fälschen).
• DKIM (kryptographische Signatur): Jede ausgehende Mail wird mit einem privaten Schlüssel signiert, der öffentliche Schlüssel liegt im DNS unter selector._domainkey.deine-domain.com als TXT mit v=DKIM1. Empfänger prüfen die Signatur und erkennen Manipulationen.
• DMARC (Policy + Reporting): TXT unter _dmarc.deine-domain.com mit v=DMARC1; p=reject; rua=mailto:dmarc@... DMARC kombiniert SPF und DKIM, sagt was der Empfänger mit fehlgeschlagenen Mails machen soll und liefert dir Reports.

Unser Tool parst SPF, DKIM und DMARC inline und zeigt dir mit grünem, gelbem oder rotem Badge sofort, ob das Setup sauber ist oder ob z. B. -all fehlt, der DKIM-Schlüssel zu kurz ist oder DMARC nur im Monitoring-Mode läuft.

TTL und DNS-Caching

TTL (Time To Live) gibt in Sekunden an, wie lange ein Resolver einen DNS-Eintrag cachen darf. Bei TTL=3600 fragt der Resolver erst nach einer Stunde wieder beim Authoritative Server nach. Das spart Bandbreite, macht aber DNS-änderungen nicht sofort sichtbar.

Die richtige TTL hängt davon ab, was du erreichen willst. Stabiler Produktionsbetrieb: hohe TTL (1 Stunde bis 1 Tag). Bevorstehender Server-Umzug: TTL Tage vorher auf 60-300 Sekunden senken, dann umziehen, dann wieder hochsetzen.

• Kurze TTL (60-300s): Schnelle änderungen, aber mehr Last auf dem Authoritative-Server und leicht höherer Latency-Overhead beim Lookup.
• Lange TTL (3600-86400s): Weniger Last, schnellere Antworten aus dem Cache, aber änderungen brauchen Stunden bis Tage bis sie weltweit sichtbar sind.
• Bei Migrationen: Mindestens 24 Stunden vor dem Umzug TTL auf 60-300 Sekunden senken, dann sind alle Resolver-Caches kurz vor dem Cutover-Termin abgelaufen.

Was ist DNSSEC und brauche ich das?

DNSSEC (DNS Security Extensions) signiert DNS-Records kryptographisch, damit ein Resolver prüfen kann, ob die Antwort auf dem Weg manipuliert wurde. Ohne DNSSEC kann ein böswilliger ISP- oder Public-WiFi-Resolver dir falsche IPs liefern (DNS-Spoofing).

DNSSEC nutzt zwei Schlüssel: ZSK (Zone Signing Key) signiert die Records, KSK (Key Signing Key) signiert den ZSK. Der KSK-Hash wird als DS-Record beim Registrar hinterlegt, was die Vertrauenskette bis zur Root schließt.

Brauchst du das? Für Banken, Behörden, Mail-Provider und alle, die SMIMEA-, TLSA- oder OPENPGPKEY-Records (DANE) nutzen wollen: ja. Für einen normalen Webshop ist DNSSEC ein nice-to-have, das aber nichts kostet, wenn der Provider es unterstützt. KernelHost-DNS unterstützt DNSSEC out-of-the-box.

Typische Debugging-Use-Cases

Wofür du dieses Tool im Alltag wirklich brauchst:

• Mail kommt nicht an: MX-Records prüfen, dann SPF, DKIM, DMARC. Ist eine der vier Komponenten kaputt, landet die Mail im Spam oder wird vom Empfänger gar nicht angenommen.
• Domain zeigt auf falsche IP: A- und AAAA-Records prüfen. Manchmal hat man bei einem Server-Umzug nur die A-Records umgestellt, aber alte AAAA-Records vergessen.
• Subdomain antwortet nicht: CNAME oder direkten A-Record auf der Subdomain prüfen. Häufiger Fehler: Subdomain wurde im Hosting-Panel angelegt, aber DNS zeigt noch ins Leere.
• DNS-Propagation prüfen: Nach einer änderung mehrere Lookups in zeitlichem Abstand machen. Wenn TTL abgelaufen ist, sollten alle Resolver die neuen Records sehen.
• Lets Encrypt verweigert Zertifikat: CAA-Records prüfen. Steht dort z. B. nur ein anderer CA-Eintrag und Lets Encrypt fehlt, weigert sich Lets Encrypt, ein Zertifikat auszustellen.

DNS und KernelHost

KernelHost-Webhosting beinhaltet komplettes Managed-DNS: alle Records werden über unser Control-Panel gepflegt, DNSSEC ist standardmäßig aktiv, geographisch redundante Anycast-Nameserver in Frankfurt und Wien sorgen für schnelle Antworten weltweit.

Wer nur DNS-Hosting ohne Webspace braucht, kann unsere Domain-Service-Pakete nutzen. Domain-Registrierung, Transfer und DNS-Management sind in jedem KernelHost-Hosting-Tarif inklusive. Für komplexere Setups (Split-Horizon, GeoDNS, hohe TTL-Präzision) ist VPS- plus eigener Authoritative-Server eine Option, das Tool hier kannst du jederzeit zur Diagnose nutzen.

Häufig gestellte Fragen