Viele kennen DNS aus einem einzigen Zusammenhang: Eine Domain zeigt auf eine IP-Adresse. Das stimmt – aber es ist nur ein kleiner Teil des Bildes.
In Unternehmen hängt an DNS weit mehr als nur die Website. E-Mail-Zustellung, Microsoft-365-Anbindungen, Cloud-Dienste, Standortkopplungen, Reverse DNS, Sicherheitsrichtlinien für E-Mail, Failover-Szenarien, Subdomains für Anwendungen oder VPN-Portale: All das hat direkt oder indirekt mit DNS zu tun.
Genau deshalb wird DNS in vielen gewachsenen IT-Umgebungen unterschätzt. Es wirkt im Alltag still. Aber wenn DNS falsch gepflegt, schlecht dokumentiert oder nur halb verstanden ist, werden Probleme schnell teuer: Mails landen im Spam, Dienste sind nicht erreichbar, Zertifikate lassen sich nicht sauber ausrollen, Migrationen geraten ins Stocken oder intern weiß niemand mehr, welche Einträge noch benötigt werden.
DNS ist keine Randnotiz. DNS ist ein Grundpfeiler für Erreichbarkeit, Vertrauen und geordneten IT-Betrieb.
Warum das „Telefonbuch des Internets“ als Erklärung zu kurz greift
Der bekannte Vergleich mit dem Telefonbuch hilft für den Einstieg, aber für Unternehmen greift er zu kurz. DNS ordnet nicht nur Namen einer Adresse zu. DNS beschreibt heute auch Rollen, Zuständigkeiten, Dienste, Prioritäten, Autorität und Sicherheitsrichtlinien.
Eine Domain kann gleichzeitig Website, Webshop, VPN-Zugang, Ticketsystem, SIP-Dienste, Newsletter-Versand, Microsoft-365-Einbindung, Cloud-Anwendungen und E-Mail-Schutzregeln abbilden. In der Praxis ist DNS daher eher ein verteiltes Steuerungs- und Vertrauenssystem als nur ein Nachschlagewerk.
Was DNS im Unternehmen konkret steuert
- Web-Erreichbarkeit: Welche Website oder welcher Dienst hinter einer Domain oder Subdomain erreichbar ist.
- E-Mail-Fluss: Welche Mailserver für die Zustellung zuständig sind und welche Systeme im Namen einer Domain senden dürfen.
- Cloud- und SaaS-Anbindungen: Ob Subdomains zu eigenen Diensten, CDN-Endpunkten oder Cloud-Anbietern weiterleiten.
- Vertrauen und Reputation: Ob Reverse DNS, SPF, DKIM und DMARC sauber gesetzt sind.
- Delegation und Zuständigkeit: Welche Nameserver für eine Zone autoritativ sind.
- Fehlertoleranz und Betrieb: Wie TTLs, Prioritäten und Dokumentation Änderungen, Migrationen und Störungen beeinflussen.
Die Grundbegriffe, die man kennen sollte
Bevor wir die einzelnen Record-Typen ansehen, lohnt sich ein kurzer Blick auf ein paar Begriffe, die in der Praxis ständig vorkommen:
- Zone: Der Verwaltungsbereich einer Domain, also die Gesamtheit der zugehörigen DNS-Einträge.
- Record: Ein einzelner Eintrag mit einem Typ und einem Wert, zum Beispiel A, MX oder TXT.
- TTL (Time to Live): Wie lange Resolver Antworten zwischenspeichern dürfen. Das ist für Umstellungen und Fehlersuche wichtig.
- Authoritative Nameserver: Die Quelle der Wahrheit für eine Zone.
- Recursive Resolver: Der Dienst, der für Clients Antworten ermittelt und zwischenspeichert.
Gerade TTL-Werte sind in der Praxis ein klassischer Stolperstein. Wer eine Website oder E-Mail-Infrastruktur umzieht und TTLs nicht rechtzeitig absenkt, wartet unter Umständen länger als nötig auf die wirksame Umstellung. Umgekehrt erhöhen extrem niedrige TTLs unnötig die Abhängigkeit von der Live-Erreichbarkeit der autoritativen Nameserver.
A- und AAAA-Records: Die Basis der Erreichbarkeit
Der A-Record ordnet einen Hostnamen einer IPv4-Adresse zu. Der AAAA-Record macht dasselbe für IPv6. Beide sind der klassische Einstieg in DNS – und trotzdem entstehen schon hier viele Fehler.
Einige typische Praxisfragen:
- Zeigt die Hauptdomain auf den richtigen Webserver?
- Existieren separate Einträge für
www, Portale, VPN, Intranet oder Kundenbereiche? - Gibt es bei IPv6 dieselbe Sorgfalt wie bei IPv4 – oder ist AAAA irgendwann „nebenbei“ entstanden?
- Wurde bei einem Umzug ein alter A-Record vergessen?
In modernen Umgebungen reicht es längst nicht, einen einzelnen A-Record zu setzen und das Thema abzuhaken. Unternehmen arbeiten mit mehreren Webdiensten, CDN- oder Reverse-Proxy-Konzepten, hybriden Infrastrukturen und verteilten Standorten. Dadurch wird schon der vermeintlich einfache „Namens-zu-Adressen“-Teil komplexer.
CNAME: Alias statt direkter Zieladresse
Ein CNAME-Record verweist nicht direkt auf eine IP-Adresse, sondern auf einen anderen Namen. Das ist praktisch, wenn Dienste logisch getrennt, aber technisch flexibel angebunden werden sollen. Beispiele sind Subdomains wie portal, service, help oder autodiscover.
Der Nutzen ist klar: Statt an mehreren Stellen IPs zu pflegen, wird ein Alias auf einen kanonischen Namen gesetzt. Ändert sich dessen Ziel, folgen die abhängigen Dienste automatisch. Das reduziert Pflegeaufwand – setzt aber voraus, dass die Struktur bewusst geplant ist.
Wichtig ist dabei auch zu wissen, was nicht geht oder nicht überall sauber unterstützt wird. Eine Root-Domain kann bei vielen DNS-Providern nicht einfach klassisch als CNAME betrieben werden. Manche Anbieter lösen das über ALIAS- oder ANAME-Mechanismen. Wer das nicht versteht, baut schnell unnötige Sonderkonstruktionen.
MX-Records: Wohin eingehende E-Mails zugestellt werden
MX-Records legen fest, welche Mailserver E-Mails für eine Domain annehmen. Sie gehören zu den wichtigsten Einträgen überhaupt, weil schon kleine Fehler spürbare Folgen haben: Mails kommen nicht an, laufen ins Leere, landen bei einem alten Provider oder zeigen auf Systeme, die gar nicht mehr genutzt werden.
Besonders kritisch wird es bei Migrationen – etwa beim Wechsel zu Microsoft 365 oder beim Parallelbetrieb mit Gateways, Archivierungslösungen oder Sicherheitsdiensten. Hier muss klar sein, welche MX-Prioritäten gesetzt sind, welche Sicherheitsstufen davorliegen und ob die DNS-Konfiguration zum tatsächlichen Mailfluss passt.
TXT-Records: Mehr als „nur Text“
Der TXT-Record wird gern unterschätzt, weil er auf den ersten Blick unspektakulär wirkt. In der Praxis ist er aber einer der wichtigsten Container für moderne Sicherheits- und Verifizierungsinformationen.
Vor allem im E-Mail-Bereich spielen TXT-Records eine zentrale Rolle:
- SPF: Welche Systeme im Namen der Domain E-Mails versenden dürfen.
- DKIM: Öffentliche Schlüssel zur Signaturprüfung versendeter E-Mails.
- DMARC: Richtlinien und Berichte für den Umgang mit nicht authentifizierten Nachrichten.
- Domain-Verifikationen: Nachweise für Microsoft 365, Google, Newsletter-Plattformen oder andere Cloud-Dienste.
Gerade hier entstehen im Alltag viele Fehler: zu viele SPF-Weiterleitungen, unklare DKIM-Selector, halb eingeführte DMARC-Richtlinien oder vergessene Verifizierungseinträge aus alten Projekten. Solche Punkte sind nicht nur technisch unsauber, sondern können ganz konkret Vertrauen zerstören – etwa wenn legitime Mails im Spam landen oder sich Absenderfälschungen leichter ausnutzen lassen.
Trotz sauberer SPF-, DKIM- und DMARC-Konfiguration können einzelne Nachrichten durchkommen. Dann ist wichtig zu wissen: Phishing-Mail geöffnet: Was jetzt im Unternehmen zu tun ist.
PTR beziehungsweise Reverse DNS: Der Blick von der IP zurück zum Namen
Bei einem PTR-Record läuft die Zuordnung andersherum: Eine IP-Adresse wird einem Hostnamen zugeordnet. Das nennt man Reverse DNS. Für viele Unternehmen ist das zunächst abstrakt, in der Praxis ist es aber relevant – vor allem bei E-Mail, Logging, Security und Diagnose.
Wenn ein Mailserver E-Mails versendet, achten empfangende Systeme oft darauf, ob die sendende IP einen plausiblen PTR-Eintrag hat. Fehlt dieser oder wirkt er unpassend, leidet die Reputation. Auch im Troubleshooting hilft Reverse DNS enorm, weil IP-Adressen in Logs, Firewalls oder Monitoring-Systemen leichter eingeordnet werden können.
Wichtig: PTR-Zonen liegen häufig nicht beim klassischen DNS-Provider der Domain, sondern beim Provider der IP-Adressbereiche oder beim Rechenzentrums- beziehungsweise Mailanbieter. Genau an dieser Stelle entstehen oft unnötige Reibungsverluste, weil Zuständigkeiten nicht dokumentiert sind.
NS-Records: Wer ist für die Zone autoritativ?
NS-Records geben an, welche Nameserver für eine Zone zuständig sind. Das klingt unscheinbar, ist aber strategisch wichtig. Wenn nicht klar ist, wo die autoritative Wahrheit einer Domain liegt, wird jede Änderung zum Risiko.
Typische Praxisprobleme sind:
- Die Domain liegt bei einem Registrar, die Zone bei einem anderen Anbieter, aber niemand weiß genau, wer aktuell die autoritativen Nameserver stellt.
- Nach einer Migration zeigen NS-Einträge noch auf einen Altbestand.
- Der Zugang zum DNS liegt bei einer Einzelperson oder in einem privaten Postfach.
- Es existiert keine sauber dokumentierte Freigabe- und Änderungsroutine.
Gerade in gewachsenen Unternehmen ist das ein echter Klassiker. Die Technik funktioniert irgendwie, solange niemand etwas ändern muss. Sobald jedoch eine Website migriert, Microsoft 365 eingeführt oder eine Subdomain für einen neuen Dienst gebraucht wird, fällt die organisatorische Schwäche auf.
SOA-Records: Verwaltungs- und Zeitinformationen der Zone
Der SOA-Record – Start of Authority – beschreibt Grundparameter einer Zone. Dazu gehören typischerweise der primäre Nameserver, ein Kontakt, die Seriennummer und verschiedene Zeitwerte für Refresh, Retry und Expire.
Viele Unternehmen beschäftigen sich kaum damit, und im Alltag muss man das auch nicht ständig. Trotzdem zeigt der SOA-Record, wie professionell eine Zone geführt wird. Saubere Serienlogik, klare Zuständigkeit und sinnvolle Zeitwerte sind ein Zeichen dafür, dass die Zone nicht dem Zufall überlassen wird.
Weitere Record-Typen, die in der Praxis wichtig sein können
Die gängigen Kern-Records decken viel ab. In der Praxis begegnet man aber häufig weiteren Typen:
- CAA: Legt fest, welche Zertifizierungsstellen Zertifikate für eine Domain ausstellen dürfen.
- SRV: Wird für bestimmte Dienste genutzt, etwa in Telefonie- oder Verzeichnisumgebungen.
- DS / DNSSEC: Für die kryptografische Absicherung der DNS-Kette.
Für viele mittelständische Unternehmen ist nicht jeder dieser Typen täglich relevant. Aber sie zeigen, dass DNS weit über die Frage „Welche IP steckt hinter der Website?“ hinausgeht.
Typische DNS-Fehler im Unternehmensalltag
Die meisten Probleme entstehen nicht, weil DNS an sich exotisch wäre. Sie entstehen, weil Änderungen historisch gewachsen, unvollständig dokumentiert oder unter Zeitdruck umgesetzt wurden. Zu den häufigsten Fehlern gehören:
- Veraltete Einträge: Alte Ziele, nicht mehr genutzte Subdomains, frühere Provider oder verwaiste Verifizierungsrecords bleiben stehen.
- Fehlende Dokumentation: Niemand weiß, warum ein Eintrag existiert und welche Abhängigkeiten daran hängen.
- Unsaubere E-Mail-Authentifizierung: SPF ist zu breit, DKIM nicht vollständig aktiv oder DMARC nie konsequent eingeführt.
- Unklare Zuständigkeiten: Registrar, DNS-Provider, Mailanbieter und Webhoster sind organisatorisch nicht sauber getrennt.
- Falsche TTL-Strategie: Bei Umzügen und Änderungen dauern Anpassungen unnötig lange oder sind unnötig riskant.
- Kein Blick auf Sicherheit: Kein MFA-Schutz am Registrar, keine Änderungsprotokolle, keine regelmäßige Prüfung auf unnötige oder gefährliche Records.
Warum DNS auch ein Sicherheitsthema ist
DNS ist nicht nur Infrastruktur, sondern immer auch Sicherheitsoberfläche. Wer Domains, Nameserver oder kritische TXT-Records kontrolliert, kontrolliert unter Umständen Website, E-Mail-Vertrauen und zentrale Cloud-Anbindungen.
Zu den sicherheitsrelevanten Punkten gehören unter anderem:
- Registrar-Zugänge mit MFA und sauberem Berechtigungskonzept
- regelmäßige Überprüfung alter oder nicht mehr benötigter Einträge
- Vermeidung von „dangling DNS“ und unnötigen Subdomains
- saubere Dokumentation von Änderungen und Freigaben
- Prüfung von SPF, DKIM, DMARC und Reverse DNS im Zusammenspiel
Ein falsch gesetzter Record kann im schlimmsten Fall nicht nur Erreichbarkeit stören, sondern auch Angriffsflächen vergrößern oder Vertrauen nach außen beschädigen.
So sieht saubere DNS-Verwaltung in Unternehmen aus
Ordentliche DNS-Verwaltung bedeutet nicht, dass jede Umgebung maximal komplex sein muss. Im Gegenteil: Gute DNS-Verwaltung schafft Übersicht. Dazu gehören in der Praxis vor allem diese Punkte:
- Zentrale Übersicht: Welche Domains, Subdomains, Zonen und Provider gibt es?
- Dokumentation: Wofür ist jeder relevante Eintrag da, wer ist zuständig und welche Abhängigkeiten existieren?
- Berechtigung und Schutz: Zugriff nur für definierte Personen, MFA, keine privaten Postfächer, keine Schattenverwaltung.
- Änderungsprozess: Freigabe, Umsetzung, Prüfung, Rückfalloption und Dokumentation.
- Regelmäßige Prüfung: Altlasten entfernen, Sicherheits- und E-Mail-Konfiguration prüfen, Änderungen sauber nachhalten.
Wann ein DNS-Review sinnvoll ist
Ein strukturierter DNS-Check lohnt sich besonders dann, wenn:
- Microsoft 365 eingeführt oder umgebaut wird,
- Website oder Mailprovider gewechselt werden,
- ein Unternehmen mehrere Standorte oder neue Cloud-Dienste einbindet,
- es Probleme mit E-Mail-Zustellung oder Spam-Reputation gibt,
- intern niemand mehr sauber erklären kann, welche Records aktuell geschäftskritisch sind.
Gerade in historisch gewachsenen Umgebungen ist ein DNS-Review oft einer der schnellsten Wege, Ordnung in eine unsichtbare, aber zentrale Schicht der IT zu bringen.
DNS sauber aufstellen statt im Blindflug weiterarbeiten
Wenn Ihre DNS-Konfiguration historisch gewachsen ist, Mails nicht sauber zustellen, Cloud-Dienste angebunden werden oder schlicht niemand mehr sicher sagen kann, welche Einträge aktuell relevant sind, lohnt sich ein strukturierter Blick darauf.
EDV Systeme Donner unterstützt Unternehmen dabei, DNS-Strukturen zu prüfen, zu dokumentieren und sauber an Website, E-Mail, Microsoft 365, Sicherheitsanforderungen und laufenden IT-Betrieb anzupassen.
Fazit
DNS ist einer dieser Bereiche, die oft erst auffallen, wenn etwas nicht mehr funktioniert. Genau das ist der Fehler. Wer DNS erst dann ernst nimmt, wenn E-Mails nicht ankommen oder Dienste ausfallen, arbeitet reaktiv.
Unternehmen fahren besser, wenn sie DNS als das behandeln, was es tatsächlich ist: eine zentrale Schicht für Erreichbarkeit, Vertrauen, Sicherheitsregeln und geordneten IT-Betrieb. A-Records sind wichtig – aber sie sind nur der Anfang.
Häufige Fragen zu DNS-Record-Typen im Unternehmen
Welche DNS-Record-Typen sind im Unternehmensalltag am wichtigsten?
Vor allem A, AAAA, CNAME, MX, TXT, PTR, NS und SOA. Ergänzend spielen oft SPF, DKIM und DMARC über TXT-Einträge sowie je nach Einsatz CAA oder SRV eine Rolle.
Warum reichen A-Records allein nicht?
Weil moderne Unternehmens-IT mehr braucht als die Zuordnung einer Domain zu einer IP-Adresse. E-Mail-Zustellung, Cloud-Dienste, Reverse DNS, Autorität, Delegation und Sicherheitsrichtlinien hängen ebenfalls an DNS.
Wofür ist TXT in der Praxis wichtig?
Neben allgemeinen Verifizierungen vor allem für SPF, DKIM und DMARC. Diese Informationen helfen, E-Mails zu authentifizieren und Missbrauch im Namen der Domain zu begrenzen.
Ist Reverse DNS nur für große Umgebungen relevant?
Nein. Schon bei normalem E-Mail-Versand oder bei Log- und Security-Auswertungen ist PTR beziehungsweise Reverse DNS oft relevant.
Wann sollte man DNS dokumentieren oder prüfen?
Spätestens bei Migrationen, Einführung neuer Cloud-Dienste, Providerwechseln, E-Mail-Problemen, Sicherheitsvorfällen oder wenn Zuständigkeiten unklar geworden sind.