DNS

Allgmeines

DNS (Domain Name System) ist ein hierarchisch angeordnetes System für Rechner, Dienste und andere Resourcen in IP-basierten Netzen. In DNS-Einträgen werden verschiedene Informationen mit Domain-Namen in Verbindung gesetzt. Insbesondere nutzt man DNS, um einen Domain-Namen auf eine IP-Adresse aufzulösen. Erst so ist es überhaupt möglich, z.B. mit dem Browser (Web-Client) oder Mail-Client eine Verbindung mit dem zuständigen Server per IP herzustellen, ohne die IP direkt zu benutzen.

DNS Anfragen

Die Anfrage durchläuft dabei folgende Schritte:

(C) CC-BY-SA 4.0. DNS Architecture, Aaron Filbert, Wikimedia Foundation, abg. am 18.12.2023

Die Anfrage hört dabei an dem Knoten auf, der die Antwort zur Anfrage kennt (bspw. durch Caching). In dem Fall beantwortet dieser Knoten die Anfrage. In der Regel sind mindestens die TLD DNS Server den öffentlichen rekursiven DNS Servern bekannt, sodass eine Anfrage an die Root DNS Server selten erfolgen muss.

Begriffserklärungen:

• Root Nameserver: von ICANN betriebene DNS-Server, die Informationen zu allen TLDs enthält
• TLD Nameserver: von dem jeweiligen Betreiber der Top Level Domain (TLD) betrieben, enthält Informationen zu allen SLDs unter der TLD
• SLD Nameserver: von dem Betreiber der Second Level Domain (SLD) (oder dessen Dienstleister) betrieben

DNS Paket

Bits	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
H E A D E R	ID
	QR	OPCODE				AA	TC	RD	RA	Z			RCODE
	QCOUNT
	ANCOUNT
	NSCOUNT
	ARCOUNT
Q/A	QUESTION
	ANSWER
	AUTHORITY
	ADDITIONAL

Der Header

Im Header werden diverse Meta-Daten mitgeliefert, viele davon anhand von Flags. Nachfolgend sind die einzelnen Felder im Header erläutert:

• ID: 16-Bit ID, das von dem Prozess, der die Anfrage stellt, festgesetzt wird
• QR: Ein Flag zur Signalisierung, ob die Nachricht eine Query oder eine Antwort ist
• • 0: Query / Anfrage
• • 1: Response / Antwort
• OPCODE: 4 Bits zum Identifizieren des Query-Typen (0 für Standard-Anfrage)
• AA: Authorative Antwort (signalisiert, ob die Antwort vom für die Domain authorativen DNS Server stammt)
• TC: TrunCation, sagt an ob relevante Teile in der Nachricht entfernt wurden
• RD: Recursion Desired
• • 0: Falls eine rekursive Anfrage nicht erforderlich ist
• • 1: Falls erwünscht ist, die Anfrage rekursiv zu verfolgen
• RA: Recursion Available, sagt an ob eine rekursive Anfrage beim angesprochenen DNS Server verfügbar ist
• Z: Reserviert, muss auf 0 gesetzt sein
• RCODE: Response Code
• • 0: Keine Fehler
• • 1: Format Error, die Query konnte nicht interpretiert werden
• • 2: Server Failure, aufgrund server-internem Fehler konnte die Query nicht verarbeitet werden
• • 3: Name Error, NXDOMAIN (wird nur von einem Authorative DNS Server gesetzt)
• • 4: Not Implemented, Query Typ wird vom DNS Server nicht unterstützt
• • 5: Refused, der DNS Server hat die Anfrage abgelehnt
• QCOUNT: Anzahl der Anfragen im QUESTION-Feld
• ANCOUNT: Anzahl der Resource Records im ANSWER-Feld
• NSCOUNT: Anzahl der NS Records im AUTHORITY-Feld
• ARCOUNT: Anzahl der Resource Records im ADDITIONAL-Feld

aus: RFC 1035, IETF, abg. am 18.12.2023

DNS Typen

Es gibt verschiedene Arten von DNS Servern. Im Anschluss werden diese Typen näher erläutert.

Authorative DNS

Authorative DNS Server sind diejenigen DNS-Server, die für die jeweilige Domäne verantwortlich sind. Hat ein Recursive DNS Server keine EInträge im Cache, fragt er beim Authorativen DNS Server nach den gesuchten Informationen. Dabei erfolgt folgende Hierarchie:

1. Root DNS Server der ICANN weiß, wo die TLD DNS Server sind
2. TLD DNS Server weiß, wo die authorativen SLD DNS Server sind
3. SLD DNS Server weiß, untter welcher IP Adresse die Domain & Subdomains

Die Root DNS Server sind weltweit verteilt. Man redet hierbei von 13 solchen Servern, wobei auch diese 13 redundant abgebildet sind. Diese werden von der ICANN (Internet Corporation for Assigned Names and Numbers) verwaltet.

Die TLD DNS Server werden von dem Registry der TLD (Top Level Domain) verwaltet. So z.B. durch DENic für .de bzw. EURid für .eu TLDs. Hier werden für registrierte SLDs (Second Level Domains) die für die SLD zugehörigen DNS Server hinterlegt.

Die SLD DNS Server werden entweder vom Domain-Inhaber oder einem von ihm beauftragten Dienstleister verwaltet. Dieser ist autorisiert, alles einzustellen, was diese SLD und ihre Subdomains betrifft.

Recursive DNS

Ein Rekursiver DNS Server wird von diversen Dienstleistern wie Google, Cloudflare, aber auch dem eigenen Internetanbieter angeboten. Dieser stellt die Schnittstelle zwischen dem Heimnetz und den Authorative DNS Servern dar. Er stellt rekursiv DNS Queries in etwa nach folgendem Schema:

query(domain):
    if( cahed(domain) )
        return cacheEntry(domain)
     // ein Level höher in der Domain-Kette
    firstDot = domain.position('.')
    domain = domain.substr(firstDot, domain.length)
    return query(domain)

Also wird vorher geschaut, ob zu fisi.donmez.eu bereits die Antwort oder alternativ der autorative DNS Server zum Versenden einer Anfrage gecached sind. Falls nein, wird geschaut, ob der autorative DNS Server für donmez.eu bekannt ist. Falls auch das nicht bekannt ist, wird geschaut, ob der autorative DNS Server für .eu bekannt ist. In der Regel höert die Rekursion hier auf. Falls nicht, wird ein Root DNS Server angefragt.

Die geläufigsten Recursive DNS Server sind:

• Google DNS: 8.8.8.8, 8.8.4.4
• Cloudflare: 1.1.1.1, 1.0.0.1

Reverse DNS (rDNS)

Nicht nur Domain-Namen können auf eine IP-Adresse aufgelöst werden, sondern können auch IP-Adressen auf einen Hostnamen bzw. auf eine Domain aufgelöst werden. Dies geschieht mittels rDNS.

Mehr dazu unter: IP / Namens- & Adressauflösung # Reverse DNS (rDNS)

DNS Einträge

Im DNS Server sind Einträge (Resource Records) hinterlegt. Jeder Eintrag ist wie folgt aufgebaut:

0 - 16 Bits
Name (var. Länge)

Record Type
RR Class
TTL
TTL
RDLENGTH
RDATA (var. Länge)

• Name: Name des Knoten, auf den sich das Resource Record bezieht
• RR Type: Bspw. A (1), AAAA (28), CNAME (5), MX (15), NS (2), PTR (12), SOA (6), TXT (16), etc.
• RR Clas: Internet (1), CSNET (2), CHAOS (3), Hesiod (4)
• TTL: Time To Live, Speicher- bzw. Cachedauer
• RDLENGTH: 16-Bit Integer für die Länger des RDATA Feldes in 8-Bit Bytes
• RDATA: Der Inhalt des RR (String variabler Länge aus 8-Bit Bytes)

aus: RFC 1035, IETF, abg. am 18.12.2023

DNS Record-Typen

Nachfolgend sind einige geläufigen Resource Record Typen aufgeführt.

SOA

SOA, kurz für Start of Authority, ist ein RR welche administrative Informationen zur Zone enthält. Ein Beispiel könnte wie folgt aussehen:

example.com.        3600    IN  SOA ns.icann.org. noc.dns.icann.org. 2022091377  7200  3600  1209600  3600

Dies besagt, dass der Nameserver ns.icann.org für die Domain example.com antwortet und gibt noc[at]dns.icann.org als die E-Mail Adresse des Verantwortlichen für diese DNS Zone an. Die Zahlen am Ende hingegen besagen einige weitere Informationen, die man in dieser Schreibweise besser ablesen kann:

example.com. IN SOA ns.icann.org. noc.dns.icann.org. (
    2022091377 ; Serial
    7200       ; Refresh
    3600       ; Retry
    1209600    ; Expire
    3600       ; Minimum
)

Das ist auch die Schreibweise, wie ein SOA Record in einem DNS Server konfiguriert sein könnte, während die erste Schreibweise die Antwort auf eine DNS Anfrage mittels dig @1.1.1.1 SOA example.com. darstellt.

NS

Ein NS Record besagt, welcher DNS Server für die entsprechende Domäne authorativ ist.

TXT

Mittels TXT Records kann ein nicht näher spezifizierter Text ins DNS hinterlegt werden. Dies wird bspw. für SPF (Sender Policy Framework) zur Bekämpfung von gespooften Spam E-Mails oder auch zur Verifizierung der Domain-Inhaberschaft für diverse Dienste (z.B. Google Analytics oder auch von verschiedenen CAs zur Domain-Verifizierung) genutzt.

A

Mit Hilfe des A Records kann eine Domain auf eine IPv4 Adresse aufgelöst werden.

AAAA

Mit Hilfe des AAAA Records kann eine Domain auf eine IPv6 Adresse aufgelöst werden. Im Grunde genommen steht ein jedes A für eine IP-Adresslänge von 32 Bits. Also AAAA -> 4x 32-Bits = 128-Bits, was auch der Bitlänge einer IPv6 Adresse entspricht.

CNAME

CNAME steht kurz für Canonical Name. Damit kann ein Domain-Name auf einen anderen Namen aufgelöst werden. Zur Auflösung der IP-Adresse müssen entsprechend alle CNAME Ziele in der Chain aufgelöst werden, bis ein A oder AAAA Record mit einer IPv4 bzw. IPv6 Adresse als Ziel erreicht wird.

MX

MX steht kurz für Mail Exchange und informiert etwaige Absender darüber, wo der für die Domain zuständige Mail Transfer Agent (MTA) zu finden ist. Mit diesem werden E-Mail Nachrichten mittels SMTP ausgetauscht. MX ersetzt die alten nicht mehr genutzten Record Typen MS (Mail Destination) & MF (Mail Forwarder)

PTR

PTR steht für Domain Name Pointer. Spezielle Domains wie z.B. .in-addr.arpa bzw. .ip6.arpa zeigen damit auf einen anderen Ort im Domain Space. Damit kann bspw. eine IPv4 bzw. IPv6 Adresse auf einen Domain-Namen aufgelöst werden.

Mehr dazu unter: IP / Namens- & Adressauflösung # Reverse DNS (rDNS)

SRV

SRV steht kurz für Service und definiert für einen Dienst unter welchem Hostnamen und Portnummer der Dienst zu finden ist.

CAA

CAA steht kurz für Certificate Authority Authorization und definiert, welche CAs für die Domain und ggf. auch für Subdomains autorisiert sein seollen, Zertifikate auszustellen. Weiteres dazu kann RFC 8659 entnommen werden.

DS

DS steht kurz für Delegation Signer und enthält Informationen zur Identifizierung des Signaturschlüssels für eine delegierte Zone. Der DS Record muss jeweils in einer übergeordneten Zone hinterlegt werden, damit die Signatur verifiziert werden kann. Er referenziert auf den DNSKEY Record der delegierten Zone. Dieser Record Typ wird in Verbindung mit DNSSEC genutzt.

DNSKEY

DNSKEY steht für DNS Key und beschreibt das öffentliche Zertifikat der Zone mit der ein DNS Resolver die DNSSEC Signatur eines RRSIG (Resource Record Signature) Records verifizieren kann.

TLSA

TLSA wird genutzt, um ein öffentliches Zertifikat mit dem Domain-Namen zu verbinden. Dies wird insbesondere in Verbindung mit DANE genutzt, welcher jedoch auch DNSSEC erfordert.

Format

DNS Einträge werden in Zonen hinterlegt. Dabei wird in der Regel pro Domain eine eigene Zone mit einem eigenen Zone-File erstellt. In der Zone File ist die Zone samt der darin enthaltenen DNS Einträge beschrieben.

Es ecistieren zwei geläufige Formate:

• BIND-Format: In RFC 1034 Punkt 3.6.1 & RFC 1035 Punkt 5 definierter Standard (BIND)
• DB-Format: Die Zonen werden in einer Datenbank hinterlegt (NSD, PowerDNS, microsoft DNS, etc.)

Hier wird nur das BIND-Format thematisiert. EIn Beispiel hierfür sieht so aus:

$ORIGIN example.com.     ; designates the start of this zone file in the namespace
$TTL 3600                ; default expiration time (in seconds) of all RRs without their own TTL value
example.com.  IN  SOA   ns.example.com. username.example.com. ( 2020091025 7200 3600 1209600 3600 )
example.com.  IN  NS    ns                    ; ns.example.com is a nameserver for example.com
example.com.  IN  NS    ns.somewhere.example. ; ns.somewhere.example is a backup nameserver for example.com
example.com.  IN  MX    10 mail.example.com.  ; mail.example.com is the mailserver for example.com
@             IN  MX    20 mail2.example.com. ; equivalent to above line, "@" represents zone origin
@             IN  MX    50 mail3              ; equivalent to above line, but using a relative host name
example.com.  IN  A     192.0.2.1             ; IPv4 address for example.com
              IN  AAAA  2001:db8:10::1        ; IPv6 address for example.com
ns            IN  A     192.0.2.2             ; IPv4 address for ns.example.com
              IN  AAAA  2001:db8:10::2        ; IPv6 address for ns.example.com
www           IN  CNAME example.com.          ; www.example.com is an alias for example.com
wwwtest       IN  CNAME www                   ; wwwtest.example.com is another alias for www.example.com
mail          IN  A     192.0.2.3             ; IPv4 address for mail.example.com
mail2         IN  A     192.0.2.4             ; IPv4 address for mail2.example.com
mail3         IN  A     192.0.2.5             ; IPv4 address for mail3.example.com

aus: Zone File, Wikipedia, abg. am 19.12.2023

DNSSEC

Mittels DNSSEC (DNS Security Extension) ist eine Erweiterung des Domain Name Systems um kryptographische Signaturen. Somit werden bestehende DNS Records signiert. Dadurch kann man mit Hilfe der zugehörigen Signatur feststellen, ob ein DNS Record tatsächlich auch von einem für diese Domain authorativen DNS Server stammt, oder ggf. manipuliert wurde.

Insbesondere in Verbindung mit DANE (DNS-based Authentication of Named Entities) sind weitere Möglichkeiten von DNSSEC ersichtlich. So kann ein Domain-Inhaber eigene TLS Zertifikate erstellen und ihre Validierung findet nun mittels DNSSEC statt, ohne einer Liste "vertrauenswürdiger" Zertifizierungsinstitute (CAs) blindes Vertrauen schenken zu müssen. Dadurch meidet man von Sicherheitsproblemen der CAs betroffen zu werden. So haben in der Vergangenheit einige damals als vertrauenswürdig geltenden CAs schonmal Zertifikate für fremde Domains ausgehändigt. Alleine von 2008 bis 2018 sind mindestens 20 Sicherheitsvorfälle bei 13 CAs bekannt, wobei nur einer von diesen erst 8 Jahre später aufgrund eines zweiten großen Sicherheitsvorfalls distrusted wurde. [1]

Verschlüsselter DNS

DNS over HTTPS (DoH)

DoH ist ähnlich wie DoT, wobei die Verbindung hier via HTTPS stattfindet. Also werden DNS Pakete in HTTP Paketen verpackt und via HTTPS (HTTP via SSL/TLS oder QUIC) übertragen. Dies ist insbesondere dann sinnvoll, wenn bspw. eine Regierung den Zugriff zu bestimmten Resourcen einschränkt und man unbemerkt verschlüsselte DNS Anfragen und Antworten erhalten, bzw. sind die Pakete hier nicht von HTTPS Paketen unterscheidbar.

DNS over TLS (DoT)

Bei DoT werden DNS Anfragen und Antworten über einen TLS-verschlüsselten Kanal übermittelt. So findet die Übertragung Dadurch wird gegen das Mitlauschen von DNS Anfragen bzw. Antworten sowie etwaige Manipulation der Pakete vom / zum DNS Server präventiv eingelenkt. DoT wird standardmäßig über Port 853 angeboten, während satndardmäßige DNS Verbindungen via Port 53 angeboten werden.

DNS over QUIC (DoQ)

Bei DoQ werden DNS Anfragen und Antworten analog zu DOT via QUIC übermittelt. Auch hier wird der Dienst standardmäßig über Port 853 angeboten. Weitere Details sind unter RFC 9250 zu finden.