| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
| netzwerke:dns [2021/08/09 08:01] – [managed DNS-Services] st | netzwerke:dns [2025/01/05 00:15] (aktuell) – [DoT testen] st |
|---|
| ^ forward-lookup | Auflösung von Namen in Adressen: <code bash>dig www.stefanux.de.</code> (veraltet auf [[linux:Linux]] aber bei [[windows:Windows]] vorinstalliert: <code>nslookup www.stefanux.de.</code> | <code bash>dig ipv6.google.com AAAA</code> | | ^ forward-lookup | Auflösung von Namen in Adressen: <code bash>dig www.stefanux.de.</code> (veraltet auf [[linux:Linux]] aber bei [[windows:Windows]] vorinstalliert: <code>nslookup www.stefanux.de.</code> | <code bash>dig ipv6.google.com AAAA</code> | |
| ^ reverse-lookup | Auflösung von Adressen in Namen: <code bash>dig -x 178.63.64.116</code> veraltet bzw. bei [[windows:Windows]]: <code>nslookup 178.63.64.116</code> | <code bash>dig -x 2a00:1450:4008:c00::68</code> | | ^ reverse-lookup | Auflösung von Adressen in Namen: <code bash>dig -x 178.63.64.116</code> veraltet bzw. bei [[windows:Windows]]: <code>nslookup 178.63.64.116</code> | <code bash>dig -x 2a00:1450:4008:c00::68</code> | |
| | ^ Anfragen an einen rekursiven DNS-Resolver | Diagnose auf einem DNS-Server (ohne Antworten von Root-DNS-Servern etc.): ($interface, z.B. eth0, und $IP, z.B. 1.2.3.4, müssen geändert werden): ''tcpdump -i $interface -q udp port 53 and dst $IP and not src port 53'' || |
| |
| |
| * [[http://cre.fm/cre099-domain-name-system|Chaosradio Express 99 - Domain Name System]] | * [[http://cre.fm/cre099-domain-name-system|Chaosradio Express 99 - Domain Name System]] |
| |
| | ===== Öffentliche Rekursive DNS Server ===== |
| | |
| | Die folgende Auflistung ist eine Auswahl. |
| |
| | ^ Dienst ^ Standort ^ Methoden ^ EDNS Client Subnet ((client IP durchreichen für geo-located Antworten)) ^ v4 ^ v6 ^ DoT ^ DoH ^ Filterung ^ Datenschutz ^ Ratelimit (queries pro IP und Sekunde) ^ |
| | | Google DNS | | UDP53, DoT, [[https://developers.google.com/speed/public-dns/docs/doh|DoH]] | | 8.8.8.8, 8.8.4.4 | 2001:4860:4860::8888, 2001:4860:4860::8844 | dns.google | ? | Nein | ? | [[https://developers.google.com/speed/public-dns/docs/isp#alternative|1500]] | |
| | | Cloudflare | | UDP53, DoT, DoH | | 1.1.1.1, 1.0.0.1 | 2606:4700:4700::1111, 2606:4700:4700::1001 | one.one.one.one, 1dot1dot1dot1.cloudflare-dns.com | ? | Ja, je nach Dienst (Blocklist) | ? | ? | |
| | | [[https://www.quad9.net/de/support/faq/|Quad9]] | | UDP53 | Ja, 9.9.9.11, 149.112.112.11 bzw. 2620:fe::11, 2620:fe::fe:11 | 9.9.9.9, 149.112.112.112 | 2620:fe::fe, 2620:fe::9 | ? | ? | Nein | ? | ? | |
| | | Foebud | DE (Hetzner) | UDP53, DoT (dns3.digitalcourage.de) | Nein | 5.9.164.112, 46.182.19.48 (ausgelastet, kein DoT) | 2a01:4f8:251:554::2, 2a02:2970:1002::18 | dns3.digitalcourage.de | - | Nein | Ja | 50 | |
| | | Stefanux | DE (Hetzner) bzw. DE (Strato) | UDP53, DoT | Nein | 162.55.248.253, 212.132.117.15 | 2a01:4f8:bb:1353::53, 2a01:239:343:ee00::1 | dns.stefanux.net, dns2.stefanux.net | - | Ja: Adware-Liste (diese Treffer werden mit "0.0.0.0" bzw. "::" beantwortet), ansonsten keine | Ja | 100 (burst bis 10s) | |
| ==== managed DNS-Services ==== | ==== managed DNS-Services ==== |
| |
| siehe auch: **[[https://www.heise.de/ct/artikel/Hoster-und-Registrare-mit-DNSSEC-Diensten-2643530.html|Hoster und Registrare mit DNSSEC-Diensten]]** | siehe auch: **[[https://www.heise.de/ct/artikel/Hoster-und-Registrare-mit-DNSSEC-Diensten-2643530.html|Hoster und Registrare mit DNSSEC-Diensten]]** |
| |
| | * [[server:hetzner]] DNS |
| * **[[inwx]]** | * **[[inwx]]** |
| * [[https://cloud.autodns.com/login|autodns]] | * [[https://cloud.autodns.com/login|autodns]] |
| * inviduelle Hygenegründe ("was nicht öffentlich routebar ist, soll auch nicht im public dns sein") | * 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. | * 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!) | * **DNS-Rebind-Schutzmaßnahmen** brauchen dafür Ausnahmen ((z.B. Fritz-Boxen: Heimnetz -> Netzwerk -> Netzwerkeinstellungen -> weitere Einstellungen -> Hostnamen-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) | * 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 | * Rückwärtsauflösung privater Adressen ist nur intern möglich |
| |
| | ==== .local vermeiden ==== |
| | |
| | dig erzeugt Warnungen, bei bind ist das extra Aufwand, powerdns recursive kommt damit klar (wenn es forwarded), trotzdem nicht benutzen: [[https://datatracker.ietf.org/doc/html/rfc6762|RFC6762]]. |
| | <code> |
| | WARNING: .local is reserved for Multicast DNS |
| | ;; You are currently testing what happens when an mDNS query is leaked to DNS |
| | </code> |
| ==== Zonen ==== | ==== Zonen ==== |
| Bei DNS bezeichnet [[wpde>Zone (DNS)|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. | Bei DNS bezeichnet [[wpde>Zone (DNS)|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. |
| |
| |
| ===== DNSSEC ===== | ===== Sicherungsmaßnahmen bei DNS ===== |
| FIXME | |
| Gegen Angriffe wie [[security:Angriffsmethoden und Gegenmaßnahmen#dns-poisoning|DNS-poisoning]] hilft [[wpde>DNSSEC]]. | 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 |
| | |
| | ==== DNSSEC (Signierung) ==== |
| | |
| | Gegen Angriffe wie [[security:Angriffsmethoden und Gegenmaßnahmen#dns-poisoning|DNS-poisoning]] hilft [[wpde>DNSSEC]]. Es führt eine Signaturkette ein, das die DNS-Antworten auf Gültigkeit verifiziert, verhindert aber kein mitlesen der Daten. |
| | |
| | siehe auch: **[[https://www.heise.de/ct/artikel/Hoster-und-Registrare-mit-DNSSEC-Diensten-2643530.html|Hoster und Registrare mit DNSSEC-Diensten]]** |
| |
| * [[http://www.heise.de/newsticker/Cache-Poisoning-Gefahr-heizt-DNSSEC-Debatte-an--/meldung/112980/from/rss09|Cache-Poisoning-Gefahr heizt DNSSEC-Debatte an]] | * [[http://www.heise.de/newsticker/Cache-Poisoning-Gefahr-heizt-DNSSEC-Debatte-an--/meldung/112980/from/rss09|Cache-Poisoning-Gefahr heizt DNSSEC-Debatte an]] |
| * [[http://www.dnssec-tools.org/|DNSSEC-Tools]] | * [[http://www.dnssec-tools.org/|DNSSEC-Tools]] |
| * [[http://www.dnssec-deployment.org/tracker/|DNSSEC Deployment Initiative: Links to Software]] | * [[http://www.dnssec-deployment.org/tracker/|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. | 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. |
| </file> | </file> |
| |
| | ===== DnsSec testen ===== |
| | |
| | * 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) ==== |
| | |
| | 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 [[software:stunnel4|stunnel]]) aufgerüstet werden. |
| | |
| | * [[https://developers.google.com/speed/public-dns/docs/dns-over-tls|Google DNS DoT]] |
| | * [[https://www.quad9.net/de/service/service-addresses-and-features|Quad9 DoT]] |
| | === DoT testen === |
| | |
| | Test via Kommandozeile (kdig ist Teil der "knot-dnsutils"): |
| | |
| | Beispiel: Abfrage der IP 8.8.4.4 (mit Hostname "dns.google.com" für den das Zertifikat gültig sein muss) nach "www.google.com": |
| | |
| | <code bash>kdig -d @8.8.4.4 +tls-ca +tls-host=dns.google.com www.google.com</code> |
| | |
| | Erfolg: |
| | <file>;; DEBUG: TLS, The certificate is trusted.</file> |
| | |
| | Fehler (Beispiel): |
| | <file> |
| | ;; 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.) |
| | </file> |
| | |
| | |
| | === systemd-resolved DoT config === |
| | |
| | <file> |
| | 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 |
| | </file> |
| | |
| | ==== DNS over HTTP (DoH) ==== |
| | |
| | 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. |
| | |
| | <code bash> |
| | # 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 . |
| | </code> |
| | |
| | ==== DNScrypt ==== |
| |
| | DNSCrypt (basiert auf DNScurve von D.J. Bernstein, von OpenDNS betreut) |
| ===== Hosts-Datei ===== | ===== Hosts-Datei ===== |
| |