DNS verstehen.

[debiator]

Um das Thema etwas aus einem anderen Topic auszulagern.
Eine kurze Beschreibung nach meinem Verständnis mit ein paar Fragen:

DNS-Server wird gebraucht um aus den IP-Adressen der Webserver der jeweiligen Webseiten Homepage-Adressen zu "machen".
Dieser Schickt die Anfragen an einen Nameserver, welcher dann letztendlich den Übersetzer Spielt.
Der Nameserver hat eine große Datenbank (die er bei z.B. denic aktualisiert?) mit IP-Adressen und den dazugehörigen Domainnamen (Webseitennamen).
Letztendlich ist der DNS-Server der Mittelmann zwischen dem Home-PC und dem Nameserver.

Bitte korrigieren und/oder ergänzen.

Jetzt noch eine Frage:
Wenn ich einen DNS-Server über z.B. dnscrypt nehme der auf dem Port 443/TCP läuft (oder sonst einem UDP/TCP), warum braucht mein Home-PC dann noch den Zugang zum Port 53/UDP (den Standard-DNS-Port) und warum baut er zu den Seiten über 53 die Verbindungen auf?

Ist es so zu verstehen, dass ich über 443 den DNS-Server frage, der frägt den Nameserver, die ganze Sache kommt zu mir zurück und ich dann (bevor die Seite per http/80 geladen wird) der Seite per 53 sage, was sie für eine Webadresse ist??

[alteholz]

DNS-Server wird gebraucht um aus den IP-Adressen der Webserver der jeweiligen Webseiten Homepage-Adressen zu "machen".

Nein, der DNS-Server wandelt Namen (=Domainnamen) in IP-Adressen um.

Wenn ich einen DNS-Server über z.B. dnscrypt nehme der auf dem Port 443/TCP läuft (oder sonst einem UDP/TCP), warum braucht mein Home-PC dann noch den Zugang zum Port 53/UDP (den Standard-DNS-Port) und warum baut er zu den Seiten über 53 die Verbindungen auf?

Auch wenn ein DNS-Server dnscrypt spricht, müssen das ja nicht alle tun. Für solche Anfragen wird noch der Port 53 benötigt.

Ist es so zu verstehen, dass ich über 443 den DNS-Server frage, der frägt den Nameserver, die ganze Sache kommt zu mir zurück und ich dann (bevor die Seite per http/80 geladen wird) der Seite per 53 sage, was sie für eine Webadresse ist??

Das klingt seltsam. Eine Webseite "weiß" in der Regel wie sie heißt. Das muß man ihr nicht sagen ...

Thorsten

[MSfree]

DNS-Server wird gebraucht um aus den IP-Adressen der Webserver der jeweiligen Webseiten Homepage-Adressen zu "machen".

Die Hauptaufgabe ist genau das Gegenteil. Du tippst in den Browser z.B. http://www.google.com, damit der eigentlich Server gefunden wird, muß man den Domainname in eine IP-Adresse umsetzen, und die wird dann vom Browser kontaktiert.

Der umgekehrte Weg (IP -> Domainname/Hostname) ist auch sinnvoll. Dieser sogenannte reverse-Lookup ist aber nicht immer möglich.

Der Nameserver hat eine große Datenbank (die er bei z.B. denic aktualisiert?) mit IP-Adressen und den dazugehörigen Domainnamen (Webseitennamen).

OK, das ist stark vereinfacht. Im Grunde gibt es sehr viele Nameserver, unsere Firma betreibt für ihre Domain einen eigenen DNS. Aber es stimmt schon, jeder Namerserver hat eine Datenbank für den eigenen Adressbereich. Ferner weiß jeder DNS, wo er nachfragen muß, wenn die Anfrage nicht selbstständig beantwortet werden kann.

Letztendlich ist der DNS-Server der Mittelmann zwischen dem Home-PC und dem Nameserver.

Schreibfehler?

Der DNS ist der Mittelman zwischen dem Home-PC und dem Internetserver. Ob das nun ein Webserver oder ein Mailserver oder ein FTP-Server... ist, ist erstmal egal.

Wenn ich einen DNS-Server über z.B. dnscrypt nehme der auf dem Port 443/TCP läuft (oder sonst einem UDP/TCP), warum braucht mein Home-PC dann noch den Zugang zum Port 53/UDP (den Standard-DNS-Port) und warum baut er zu den Seiten über 53 die Verbindungen auf?

Der Name-Lookup erfolgt vom Clientprogramm immer über den standardisierten Port 53. Wenn du z.B. mit deinem Mailprogramm den Mailserver imaps.t-online.de kontaktierst, so erfragt das Mailprogramm immer über den Port 53 nach der IP-Adresse des Rechners mit dem Namen imaps.t-online.de. Der Mailprogramm hat absolut keine Möglichkeit, über tcp/443 verschlüsselt einen Namelookup durchzuführen. Daher brauchst du ja den dns-crypt, der die Port 53 Anfragen "abfängt" und dann via Port 443 verschlüsselt an den entsprechenden Server leitet. Dieses Abfangen und Weiterleiten nennt man englisch "Proxy".

Ist es so zu verstehen, dass ich über 443 den DNS-Server frage, der frägt den Nameserver, die ganze Sache kommt zu mir zurück und ich dann (bevor die Seite per http/80 geladen wird) der Seite per 53 sage, was sie für eine Webadresse ist??

Die Kommunikation über dnscrypt geht etwa so ab:

Der Webbrowser will die Seite von http://www.google.com darstellen:

Webserver: "hey Namerserver auf Port 53, gib mir mal die IP von http://www.google.com"
Nameserver: "OK, der Browser will http://www.google.com, ich habe gar keine Ahnung, mal den Chef fragen. Hey Chef, was ist die IP von http://www.google.com"
Chef: "OK, du willst di IP von http://www.google.com? Dann frage ich mal den dns-crypt auf Port 443. Hey dnscrypt, was ist die IP von http://www.google.com?
DNS-Crypt: "da frage ich mal meine Vorgesetzten auf Port 443"
Chef von DNS-Crypt: "Das weiß ich auch nicht, da frage ich mal den Root-DNS auf Port 53"
DNS-Root: "OK, die IP von http://www.google.com habe ich zufällig gecached, die lautet 173.194.113.16"
Chef von DNS-Crypt: "OK, verstanden, das gebe ich dann mal weiter"
DNS-Crypt: "OK, das habe ich empfangen, gebe weiter"
Chef: "OK, das habe ich jetzt bekomen, gebe weiter"
Nameserver: "OK, ich sage dem Browser, daß die IP von http://www.google.com 173.194.113.16 ist"
Browser: "Danke an euch"

Browser: "Hey Sever 173.194.113.16 auf Port 80, reich mal deine Startseite zurück"
http://www.google.com: "Hier hast du sei"
Browser: "Danke, dann stell ich sie mal für den Kerl an der Tastatur am Bildschirm dar".

[debiator]

Nein, der DNS-Server wandelt Namen (=Domainnamen) in IP-Adressen um.

ah, also andersherum. DNS-Server holt die Liste der Webseiten von dem Nameserver und wandelt sie in brauchbare Verbindungsdaten um also IP.
Ist ja auch logisch, man tippt ja die Seite ein.

Auch wenn ein DNS-Server dnscrypt spricht, müssen das ja nicht alle tun. Für solche Anfragen wird noch der Port 53 benötigt.

Das verstehe ich nicht. dnscrypt stellt eine Verbindung (verschlüsselte) zu einem DNS-Resolver her, der klärt die Übersetzung. Wenn etwas außerhalb des dnscrypts passiert, dann wäre es gravierend und würde ein DNS-Leak darstellen. Wo ist also der Hacken?

Das klingt seltsam. Eine Webseite "weiß" in der Regel wie sie heißt. Das muß man ihr nicht sagen ...

Das ist klar, ich habe nur eine einfache bildliche Erklärung gesucht. Es ging mir um die Transferkette.


@MSfree:
Danke für die Darstellung, jetzt habe ichs etwas plastischer.
Mir ist allerdings immer noch die Frage, was ist mit diesem verreckten 53er in der Kette? Stellt es dann keinen DNS-Leak dar?

[MSfree]

Mir ist allerdings immer noch die Frage, was ist mit diesem verreckten 53er in der Kette?

53 ist der Standard schlechthin. Das wurde mal so festgelegt und ist praktisch unumstößlich.

Jeder Client der einen anderen Rechner kontaktieren will, fragt den für ihn zuständigen Nameserver über Port 53 ab.

Ob du nun auf der Kommandozeile ping http://www.google.de tippst, oder dein Mailprogramm öffnest, das wiederum den Telekom-Mailserver imaps.t-online.de abfragt, oder ob du mit dem Browser auf http://www.bild.de surfen willst ist egal. Alle nutzen den gleichen einheitlichen Weg, die IP-Adresse des Ziels über Port 53 beim Nameserver zu erfragen.

Auch der dnscrypt-Dienst hat keine so großen Server, um alle 4 Milliarden theoretischen IPv4-Adress/Hostname-Paare zu speichern und aktuell zu halten, denn es ändern sich einige tausend pro Stunde. Von IPv6 reden wir hier lieber gar nicht, es gibt mehr IPv6-Adressen als Atome im Sonnensystem. Also muß auch der dnscrypt-Dienst irgendwann wieder aus seiner Veschlüsselung raus und die normalen Nameserver kontaktieren. Der ganze dnscrypt ist also kein Sicherheitsgewinn, es ist bestenfalls eine Verschleierung, an der nichtmal die Strafermittler oder Geheimdienste interessiert sind.

[debiator]

also ist es Fakt, dass dnscrypt den verschlüsselten Tunnel verlässt?
Die Frage, die sich da aber stellt ist, ob die Anfragen, die dann vom DNScrypt-Resolver weiter geschickt werden, ob sie dann dem Anfragenden zugeordnet werden können, oder ob da der Tunnel dazwischen liegt und es nicht klar ist, wer angefragt hat.

By the way, gibt es nicht nur Geheimdienste und Provider im Internet, sondern jede Menge Menschen, die jede Menge Unfug treiben.

[MSfree]

also ist es Fakt, dass dnscrypt den verschlüsselten Tunnel verlässt?

Ja, auf jeden Fall.

Die Frage, die sich da aber stellt ist, ob die Anfragen, die dann vom DNScrypt-Resolver weiter geschickt werden, ob sie dann dem Anfragenden zugeordnet werden können, oder ob da der Tunnel dazwischen liegt und es nicht klar ist, wer angefragt hat.

Für die Zuordnung interessiert sich kein Mensch. Mit der Information fängt auch ein Angreifer rein gar nichts an. Ich könnte ja z.B. einfach mit dem Aufruf nslookup http://www.kinderporno.com bei Ermittlern für Aufsehen sorgen. Solange ich dann aber nicht mit dem Webbrowser auf diese Seite gehe und ein echte Verbindung dahin aufbaue. weiß deiser irgendjemand nur, daß ich zum Spaß ein Nameserver-Lookup ausgeführt habe.

By the way, gibt es nicht nur Geheimdienste und Provider im Internet, sondern jede Menge Menschen, die jede Menge Unfug treiben.

Ja, und die sind eher daran interessiert, z.B. die IP-Adresse einer Bank zu verbiegen und viele Leute auf eine gefälschte Seite zu locken als einem einzelnen zu schaden. Und wer in großen Stil Schaden anrichten will, den interessiert die Zuordnung zum Anfragenden nicht.

Wie gesagt, kein Sicherheitsgewinn, kein erhöhter Schutz der Privatsphäre, aber jede Menge FUD.

[wanne]

Der Nameserver hat eine große Datenbank (die er bei z.B. denic aktualisiert?) mit IP-Adressen und den dazugehörigen Domainnamen (Webseitennamen).

Um das nochmal klarzustellen (weil zu oft falsch dargestellt.). Kein nameserver hat eine Datenbank mit allen Domainnamen. (Das sind auch bei IPv4 deutlich mehr als 4Mrd., weil mehrere Naemen auf die gleiche IP zeigen können. ) Dein Nameserver wird nur extrem häufige Namen kennen. Sonst sprechen sich die Nameserver untereinander ab. Insbesondere haben die root-DNS server nur einige hundert einträge und werden niemals direkt antworten sondern immer nur auf weitere DNS-Server verweisen.

Wenn ich einen DNS-Server über z.B. dnscrypt nehme.

Um das nochmal klarzustellen: dnscrypt verschlüsselt gar nicht. Es signiert lediglich. D.h. Es wird lediglich sichergestellt, dass du nur das bekommst, was OpenDNS losgesendet hat. Das ist deswegen wichtig, weil es viele Angriffe gibt, die versuchen auf Namen falsche IPs zu antworten. (Prinzipiell kann jeder auf eine DNS-Anfrage Antworten. (Und nein irgend welche dämlichen NATs verhindern das nicht.)) Er muss nur schneller antowrten als der "echte" DNS-Server . So kann man jemanden beispielsweise auf eine andere webseite lozen und hoffen dass man dort seine Passwörter eingibt. (Falls die Webseit kein HTTPS nutzt.)
Problem ist, dass man eben nicht die wirkliche Antwort sondern die von OpenDNS bekommt. (Und wie die an ihre ergebnise kommen ist eher Fragelich. Wie gesagt: Eine vollständige Datenbank gibt es nicht.) Wenn du dich für sowas interessierst: DNSSEC garantiert wirklich richtige Antworten. (Und ist btw. auch wesentlich schneller.)

der auf dem Port 443/TCP läuft (oder sonst einem UDP/TCP), warum braucht mein Home-PC dann noch den Zugang zum Port 53/UDP

Zuerstmal TCP und UDP sind völlig unterschiedliche Protokolle. Man kann die nicht einfach austauschen. Ist wie wenn du versuchst mit einem Zug auf der Straße zu fahren. Dass beide Ports haben ist reiner Zufall. (Bzw. hat damit zu tun, dass UDP das von TCP abgeschaut hat.) ICMP hat beispielsweise gar keine. Es gibt zwar DNS, dass man über TCP sprechen kann. (Wie es Autos gibt die auf Schienen fahren können.) Aber das ist was völlig eigenes und eine obskurität und ineffizient. Der Port wäre dagegen völlig wurst. Aber es sprechen einfach alle über Port 53. Da hat man sich mal darauf geinigt. Es wäre rein Theoretisch möglich aber versuch mal irgend wo den DNS-Port einzustellen. Ist einfach nirgends vorgesehen. Keiner hat je einen Vorteil darin gesehen. Deswegen wird überall implizi Port 53 genommen.

[catdog2]

Es gibt zwar DNS, dass man über TCP sprechen kann.

DNS kann über TCP und UDP verwendet werden. Die meisten Server dürften auch beides anbieten. Für die meisten arten von Anfragen bevorzugt man aber UDP weil ein TCP Handshake zu lange dauert und keinen Mehrwert bietet u.a. weil die Antworten eh meist in ein Paket passen. TCP verwendet man höchstens für größere Anfragen wie Zonentransfers.

Sonst sprechen sich die Nameserver untereinander ab. Insbesondere haben die root-DNS server nur einige hundert einträge und werden niemals direkt antworten sondern immer nur auf weitere DNS-Server verweisen.

DNS ist einfach ein hierarchisches System. Wenn du debianforum.de. auflösen willst musst du einen root Server fragen (die sind unter bekannten IP Adressen zu erreichen), der verweist dich aber nur auf einen für de. zuständigen Server welcher dich dann an den für debianforum.de. zuständigen Server verweist welcher am ende den gewünschten Eintrag zurück gibt. Das machst du in der Regel aber nicht direkt (der glibc resolver kann das z.B. gar nicht) sondern es gibt bestimmte DNS Server welche sog. rekursive Anfragen unterstützen, dir die Arbeit also abnehmen und dir das Ergebnis am Silbertablett präsentieren. Diese legen die Antworten außerdem in einen Cache, d.h. wenn innerhalb kürzerer Zeit mehrfach debianforum.de angefragt wird wird die Antwort schneller kommen und das System als ganzes entlastet. Daher ist es auch sinnvoll einen lokalen Cache (z.B. eingebaut im Browser oder OS oder z.B. mit dnsmasq im lokalen Netzwerk) zu verwenden weil der die Antworten aufgrund der niedrigen Antwortzeit dann nochmal schneller liefen kann.

[seeker]

Um das nochmal klarzustellen: dnscrypt verschlüsselt gar nicht. Es signiert lediglich.

Ich glaube nicht, dass das korrekt ist. Die dnscrypt-proxy Seite sagt zwar:

dnscrypt-proxy verifies that responses you get from a DNS provider have been actually sent by that provider, and haven't been tampered with.

... was man in deinem Sinne interpretieren könnte. Weiter unten heißt es aber:

The DNSCrypt protocol uses high-speed high-security elliptic-curve cryptography and is very similar to DNSCurve,

Auf der DNSCurve-Seite wiederum heißt es ausdrücklich:

DNSCurve encrypts all DNS packets.

Und openDNS schreibt:

DNSCrypt turns regular DNS traffic into encrypted DNS traffic that is secure from eavesdropping and man-in-the-middle attacks.
...
We’re using elliptic-curve cryptography, in particular the Curve25519 elliptic curve. The design goals are similar to those described in the DNSCurve forwarder design.

Wenn du dich für sowas interessierst: DNSSEC garantiert wirklich richtige Antworten. (Und ist btw. auch wesentlich schneller.)

Auch dazu schreibt openDNS:

DNSCrypt and DNSSEC are complementary. DNSSEC does a number of things. First, it provides authentication. (Is the DNS record I’m getting a response for coming from the owner of the domain name I’m asking about or has it been tampered with?) Second, DNSSEC provides a chain of trust to help establish confidence that the answers you’re getting are verifiable. But unfortunately, DNSSEC doesn’t actually provide encryption for DNS records, even those signed by DNSSEC. Even if everyone in the world used DNSSEC, the need to encrypt all DNS traffic would not go away. Moreover, DNSSEC today represents a near-zero percentage of overall domain names and an increasingly smaller percentage of DNS records each day as the Internet grows.

That said, DNSSEC and DNSCrypt can work perfectly together.

Und deshalb macht es ja auch Sinn, einen DNSSEC-fähigen dnscrypt-Resolver zu wählen.

[wanne]

Ich habe jetzt mal einfach in wireshark geguckt. Die nutzen einfach QUIC als Protokoll. Das schreibt Verschlüsslung vor. Warum sie das nicht einfach verraten verstehe ich nicht.

[debiator]

danke für die genauere Darstellung.
Dass TCP und UDP etwas anderes ist, ist klar.

dnscrypt verschlüsselt auf jeden Fall. Nur seltsamerweise nicht alles. Zumindest bei mir scheint es der Fall zu sein. Oder ich verstehe das DNS-Prinzip immer noch nicht. Denn wenn alles über localhost-dnscrypt laufen soll, dann dürfte mein Rechner nicht über 53 mit der Außenwelt kommunizieren.

[debiator]

Dass dnscrypt QUIC nutzt.... jooaa... da das Protokoll vom Google kommt, ist es natürlich fragwürdig.
Ist es nachvollziehbar, wie es gemacht wurde und was es treibt?

[shoening]

Hallo,

dnscrypt verschlüsselt auf jeden Fall. Nur seltsamerweise nicht alles. Zumindest bei mir scheint es der Fall zu sein. Oder ich
verstehe das DNS-Prinzip immer noch nicht.

ich habe mir jetzt nicht genau angesehen, was DNSCrypt genau macht, aber aus dem, was man z.B. bei Wikipedia findet, wird die DNS Antwort mit einer Digitalen Signatur versehen. Das bedeutet, dass sie unverschlüsselt transportiert wird, aber der Empfänger in der Lage ist zu prüfen, dass die erhaltene Antwort wirklich vom dem Absender stammt, den er erwartet.

Natürlich werden dabei kryptografische Verfahren verwendet. Bei Digitalen Signaturen verwendet man Public/Private-Key Kryptografie.
Der Absender erstellt von der Nachricht (in Deinem Fall der DNS Antwort des Servers) eine Prüfsumme (z.B. MD5 oder SHA-256, ...) und verschlüsselt diese mit seinem privaten Schlüssel. Die Nachricht und die verschlüsselte Prüfsumme werden zum Empfänger geschickt.
Der Empfänger kann dann mit dem öffentlichen Schlüssel des Absenders die Prüfsumme entschlüsseln und mit der (selbst berechneten) Prüfsumme der Nachricht vergleichen.

Also gehen die Antworten unverschlüsselt über das Netz, aber der Empfänger weiß sicher, woher die Antwort gekommen ist.

Ciao
Stefan

[DeletedUserReAsG]

Dass dnscrypt QUIC nutzt.... jooaa... da das Protokoll vom Google kommt, ist es natürlich fragwürdig.
Ist es nachvollziehbar, wie es gemacht wurde und was es treibt?

Natürlich: https://tools.ietf.org/html/draft-tsvwg ... rotocol-00 – wie sollte es auch implementiert werden können, wenn es nicht einsehbar wäre?

[wanne]

Ich habe mir jetzt nicht genau angesehen, was DNSCrypt genau macht, aber aus dem, was man z.B. bei Wikipedia findet, wird die DNS Antwort mit einer Digitalen Signatur versehen. Das bedeutet, dass sie unverschlüsselt transportiert wird, aber der Empfänger in der Lage ist zu prüfen, dass die erhaltene Antwort wirklich vom dem Absender stammt, den er erwartet.
[…]
Also gehen die Antworten unverschlüsselt über das Netz, aber der Empfänger weiß sicher, woher die Antwort gekommen ist.

Hatte ich aufgrund des Artikels auch vermutet. Aber prinzipiell schließt eine Signatur Verschlüsslung ja nicht aus. Und wenn man nachguckt, sind die Daten verschlüsselt.

[debiator]

Es IST faktisch alles verschlüsselt, man kann es ja in Wireshark sehen.
Und wenn QUIC nachvollziehbar ist, dann steht dem ja nichts im Wege.

Das DNS-Leak von dnscrypt war lediglich aufgrund des Addons für dnssec, ohne dieses Addon gibts da keinen Leak und auch keinen Port 53.

[dufty2]

Es IST faktisch alles verschlüsselt, man kann es ja in Wireshark sehen.
Und wenn QUIC nachvollziehbar ist, dann steht dem ja nichts im Wege.

Das DNS-Leak von dnscrypt war lediglich aufgrund des Addons für dnssec, ohne dieses Addon gibts da keinen Leak und auch keinen Port 53.

Ja ja, schon richtig.
Denke, shoening hat auf wikipedia DNSSEC mit DNSCrypt resp. DNSCurve verbuchstabelt

[debiator]

jup, sieht so aus... denn DNSSEC, das Ding verschlüsselt wirklich gar nicht. Ist ja auch nicht der Sinn der Sache dabei.
Es wird alles ganz offen übertragen. Das Ding geht auch, trotz den Einstellungen, am dnscrypt vorbei (warum auch immer).
Deswegen nutze ich lieber dnscrypt als dnssec.

[dufty2]

Deswegen nutze ich lieber dnscrypt als dnssec.

Das eine schließt das andere nicht aus.
Nur weil ein Firefox-Addon den lokalen resolver übergeht, heisst dies noch lange nicht,
das das Protokoll DNSSEC fehl am Platze wäre.

[debiator]

kann ich den zu dem dnsmasq und dnscrypt verwenden und zwar lokal?
Wenn ja wie und mit was? Das Ding ist ja an sich sinnvoll.

[dufty2]

Ja, sollte gehen. (Selbst nicht ausprobiert, da ich unbound verwende):
dnsmasq mit --server=127.0.0.1#41
und dann weiter wie auf
https://dnscrypt.org/
beschrieben unter
"Using DNSCrypt in combination with a DNS cache"

[debiator]

hä?? Ja dafür hab ich ja selber in einem anderen Thread eine Anleitung geschrieben.
Das ist die Zusammenarbeit von dnsmasq und dnscrypt.

Die Frage ist, wie kann ich da DNSSEC einbinden??

[dufty2]

Naja, dann solltest Du die Frage etwas weniger missverständlich formulieren.
Und nein, ich lese nicht alle threads

dnsmasq hat die Option "--dnssec".
Aber alles ohne Gewähr, da selbst nicht getestet.

[debiator]

alles klar. danke, werds mal testen.