im Sinne der Verringerung der Abhängigkeit von amerikanischen Services kann man statt google-DNS servers auch einen EU Service nutzen

https://www.joindns4.eu/for-public



Ein DNS-Server (Domain Name System Server) ist wie das Telefonbuch des Internets.

Kurz erklärt:
Wenn du z. B. openai.com in deinen Browser eingibst, weiß dein Computer nicht automatisch, wo das ist.
Der DNS-Server übersetzt diesen Namen (openai.com) in eine IP-Adresse (z. B. 104.22.3.123), die Computer verstehen.
Dann kann dein Gerät eine Verbindung zu diesem Server aufbauen.
Ohne DNS:
Du müsstest dir jede IP-Adresse von Webseiten merken – was extrem unpraktisch wäre.

Nun muss ich mal nachfragen. Ich nutze tatsächlich Tailscale und bin somit stets über mein Netz mit dem Internet verbunden. Nur als Rückoption habe ich NextDNS auf dem iPhone.
Zuhause nutze ich Pi-hole, aber ohne einen Unbound-Resolver. Stattdessen ist der Upstream-DNS-Server von Quad9. Ist es nicht immer der gleiche Anbieter (und damit so zentral/dezentral wie Quad9 nunmal ist), egal ob ich per 9.9.9.9 oder per DoH zugreife?

Doch ist es. Und danke für den Post, ich glaube ich verstehe langsam, an welcher Stelle Peter Eckel und ich aneinander vorbeireden.

In seiner Argumentation geht er von einem Nutzer aus, der grundsätzlich per VPN über sein eigenes Netzwerk (und seinen eigenen DNS-Server) mit der Welt kommuniziert. Der jeweilige Provider wird ausschließlich genutzt um eine VPN-Verbindung herzustellen. In dieser Welt hat DoX natürlich keinen Sinn (schadet aber auch nicht sonderlich - bis auf den erhöhten Rechenaufwand).

In meiner Argumentation gehe ich von einem Nutzer aus, der weder in der Lage ist das Eine noch das Andere bei sich einzurichten (insbesondere auch so, dass keine Leaks bleiben) und daher einfach ohnehin die Dienste des jeweiligen Providers nutzt (bzw. eben allenfalls Anbieter wie DNS4EU oder NextDNS). In dieser Welt hat DoX durchaus einen Sinn, da eben gar kein VPN genutzt wird und der Nutzer ja auch keinen bis wenig Einfluss auf die Fähigkeiten des DNS-Servers hat (wie eben z.B. DNSSEC).

Klingt erstmal wie ein sinnvolles Setup.
Genau. Ob Du jetzt einen zentralen DNS-Server wie 9.9.9.9 per DNS oder die gleiche Infrastruktur per DoH ansprichst, bleibt sich gleich (bis auf die Verschlüsselung bei DoH). Vorteil bei DoH in diesem Fall: Dein Provider sieht die DNS-Queries nicht. Dafür sieht er alles andere.

Wenn Du dem Pi-Hole noch einen Unbound spendierst, ist Quad9 auch aus dem Spiel und Deine DNS-Queries finden dezentral statt. Beim Aufsetzen nicht "qname-minimisation" vergessen (aber nicht "-strict"!):

Ohne diese Einstellung bekommt jeder Server, der rekursiv nach einem Namen gefragt wird, den kompletten Namen geliefert, auch wenn er für die betreffende Zone gar nicht autoritativ ist. Das leakt unnötig Information und kann mit "qname-minimisation" abgeschaltet werden.

Danke für die Erläuterung und den Tipp. Nachdem nun beide Pi-holes bei mir IPv6 verstehen, kann ich als nächstes Projekt mal eine Pi-hole mit Unbound verkuppeln

Exakt!
Und genau daß DoX in dieser Konstellation sinnvoll ist bestreite ich.

Wir waren ja im Beispiel von "nicht vetrauenswürdiges WLAN" als Umgebung ausgegangen. "Nicht vertrauenswüridger Provider" ist nochmal eine andere Nummer, aber prinzipiell ähnlich. In diesem WLAN ist es mit einigem Aufwand (nämlich durch Mitlesen der übertragenen Daten) möglich, die DNS-Queries einzusehen.

Mit weniger Aufwand (nämlich durch einfaches Lesen der Router- bzw. Firewall-Logs) kann man aber ein Profil der besuchten Server bekommen, was ziemlich deckungsgleiche Informationen liefert (abgesehen von SNI bzw. Datenmengen auf der einen bzw. anderen Seite).

DoX hilft nur gegen das erste Problem, das zweite bleibt aber ohne VPN ungelöst und damit verändert DoX die Sachlage nicht entscheidend zum Guten, es ist also nicht viel damit gewonnen.

Auf der anderen Seite stehen die beschriebenen Nachteile von DoX, insbesondere wenn es fremdgehostet ist. Das ist einfach eine Abwägung der Vor- und Nachteile, die für DoX nicht so gut ausgeht.

Und deshalb meine Empfehlung, von DoX Abstand zu nehmen.

Interessanter Thread - durch und durch. Ich nutze eine APU2C4 nach meinem Kabelmodem mit der pfSense Firewall. Nach der Firewall kommt ein Managed Switch und danach WLAN Router und Mesh Verstärker für die kabellosen Nutzer. Alle Klienten im Netzwerk mit Durchsatz-Anforderungen werden von einem WireGuard VPN gezogen (pull routes von IP-Alias-Listen). Alle anderen von einer OpenVPN Verbindung zu einem anderen Endpoint in der Welt auf der gleichen Firewall. Nur wenige Klienten ohne Browser/eMail bsp.weise wie Playstation, TV, HomePod kommen in den Genuss direkt verbunden zu sein. Den in der Firewall implementierten Unbound-Resolver nutze ich ebenfalls. Hier kann man auch festlegen, welche statischen IPs im LAN/WLAN vom Resolver genutzt werden müssen. Leaks oder Kill Switches sind denkbar simpel einzurichten. Klar leidet die Latenz bei VPN. Aber wenn die Verbindung einmal steht geht es. Falls es jemanden interessiert, die APU liefert bei WireGuard einen maximalen Durchsatz von ca. 35MB/s wohingegen OpenVPN bei max. 12MB/s liegt.

Da ich beruflich bedingt immer mal woanders lebe, hatte ich immer die gleichen Beobachtungen. In England bei Virgin und in der USA bei Spectrum waren die hauseigenen DNS Server meiner Einschätzung nach überhaupt nicht zu empfehlen, denn diese filterten schon alleine alle Suchergebnisse zu VPN Hostern, Lösungen etc. immer fein raus. Nichts zu sehen bei einer Google Suche. Falls ich abschweifte - man verzeihe mir.

Deine Erfahrungen mit OpenVPN vs. Wireguard-Performance kann ich bestätigen - auch verglichen mit IPsec ist OpenVPN eher auf der gemächlichen Seite. Ein anderes Problem bei OpenVPN sind die Reconnects bei Netzwechsel, die immer mit spürbaren Aussetzern verbunden sind. Auch deswegen habe ich OpenVPN komplett entsorgt.

Die APU-Boards sind in der Tat Gold wert. Ich habe mir einen LTE-Router auf einem gebaut, über den ich meine Backup-Leitung betreibe - die LTE-FritzBoxen sind an der Aufgabe gescheitert, weil auf denen IPv6 nicht sauber zum Laufen zu bringen war. Lange Geschichte. APU mit OpenWRT ging zügig und läuft fast zufriedenstellend, ich experimentiere aber gerade auf einem zweiten APU mit VyOS, weil mir die Upgrade-Arie bei OpenWRT zu fummelig ist. Irgendwie fehlt aber immer die Zeit.

Provider-DNS-Resolver sind meiner Erfahrung nach immer ziemlich bäh. Bei der Telekom ist es die tolle "Bedienhilfe", die man erstmal wegkonfigurieren muß (sie lenken Requests, die NXDOMAIN als Antwort bekommen, auf eine "Hilfeseite" um ... grausig!), bei Vodafone haben sie den DNS gleich komplett versaubeutelt (ich habe das Debugging irgendwann aufgegeben). Alle haben die Neigung, sich CUII zu beugen (einer inoffiziellen "Clearingstelle" der Content-Mafia), die auch gerne mal die falschen Domains sperren läßt. Muß man echt nicht haben.

Ich habe gestern Abend Pi-hole und Unbound als Synology-Container mit einem Portainer-Stack aufgesetzt. Durch macvlan haben Pi-hole und Unbound eigene IPs. Als Image nutze ich alpinelinux/unbound.
Unbound läuft und QNAME minimisation funktioniert.

Problem: DNSSEC funktioniert nicht. dig fail01.dnssec.works gibt NOERROR statt SERVFAIL zurück.
Was empfiehlt ihr? Unbound ohne DNSSEC? Oder Unbound mit Quad9 als Forward-Ziel?

Unbound mit DNSSEC natürlich

Ich glaube, derzeit stimmt irgendwas mit fail01.dnssec.works nicht. Ich habe hier definitiv DNSSEC-Validierung eingeschaltet, und bei mir kommt auch NOERROR ... sollte es natürlich nicht.

Versuche mal
(in der Annahme, daß Du den unbound auf localhost:5335 hören läßt, sonst entsprechend anpassen). Das funktioniert auch auf meinen unbound-Instanzen korrekt.

unbound mit Forward auf Quad9 kannst Du Dir sparen, da kannst Du dann auch gleich direkt Quad9 nehmen.

Ich habe Carsten mal angeschrieben. Da ist wirklich mit fail01.dnssec.works was faul.

Die Domain-Signatur ist kaputt:

Versuche mal
Das war der richtige Hinweis 👍🏻
dig +dnssec @192.168.1.35 sigok.ippacket.stream hat direkt die DNSSEC-Signatur bestätigt.
dig +dnssec @192.168.1.35 sigfail.ippacket.stream hat zum Time-out geführt. Das lag aber daran, dass ich aus der unbound.conf den Trust-Anchor entfernt hatte (weil DNSSEC scheinbar nicht funktionierte).
dig +dnssec @192.168.1.35 dnssec-failed.org lieferte das SERVFAIL.

Jetzt klappt alles. Danke!

Die Checks bei dnssec.works funktionieren jetzt auch wieder.

Ich muss gestehen, allzu viel verstehe ich in diesem Thread nicht, das Zitat steht stellvertretend für das Thema.
Hat vielleicht jemand einen Tip für mich für fachlich korrekte Literatur, gerne in Buchform, ungerne per Youtube, womit ich fundiert an das Thema Netzwerk herangeführt werde?

"Das Thema Netzwerk" ist ein ziemlich weites Feld. Eine "lies dieses Buch und Du verstehst das Thema"-Empfehlung kann es meines Erachtens nicht geben. Die von mir seinerzeit genutzte Literatur füllt mehrere Regale, und heute schaue ich kaum noch hinein, weil das meiste, was es dazu gibt, ziemlich veraltet ist und gute Fachliteratur bei den schellebigen IT-Themen kaum noch erscheint.

Ich kann als Grundstock nur jedem empfehlen, sich erst einmal in Linux einzuarbeiten. Das geht am besten mit einem eigenen System, auf dem man herumspielen und das man, wenn man es mal "kaputtkonfiguriert" hat. Ich benutze für so etwas Vagrant mit geeigeten "Boxen", die die Linux-Basisinstallation bereitstellen.

Ach so, und wenn Linux, dann meine ich "Linux auf der Kommandozeile". Grafische Oberflächen sind fein für die tägliche Arbeit, aber zum Verständnis der Grundlagen tragen sie nicht bei, da sie die Komplexität verbergen (das ist ihr Job). Unglücklicherweise besteht selbst unter Linux inzwischen die Tendenz, eigentlich einfache Dinge unnötig zu komplizieren, aber Linux kommt einem verständlichen Betriebssystem noch am nächsten. Vor ziemlich vielen Jahren habe ich mir die Grundlagen auf der Basis des Buches "Essential System Administration" von Æleen Frisch (O'Reilly) angeeignet - die "aktuelle" dritte Auflage ist von 2002. Ich habe die erste.

Aufbauend auf bzw. verwoben mit Linux ist einer der wichtigsten Schritte das Verständnis von TCP/IP. Das ist im Grunde nicht sooo wahnsinnig kompliziert, wird aber bei IPv4 immer übler, weil die Adressen längst alle vergeben sind und man mit esoterischen Mitteln (NAT, CGNAT und so weiter) versucht, mit dem Mangel zu leben. Das funktioniert zwar erstaunlicherweise immer noch, macht die Struktur von Netzwerken aber nicht unbedingt einfacher verständlich. Ich denke da an Firmen, in denen nach diversen Fusionen mindestens zehnmal das RFC1918-Netz "10.0.0.0/8" vorhanden ist, aber die Adressen in verschiedenen Firmenteilen nicht eindeutig sind. IPv6 hat diese Probleme alle nicht, aber die Leute erschrecken halt, wenn sie 128 Bit lange Adressen sehen und halten es dann für zu kompliziert (ist es nicht). Zumindest solltest Du verstehen, was ein Subnetz ist und wie Routing (BGP, (E)IGRP, OSPF etc. kannst Du erstmal auslassen) prinzipiell funktioniert. Das hilft schon mal sehr.

Wenn dann so etwas wie ein Grundverständnis des Systems und von TCP/IP da ist, kann man sich an die Kernfunktionalitäten des Internet heranarbeiten, von denen eine DNS ist. Ohne DNS geht buchstäblich gar nichts. Selbst wenn man noch irgendwo IP-Adressen eingeben kann, scheitert dieser Ansatz spätestens bei Webservern mit mehreren verschiedenen virtuellen Sites auf einem Server unter der gleichen IP-Adresse. Es gibt ein ganz brauchbares Werk im O'Reilly-Verlag von Cricket Liu, "DNS and BIND", das mir vor Jahren dabei geholfen hat, aber auch das ist schon ziemlich angestaubt und eine neue Auflage ist nicht in Sicht.

Wenn Du so lange durchgehalten hast, daß das alles keine Rätsel mehr sind (ich finde, es lohnt sich und macht Spaß, aber die Geschmäcker sind da vermutlich verschieden), kannst Du den Rest dann in aller Regel herleiten bzw. findest selbst die entsprechenden Ressourcen.

Das ist jetzt alles irgendwie unbefriedigend ... ich habe daher nochmal die Suchmaschine angeworfen und bin unter anderem bei folgenden Vorschlägen gelandet (ich kenne keines davon, aber zumindest von der Papierform her sehen sie ganz gut aus):

• Computer Networking: A Top-Down Approach by James Kurose and Keith Ross
• The Internet Book: Everything You Need to Know About Computer Networking and How the Internet Works by Douglas Comer
• Computer Networking: Beginners Guide to Network Fundamentals, Protocols & Enterprise Network Infrastructure
• Computer Networks And Internets by Douglas Comer
• Mastering TCP/IP: A Practical Guide to Network Protocols in the Digital Age

Auch "DNS und BIND" findet sich unter den ersten Suchergebnissen. Ich weiß nicht, ob ich da lachen oder weinen soll ... ja, das ist ein gutes Buch. Aber alles andere als aktuell, wie gesagt.

Ein anderes, auch nicht aktuelles Buch über DNS (aber dafür gratis), ist das folgende von Jan-Piet Mens: Die enthaltenen Grundlagen stimmen natürlich noch (sind aber nicht vollständig), die Angaben zu den DNS-Servern und deren Konfiguration sind aber 20 Jahre nach Erscheinen mit Vorsicht zu genießen.

Daß Du nicht gut komplexe Themen aus Youtube-Videos lernen kannst, glaube ich Dir gern. Mehr noch: Ich glaube, niemand kann das. Leider hat Youtube das Lesen von dicken Büchern anscheinend abgelöst. Vermutlich eine Frage der Aufmerksamkeitsspanne

Die Netzwerktechnik-Fibel liefert häufig Treffer bei der Suche nach Erklärungen. Die Inhalte sind über Links (nach unten scrollen) im Internet verfügbar . Da kommt man über weiterführende Links auf den Seiten von Router zu IPv6 zu SLAAC ...

Vielen Dank an Peter Eckel und sudoRinger!
Beim ZVAB - Zentralverband Antiquarischer Bücher (fast ein Unding, in Zusammenarbeit mit Netzwerktechnik von antiquarisch zu reden) habe ich eine Handvoll der Buchvorschläge zu wirklich kleinem Geld gefunden, z.T. drei fuffzig…
Und die Netzwerktechnik-Fibel ist auch Gold wert, ist gebookmarked.
Da kann ich nun endlich mein angehäuftes gefährliches Halbwissen auf eine solide Basis stellen.

Eine, zumindest für mich, neben Büchern (zum Nachschlagen) ebenfalls sehr gute Quelle zum „Erlernen“ ist die Plattform „Udemy“. Gibt’s als Webseite und als App. Darüber kann man sich Video-Trainerkurse kaufen ( ! ), dann jedoch so oft anschauen wie man möchte.