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.

dig www.stefanux.de.

nslookup www.stefanux.de.

dig ipv6.google.com AAAA

dig -x 178.63.64.116

nslookup 178.63.64.116

dig -x 2a00:1450:4008:c00::68

• DNS-Server: IP/Hostname eines DNS-Servers
• XYZ = hostname.Domain.tld

• DNS-Probleme beheben
• Securing a DNS-Server
• Anlegen und Verwalten von DNS-Zonen
• 5 basic mistakes not to make in DNS
• Chaosradio Express 99 - Domain Name System

Die folgende Auflistung ist eine Auswahl.

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

• hetzner DNS
• inwx
• autodns
• Afilias
• Proteus Cloud services
• VeriSign Managed DNS Service
• ultradns
• Nominum
• Dyn Inc.

• Bind
• PowerDNS
• NSD: Name Server Daemon
• dnsmasq: Eine einfache Lösung die lokale Einträge in die Hosts-Datei berücksichtigt und ansonsten andere DNS-Server befragt

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
• xpertdns
• diverse andere kleine und große Anbieter wie z.B. in dieser Übersicht aufgelist.

• GnuDIP
• MintDNS (kommerziell)
• Powerdns - Create your own Dynamic DNS Service using PowerDNS and MySQL
• …?

• Clients sind auch in vielen Routern enthalten haben aber meist nur eine kleine Auswahl von Dyndns-Anbietern
• Linux: ddclient, … (siehe auch: DynamicDNS)
• Windows: DynDNServ, Update-Client von DynDNS, …
• Mac: DynDNS Updater for Mac, …

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 ³⁾ 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

dig erzeugt Warnungen, bei bind ist das extra Aufwand, powerdns recursive kommt damit klar (wenn es forwarded), trotzdem nicht benutzen: RFC6762.

WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS

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.

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

• Cache-Poisoning-Gefahr heizt DNSSEC-Debatte an
• DNSSEC-Tools
• DNSSEC Deployment Initiative: Links to Software

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.

• Google DNS DoT
• Quad9 DoT

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.)

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