netzwerke:dns

Dies ist eine alte Version des Dokuments!


DNS

Das Domain Name System (DNS) ist einer der wichtigsten Dienste im Netzwerk/Internet. Seine Hauptaufgabe ist die Umsetzung von „Internetadressen“ in die zugehörige IP-Adresse. DNS-Anfragen sind vom Client nicht Verifizierbar und außerdem angreifbar (DNS-Poisoning. Lösung: DNSSEC einsetzen.

Wenn man lokalen DNS-Servern nicht traut (DNS-Poisoning) kann man auch öffentliche DNS-Server wie OpenDNS (IPs: 208.67.222.222 und 208.67.220.220) einsetzen.

Per DNS lässt sich auch der Proxy mitteilen (per Web Proxy Autodiscovery Protocol (WPAD), siehe ValentinHaenel: Web Proxy Automatic Discovery.

Abfragetypen
interative Abfrage Der DNS-Server gibt die bestmögliche Antwort zurück, die er ohne die Hilfe anderer Server bereitstellen kann
rekursive Abfrage Der DNS-Server gibt eine vollständige Antwort auf die Abfrage und nicht nur einen Verweis auf einen anderen Server zurück
Lookuptypen
Typ Ipv4 Ipv6
forward-lookup Auflösung von Namen in Adressen:
dig www.stefanux.de.

(veraltet auf Linux aber bei Windows vorinstalliert:

nslookup www.stefanux.de.
dig ipv6.google.com AAAA
reverse-lookup Auflösung von Adressen in Namen:
dig -x 178.63.64.116

veraltet bzw. bei Windows:

nslookup 178.63.64.116
dig -x 2a00:1450:4008:c00::68
Record Windows cmd Win PS v4 1) Linux (host) Linux (dig) Mac
A nslookup XYZ Resolve-DnsName -Name XYZ host XYZ dig XYZ host XYZ
AAAA nslookup -query=AAAA XYZ Resolve-DnsName -Name XYZ host -t aaaa XYZ dig AAAA XYZ
reverse lookup nslookup IP oder nslookup -type=ptr IP host IP dig -x IP
MX nslookup -query=MX XYZ host -t mx XYZ dig mx XYZ
NS (authoritative nameservers) nslookup -query=NS XYZ host -t ns XYZ dig ns XYZ host -t ns XYZ
TXT nslookup -query=TXT XYZ host -t txt XYZ dig txt XYZ
SRV nslookup -query=SRV XYZ host -t srv XYZ dig srv XYZ
bestimmten Server befragen nslookup $Abfrage DNS-Server Resolve-DnsName $Abfrage -Server DNS-Server host $Abfrage @DNS-Server dig $Abfrage @DNS-Server
alle Records zurückliefern nslookup -query=any XYZ host -t any XYZ dig any XYZ
  • DNS-Server: IP/Hostname eines DNS-Servers
  • XYZ = hostname.Domain.tld

Es gibt mittlerweise eine Reihe von Anbietern die DNS-Server betreiben und Kunden hohe Verfügbarkeit, einfache Bedienung und Features wie DNSSec bieten.

siehe auch: Hoster und Registrare mit DNSSEC-Diensten

:!: Bei selbst betreuten DNS-Servern sollte man Zonentransfers auf authorisierte Hosts beschränken.

Für den Betrieb von Serverdiensten ist in den meisten Fällen ein DNS-Name zugewiesen, der auf eine feste IP zeigt. Wenn keine feste IP möglich ist, z. B. bei einem Einwahlzugang, und sich die dynamische IP somit in (un)regelmäßigen ändert, muss man auf einen DynDNS-Anbieter zurückgreifen.

Üblicherweise wird durch eine Client-Software die neue (z.B durch Zwangstrennung geänderte) IP-Adresse gemeldet, so dass der Dienst schnell wieder unter der neuen IP-Adresse zur Verfügung steht.

  • no-ip.com z.Zt. 3 Hosts kostenlos möglich
  • dyndns - es scheint keine kostenlosen Accounts mehr zu geben bzw. man wird mehr und weniger genötigt einen Bezahltarif zu nehmen
  • diverse andere kleine und große Anbieter wie z.B. in dieser Übersicht aufgelist.

Neue Einträge im DNS-Server verbreiten sich durch caches nicht sofort im ganze Internet.

Negative Antworten (DNS-Eintrag zum angefragten Host existiert nicht =negative Caching Zeit) werden ebenfalls von anderen Nameservern zwischengespeichert. Hierbei ist die TTL aus dem SOA-record der Zone verantwortlich. Diese setzt normalerweise der Provider, wenn diese negative Caching Zeit sehr hoch ist (im Vergleich zur TTL einzelner vorhandener Einträge) ist das für dyndns/ddns-Anwendungen ein Problem. In diesem Fall kann mit wildcard-Einträgen (z.B. auf die IP des Nameservers) diese TTL umgangen werden.

dig GibtsNicht.example.com
; <<>> DiG 9.8.1-P1 <<>> GibtsNicht.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59706
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;xGibtsNicht.example.com.		IN	A

;; AUTHORITY SECTION:
example.com.		1800	IN	SOA	ns.namespace4you.de. hostmaster.example.com. 1384198447 16384 2048 1048576 2560

Aus der Antwort ergibt sich (Bedeutung der Felder des SOA-Records):

  1. Die Seriennr. der letzten Änderung: 1384198447
  2. Refresh Time: 16384
  3. Retry Time: 2048
  4. Expire Time: 1048576
  5. negative Caching Zeit: 2560

http://www.dnswatch.info/ http://zonecheck.denic.de/zonecheck/

Wikipedia - Kategorie:Domain_Name_System

Typ Bedeutung Eintrag
SOA Start Of Authority Verschiedene Parameter für die Zone, die der Nameserver verwalten soll. Bedeutung der Felder des SOA-Records.
A Address Die Adresse eines Internet Hosts (Verknüpfung einer Domain mit einer bestimmten IP-Adresse).
AAAA-Record IPv6 pendant zum A-Record unter IPv4.
MX Mail Exchange Die Priorität und Name des Mailservers der Domain. Abfrage mit dig -t mx DOMAIN :!: Achtung: Ein MX-Record darf auschließlich „canonical names“ (d. h. einen Hostnamen/FQHN der einen A record hat) enthalten.
NS Name Server Name eines Nameservers der Domain (auch: Weiterleitung der Nameserveranfragen an einen anderen Nameserver).
CNAME Canonical Name Domainname eines Rechners (Aliasfunktion: Verknüpfung einer Subdomain mit einer anderen Subdomain).
PTR Pointer Alias für eine numerische IP-Adresse (benutzt für Reverse-lookup)
HINFO Host Information ASCII Beschreibung des Hosts (CPU, OS, …)
TXT Text - Nicht verwertbarer Text - Kommentar
SPF-Record Eintrag für das „Sender Policy Framework“ (Anti-Spam-Modell).
SRV-Records Einträge für VoIP

* SOA-Resource-Record: Autoritätsursprung

:!: falsche DNS-Konfiguration (localhost. IN A 127.0.0.1 ohne den Punkt nach localhost) erlaubt Angriffe Common DNS Misconfiguration can Lead to "same Site" Scripting

DNS muss als öffentlichen Datenbank angesehen werden, zwar sind ANY-Abfragen nicht komplett und

Gründe für private DNS-Adressen im DNS:

  • Robustheit:
    • bei Abbruch der Verbindung cacht das Betriebssystem/der resolver negative Antworten aus dem public DNS. Wenn public ↔ private DNS deckungsgleich dann kann das nicht passieren
    • Split-DNS-Probleme sind aufwendiger zu finden da Antwort von der Zugangsart abhängig und monitoring schwerer möglich
  • Wartungsarm:
    • keine internen DNS-Server (doppelt ausgelegt) nötig
    • keine (manuellen) Abgleiche von externen und internen Zonen nötig. Standardproblem: Anwendung soll öffentlich/Extern aus speziellen Netzen - ohne dns-forwarder - zugreifbar sein → Record im public DNS anlegen.
  • dnssec Zonensignierung / DoT externer Server kann genutzt werden

Gründe gegen private IPs im DNS:

  • inviduelle Hygenegründe („was nicht öffentlich routebar ist, soll auch nicht im public dns sein“)
  • es besteht ein „Security-by-obscurity“-Vorteil interne IPs nicht zu veröffentlichen (diese sind jedoch aufgrund des begrenzten ipv4-Raumes privater Adressen und nach Schema, z.B. vom Gateway aus hoch bzw. runterzählen, leicht zu erraten) DNS-Records sind als öffentlich anzusehen, auch wenn nicht alle Records mit „any“-Abfrage sichtbar sind, bzw. niemand unauthorisiertes Zonentransfers machen darf.
  • DNS-Rebind-Schutzmaßnahmen brauchen dafür Ausnahmen (z.B. Fritz-Boxen) Hintergrund: Rebind-Attacken fälschen lokale (unverschlüsselte) Anfragen, diese scheitern allerdings bei validierbaren TLS-Zertifikaten, bei unsicherer Konfiguration des Applikationsservers (selg-signed Zertifikat oder Abruf über unverschlüsselte Wege) kann dies jedoch ein Risiko darstellen (das allerdings unabhängig von DNS-Anforderungen behoben werden sollte!)
  • Szenarien in denen Split-DNS zwingend nötig ist (z.B. unterschiedliche IPs auf mehreren privaten Uplinks wobei der FQDN für eine Applikation überall gleich sein muss)
  • Rückwärtsauflösung privater Adressen ist nur intern möglich

Bei DNS bezeichnet Zone den Teil des Domänenbaums, für die ein Nameserver (im Folgenden auch NS) zuständig ist und deshalb die offiziellen Daten kennt. Eine Zone wird durch einen Primary Nameserver verwaltet. Zur Erhöhung der Verfügbarkeit bei Server-Ausfällen ist es üblich, eine Zone auf einen oder mehrere Secondary Nameserver zu spiegeln.

Zonentypen
primäre Zone lese und schreibbar
sekundäre Zone liest/spiegelt die Daten der primären Zone zur Ausfallsicherheit
Windows-spezifisch in Active-Directory integriert

Eine Domäne umfasst den gesamten untergeordneten DNS Namensraum. Der Begriff Domäne wird auch verwendet, wenn man sich auf den Inhalt (Welche Namen enthält eine Domäne?) oder die Eigentumsrechte (Für wen ist eine Domäne registriert?) bezieht.

Eine Domäne kann in mehrere Zonen aufgeteilt werden, indem man die Zuständigkeit für Subdomains delegiert. Von einer Zone spricht man auch, wenn man die physische Realisierung meint – also auf welchem Server und in welcher Zonendatei liegen die DNS-Einträge.

Zonentransfer bezeichnet beim Domain Name System (DNS) die Übertragung von Zonen auf einen anderen Server.

Da ein DNS-Ausfall für ein Unternehmen meist gravierende Folgen hat, werden die DNS-Daten – also die Zonendateien – fast ausnahmslos identisch auf mehreren Nameservern gehalten. Bei Änderungen muss sichergestellt sein, dass alle Server den gleichen Datenbestand besitzen. Die Synchronisation zwischen den beteiligten Servern wird durch den Zonentransfer realisiert. Der Zonentransfer beinhaltet nicht nur das bloße Übertragen von Dateien oder Sätzen, sondern auch das Erkennen von Abweichungen in den Datenbeständen der beteiligten Server.

Er kann mit dem Befehl host -l durchgeführt werden.

Eine Zonendatei ist Teil der Konfiguration eines Nameserverdienstes (z.B. BIND) für das Domain Name System. Sie besteht aus einer Liste von Resource Records (RR). Eine Zonendatei beschreibt eine Zone vollständig. Es muss genau ein SOA Resource Record und mindestens ein NS Resource Record vorhanden sein. Der SOA-RR befindet sich meist am Anfang einer Zonendatei.

Das originale DNS ist (leider) standardmäßig unverschlüsselt und unsigniert, die Antworten können also auf dem Weg mitgelesen und verändert werden und die Echtheit der Antwort wird nicht garantiert.

Dagegen existieren im wesentlichen die folgenden drei Lösungen

Gegen Angriffe wie DNS-poisoning hilft DNSSEC. Es führt eine Signaturkette ein, das die DNS-Antworten auf Gültigkeit verifiziert, verhindert aber kein mitlesen der Daten.

siehe auch: Hoster und Registrare mit DNSSEC-Diensten

DNS-Antworten via DNSSEC enthalten sowohl signierte Daten als auch Schlüssel, deshalb können Antworten mehrere KB groß werden. Einige Firewalls und DNS-Server begrenzen jedoch die maximale Paketgröße, das gibt dann Probleme mit DNSSEC.

Das OARC betreibt einen Testdienst, der allgemeine Aufruf lautet:

dig +short rs.dns-oarc.net @DNS-Server txt

Beispiel: Google DNS abfragen:

dig +short rs.dns-oarc.net @8.8.4.4 txt

Die Ausgabe zeigt das Google DNS ein zu kleines Limit für DNSSEC hat:

rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
"74.125.76.80 DNS reply size limit is at least 490"
"74.125.76.80 lacks EDNS, defaults to 512"
"Tested at 2010-11-12 16:40:33 UTC"

Eine ausreichend dimensioniertes Limit sieht so aus (statt „a.b.c.d“ stünde hier die IP des befragten DNS-Servers):

rst.x3827.rs.dns-oarc.net.
rst.x3837.x3827.rs.dns-oarc.net.
rst.x3843.x3837.x3827.rs.dns-oarc.net.
"a.b.c.d DNS reply size limit is at least 3843"
"Tested at 2010-11-12 16:41:52 UTC"
"a.b.c.d sent EDNS buffer size 4096"
  • negativ-Test (darf kein Ergebnis liefern): dig +short sigfail.verteiltesysteme.net @mein.DNS.server
  • positiv-Test (liefert IP zurück): dig +short sigok.verteiltesysteme.net @mein.DNS.server

DNS over TLS (DoT) führt einen zusätzlichen TLS-Schutz ein (Verschlüsselung). Grundlage ist RFC 7858, TLS-verschlüsselte TCP Kommunikation, Port: 853.

DoT wird von allen wichtigen DNS-Servern unterstützt (auch von Routern wie der Fritz-box), unverschlüsselte DNS-Server können durch einen TLS-wrapper (wie stunnel) aufgerüstet werden.

DoT testen

Test via Kommandozeile (kdig ist Teil der „knot-dnsutils“):

Beispiel: dns.google.com (IP: 8.8.4.4) mit einer Abfrage nach „www.google.com“:

kdig -d @8.8.4.4 +tls-ca +tls-host=dns.google.com www.google.com

Erfolg:

;; DEBUG: TLS, The certificate is trusted.

Fehler (Beispiel):

;; DEBUG: TLS, The certificate is NOT trusted. The name in the certificate does not match the expected. 
;; WARNING: TLS, handshake failed (Error in the certificate.)

systemd-resolved DoT config

DNS=8.8.4.4#dns.google
DNS=9.9.9.9#dns.quad9.net
DNS=2001:4860:4860::8844#dns.google
DNS=2620:fe::9#dns.quad9.net
DNSOverTLS=yes

DNS over HTTP (DoH) führt einen zusätzlichen TLS-Schutz ein (Verschlüsselung), dafür wird ein TCP-Handshake durchgeführt und das HTTP-Protokoll benutzt.

# json-Abfrage für "example.com" (erfordert jq)
curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq .

DNSCrypt (basiert auf DNScurve von D.J. Bernstein, von OpenDNS betreut)

Muss ein Hostname in eine IP-Adresse (oder umgekehrt) übersetzt (oder „aufgelöst“) werden, so wird bei Betriebssystemen zuerst versucht, die Namensauflösung lokal anhand der in der Hosts-Datei gespeicherten Zuordnungen durchzuführen, bevor andere Methoden (DNS, WINS, usw.) versucht werden. Bei unixartigen Systemen wird die Reihenfolge durch Einträge in der Datei /etc/nsswitch.conf festgelegt.

Vor der Einführung des Domain Name Systems (DNS) wurden Rechnernamen im Internet über diese Hosts-Dateien aufgelöst. Die Verteilung und Aktualisierung dieser Dateien war allerdings ein logistisches Problem. Deshalb werden Hosts-Dateien im Internet sowie in größeren Netzwerken heutzutage selten bis nicht mehr verwendet. Auch Loopback-Adressen benötigen heutzutage keinen Eintrag in der Hosts-Datei.

Anmerkung: Dieser Abschnitt basiert auf einem Wikipedia-Artikel.

  • Windows NT/2000/XP/2003/Vista/7 32 & 64 Bit: %SystemRoot%\system32\drivers\etc\hosts (Standardkonfiguration, der Verweis auf das diese Datei enthaltende Verzeichnis ist in der Windows-Registrierungsdatenbank unter \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DataBasePath gespeichert.)
  • Windows 95/98/Me: %WinDir%\hosts
  • Windows Mobile: pro Host ein Schlüssel in der Registrierung unter \HKEY_LOCAL_MACHINE\Comm\Tcpip\Hosts
  • Unix, Linux: /etc/hosts
  • Mac OS X: /etc/hosts bzw. /private/etc/hosts (/etc ist eine Verknüpfung mit /private/etc)
  • iOS und andere BSD-basierende Betriebssysteme: /private/etc/hosts
  • OS/2 und eComStation: „bootdrive“:\mptn\etc\hosts
  • Series 60 1st und 2nd Edition: C:\system\data\hosts
  • Series 60 3rd Edition: C:\private\10000882\hosts (Zugriff wegen Platform Security nicht ohne weiteres möglich.)
  • Android: /system/etc/hosts

1)
Win 8.1+ / Server 2012+