| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
| netzwerke:dns [2022/12/05 23:47] – [DNS] st | netzwerke:dns [2025/01/05 00:15] (aktuell) – [DoT testen] st |
|---|
| | [[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 | ? | ? | | | [[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 | | | 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. FR (OVH) | UDP53, DoT | Nein | 162.55.248.253, 162.19.205.195 | 2a01:4f8:bb:1353::53, 2001:41d0:701:1100::6ce7 | 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) | | | 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 ==== |
| |
| * 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. |
| Test via Kommandozeile (kdig ist Teil der "knot-dnsutils"): | 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": | 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> | <code bash>kdig -d @8.8.4.4 +tls-ca +tls-host=dns.google.com www.google.com</code> |