Vor Kurzem fragte mich ein Freund, welchen DNS-Server ich ihm empfehlen könne. Zuerst war ich verwirrt und verstand die Frage nicht. Mein Freund sagte daraufhin, dass der DNS-Server seines Internet Service Provider (ISP) Anfragen nur schnarch-langsam beantwortet. Da ich mir nicht vorstellen konnte, dass dies eine allzu große Rolle spielt, war es Zeit für eine kleine Spielerei.
Hinweis: Es handelt sich hierbei wirklich nur um eine Spielerei zum Zeitvertreib und keinen fundierten Test.
Wer sich die Funktionsweise des DNS noch einmal ins Gedächtnis rufen möchte, kann hier im Blog nachlesen.
Das Spielfeld
Die folgende Grafik zeigt das Spielfeld für unsere DNS-Abfragen:

Im Bild zu sehen ist ein WLAN-Router als zentrale Schaltstelle im Heimnetzwerk. Über WLAN mit der Connect Box verbunden ist ein Notebook, welches für unsere Spielerei als Client dienen soll. Mit einem LAN-Kabel angeschlossen ein Pi-Hole, als DNS-Resolver im LAN. Darüber hinaus halten noch der DNS-Server meines ISP, ein DNS-Server von Google (8.8.8.8) und einer von Cloudflare (1.1.1.1) für unsere Spielerei her. Insgesamt sind also vier DNS-Server am Spiel beteiligt.
Das Spiel
In diesem Spiel nutze ich das Kommando dig
, um jeweils zwei Anfragen an jeden der vier DNS-Server zu senden. Zwei Anfragen deshalb, um jedem Resolver die Chance zu geben, mindestens eine Anfrage aus seinem Cache beantworten zu können.
Gegenstand der Abfrage wird ein A-Record meiner Domain „my-it-brain.de“ sein. Im Folgenden wird jeweils die gekürzte Ausgabe von dig
wiedergegeben, welcher man die Zeit für die Abfrage entnehmen kann.
Nach jeder Abfrage werden noch 10 Pings an den jeweiligen DNS-Server gesendet, um die Zeit zu mitteln, die das Paket auf der Leitung unterwegs ist.
TL;DR
Wie zu erwarten war, hat der Pi-Hole das Spiel mit den kürzesten Antwortzeiten gewonnen. Die DNS-Server von Google und Cloudflare liegen ungefähr gleich auf, wobei der Server von Cloudflare meine Domain bei der ersten Abfrage vermutlich noch nicht im Cache hatte. Der vierte im Bunde ist ein DNS-Server, welcher nach Angaben meines ISP in Dortmund steht. Dieser ist von der Abfragezeit her nicht schlechter, als die Server von Google und Cloudflare. Sieht man sich die Ping-Statistik an, kann ich wohl froh sein, überhaupt eine Antwort erhalten zu haben.
Im Folgenden findet ihr die Ausgaben der einzelnen Kommandos.
@karl: Wie sieht das denn bei dir aus?
Die Ergebnisse
$ dig @192.168.11.3 -4 my-it-brain.de A
[...]
;; Query time: 6 msec
;; SERVER: 192.168.11.3#53(192.168.11.3)
;; WHEN: Mo Apr 06 22:53:43 CEST 2020
$ dig @192.168.11.3 -4 my-it-brain.de A
[...]
;; Query time: 8 msec
;; SERVER: 192.168.11.3#53(192.168.11.3)
;; WHEN: Mo Apr 06 22:54:55 CEST 2020
;; MSG SIZE rcvd: 59
$ ping -c 10 192.168.11.3
--- 192.168.11.3 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 21ms
rtt min/avg/max/mdev = 3.002/4.425/8.268/1.725 ms
$ dig @80.69.100.230 -4 my-it-brain.de A
[...]
;; Query time: 44 msec
;; SERVER: 80.69.100.230#53(80.69.100.230)
;; WHEN: Mo Apr 06 22:59:41 CEST 2020
;; MSG SIZE rcvd: 87
$ dig @80.69.100.230 -4 my-it-brain.de A
[...]
;; Query time: 49 msec
;; SERVER: 80.69.100.230#53(80.69.100.230)
;; WHEN: Mo Apr 06 22:59:44 CEST 2020
;; MSG SIZE rcvd: 87
$ ping -c 10 80.69.100.230
--- 80.69.100.230 ping statistics ---
10 packets transmitted, 5 received, 50% packet loss, time 119ms
rtt min/avg/max/mdev = 18.458/19.942/21.248/1.092 ms
$ dig @8.8.8.8 -4 my-it-brain.de A
[...]
;; Query time: 53 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mo Apr 06 23:01:09 CEST 2020
;; MSG SIZE rcvd: 59
$ dig @8.8.8.8 -4 my-it-brain.de A
[...]
;; Query time: 49 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mo Apr 06 23:01:12 CEST 2020
;; MSG SIZE rcvd: 59
$ ping -c 10 8.8.8.8
--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 22ms
rtt min/avg/max/mdev = 18.120/20.722/23.760/1.554 ms
$ dig @1.1.1.1 -4 my-it-brain.de A
[...]
;; Query time: 89 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mo Apr 06 23:03:26 CEST 2020
;; MSG SIZE rcvd: 73
$ dig @1.1.1.1 -4 my-it-brain.de A
[...]
;; Query time: 48 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mo Apr 06 23:03:28 CEST 2020
;; MSG SIZE rcvd: 73
$ ping -c 10 1.1.1.1
--- 1.1.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 23ms
rtt min/avg/max/mdev = 20.748/49.316/87.433/24.899 ms
Schlussworte
Ich persönliche ziehe es vor, einen DNS-Resolver möglichst in bzw. nah an meiner Infrastruktur zu nutzen.
Neben der Geschwindigkeit der Abfragen bekommt so auch niemand mit, wie oft ich eine Seite aufrufen möchte, da alle auf die initiale Abfrage folgenden Abfragen aus dem Cache beantwortet werden.
Bedenkt man, dass die Ladezeit von Webseiten teilweise im Bereich mehrerer Sekunden liegt, fallen die paar Millisekunden für die Namensauflösung aber eh nicht so schwer ins Gewicht.
Ich habe auf meinem VPS knot-resolver als rekursiven DNS laufen und auf meinen Rechner habe ich knot-resolver oder unbound laufen, die über DoT auf den DNS-Server auf dem VPS zugreifen. Da knot-resolver und unbound auf den Rechnern auch cachen habe ich bei der zweiten Anfrage immer eine 0ms Antwort.
Ein Pi-Hole habe ich nicht, aber mein DNS hat die meisten Tracker auch schon geblockt.
Zum Thema DNS möchte ich nur beisteuern, dass ich seit Jahren Quad9 verwende.
Einfach 9.9.9.9 statt 8.8.8.8. Also auch sehr einprägsam 😉
Bin wegen folgendem Artikel darauf gestoßen: https://www.heise.de/newsticker/meldung/Quad9-Datenschutzfreundliche-Alternative-zum-Google-DNS-3890741.html
Viele Grüße
Rene
Hallo Rene,
danke für den Hinweis auf Quad9. Ich verwende diesen als Upstream-DNS-Server in meinem Pi-Hole. Er gefällt mir, da er neben IPv4 und IPv6 auch DNSSEC bietet.
Viele Grüße
Jörg
Ich habe meinem Pi-Hole einen dnscrypt-proxy vorgeschaltet, also als localhost auf dem gleichen Raspberry Pi laufend.
Darüber werden die DNS-Anfragen vom Pi-Hole dann über dnscrypt-proxy an die eingetragenen Upstream-DNS-Resover verschlüsselt. In meinem Fall sind das aktuell folgende (alle per DNSSEC validiert):
securedns (DNSCrypt)
securedns-doh (DNS over HTTPS)
dnswarden-doh1 (DNS over HTTPS)
dnswarden-doh2 (DNS over HTTPS)
dnswarden-doh3 (DNS over HTTPS)
dns.digitale-gesellschaft.ch (DNS over HTTPS)
dnswarden-dc1 (DNSCrypt)
dnswarden-dc2 (DNSCrypt)
dnswarden-dc3 (DNSCrypt)
ffmuc.net (DNS over HTTPS)
dnscrypt.one (DNSCrypt)
Ein weiteres Feature von dnscrypt-proxy ist das Load Balancing:
“dnscrypt-proxy comes with a load balancing algorithm. It will send consecutive DNS queries to different DNS servers randomly choosen from a sorted (fastest to slowest) set of a choosen size. The size of that set is what you can choose in the configuration file with the lb_strategy parameter. A server will be choosen randomly among the N fastest servers in your list of servers (or if you are not specifically choosing servers with the server_names parameter, among the N fastest servers from all servers that match your requirements.)”
Mehr dazu hier: https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Load-Balancing-Options
Läuft soweit alles ganz performant auf einem Raspberry Pi 2.