Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- netzwerke:dns [2022/03/29 18:31] – [DNS over TLS (DoT)] st
+++ netzwerke:dns [2025/01/05 00:15] (aktuell) – [DoT testen] st
@@ Zeile 15: / Zeile 15: @@
 ^ 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> |
+^ 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'' ||
@@ Zeile 42: / Zeile 42: @@
   * [[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 ====
@@ Zeile 49: / Zeile 58: @@
 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]]**
   * [[https://cloud.autodns.com/login|autodns]]
@@ Zeile 164: / Zeile 174: @@
   * 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!)
+  * **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)
   * 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 ====
 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.
@@ Zeile 265: / Zeile 282: @@
 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>