Spricht was gegen die Verwendung von AdGuard Home als Docker?

[undead]

Ach Gott. Irgendwie bin ich im falschen Forum, oder was. Höre hier nur Pi, PiHole, RasPi, DietPi...
Also ich kann keine Tips für Raspberry Pis geben, da ich so welche nicht besitze.

Bezgl. Adguard auf Synology NAS:
Den Docker-Container aus der Registrierung runterladen und starten.
Wie gesagt habe ich macvlan genommen und den ins Netzwerk als normaler Host eingebunden.
Zumindest Port 80 freigeben. Bei mir sind's noch andere wie 443 oder 53 für DNS.
Dann im Handy in die WLAN-Einstellungen gehen und dort in die manuelle DNS-Konfig.
Dort die AdGuard-IP als DNS eintragen.

Als zweites habe ich aus dem Appstore die App AdGuard heruntergeladen.
Diese mit vielen Clicks in den Browser einbinden und aktivieren (nervig).

Dadurch kann man viele Webseiten und (durch die Erweiterung auch Youtube) werbefrei genießen.

Ich mache das eigentlich auch nur, weil einige Webseiten wie z.B. von diversen Zeitungen und Verlagen mal Werbe-Partner hatten,
deren Server gehackt wurden und über die Werbung auf hunderten von Webseiten Schadsoftware auf die Rechner geschleust wurde.
Da sind die Werbeanbieter selbst schuld wenn sie geblockt werden. Wenn sie als Virenschleuder gelten...

Hoffe ich konnte ein paar Anregungen geben...

 

[EDvonSchleck]

Was das MacVlan angeht musst du nichts mit den Ports machen. Das geht viel einfacher und effektiver:

1. du erstellst in Adguard eine Umschreibung: Filter>DNS Umschreibung, dort gibst du der Anwendung einen Domainnamen z.B. adguard.home und als Ziel die Diskstation IP
2. du richtest den Reverse Proxy in der Diskstation so ein das der Eingang adguard.home an Port 80 oder 443 ist und zur IPder Diskstation mit UI-Port z.B. 3000 weitergeleitet wird.

Jetzt kannst du jederzeit adguard.home (Netz-Intern) aufrufen und wirst immer weitergeleitet auf das Interface. Das geht natürlich auch mit MacVlan und anderen Anwendungen.

Unbound welches du niicht nutzt speichert merkt sich die richtige Endadresse und behält diese im Speicher. Somit können Internetseiten sehr schnell direkt aufgerufen werden ohne sich vom Server zu Server (Anfrage) zu hangeln. Die Antwortzeit beträgt denn unter 1 bis 3ms!

 

[undead]

Hi,

wg. Ports: Hier hatte ich die Einstellungen in der Config des Containers gemeint (Lokaler Port - Container Port). Also ich nutze die, auch wenn es bestimmt auch tausend andere Wege gibt. Bißchen kenn ich mich auch auf der Shell aus

Das mit der DNS Umschreibung und dem Reverse Proxy bekomme ich bestimmt auch noch hin. Man will ja dazu lernen.

Aber wer oder was ist Unbound!? Ist doch bestimmt von der Beschreibung her ein DNS Cache oder sowas.
Also da könnte ich ja generell jeden nutzen. Aber wenn jemand einen Link zu diesem Unbound hat, gerne...

 

[EDvonSchleck]

Hättest du vorher besser gelesen, hattest du schon wissen können was Unbound ist und macht. Verzeichnisse müssen dazu nicht eingerichtet werden, ggf muss nur der Port angepasst werden. Das ganze kannst du natürlich in dein MacVlan oder als Bridge laufen lassen. Anschießend richtest du die IP bei Adguard als Upstream-DNS-Server (Einstellungen>DNS Einstellungen) und fertig ist das ganze. Wenn der Container im gleichen Netz (Netzwerk Docker) ist reicht es auch nur den Namen des Containers einzutragen. Normal werden Container untereinander nicht mit der IP angesprochen es sei den diese IP ist fix oder man nutzt ein Bridge-Netzwerk!

Jetzt kannst du im Log eine Seite aufrufen und die Zeiten bei nochmaligen verbinden vergleichen.

Alle Container kannst du anschließend mit Watchtower (falls noch nicht genutzt) automatisch aktuell halten.

 

[ebusynsyn]

@the other sagt:
"...mag altmodisch sein, darf ich aber, bin schließlich alt."

Definiere alt

Als ich in die erste Klasse ging:
- war Willy Brand gerade mal 1 Jahr im Amt
- In den USA war Richard Nixon Präsident
- wurde Brasilien in Mexiko Fussball-Weltmeister
- und es gab noch kein "Wort des Jahres" das wurde erst ein Jahr später eingeführt

Ja, ich weiss, es gehört eigentlich nicht hierher... wollte aber den Ball von wegen 'alt' einfach mal auffangen.

Beste Grüsse

 

[EDvonSchleck]

Alt hatte ich heute schon einmal... > https://www.synology-forum.de/threads/eol-ds212j.123241/#post-1027419

 

[peterhoffmann]

Als ich in die erste Klasse ging, hat Helmut Schmidt gerade Willy Brandt abgelöst, der da über Günter Guillaume gestolpert ist. Also bin ich zwar auch etwas älter, aber nooooooch laaaaange nicht alt. ;-)

Unbound:
Kann mir Unwissenden jemand den Sinn von Unbound schlüssig in 1-2, vielleicht 3 Sätzen erklären? Ich habe den noch nie verstanden.

 

[EDvonSchleck]

Wenn du eine Anfrage an deine Domain/URL stellst werden unterschiedliche Server abgefragt, ob sie wissen, wie die Adresse/IP des Servers ist und wo diese Seite genau gespeichert ist. Das geht mehrere Male hin und her bis du an den richtigen Server kommst. Dabei wird eine Hierarchie abgearbeitet, angefangen beim DNS meist Provider usw,. Unbound speichert das und verbindet dich beim nächsten aufrufen direkt mit den Server. Deshalb kommen die kurzen Zeiten von 1-3ms zustande.

Video

 

[Benares]

Und was ist mit der TTL und dem lokalen DNS-Cache der Clients? Liefert Unbound die TTL auch korrekt aus oder verfälscht er sie wie z.B. PI-Hole?
Ich kenne Unbound nicht, aber die schnellste Namensauflösung ist immer noch die, die ab dem 2ten Mal erst gar nicht mehr extern stattfindet.

 

[EDvonSchleck]

Das kann ich dir leider nicht sagen so tief stecke ich dort nicht drin. Wenn PI-Hole die TTL verfälscht nach deiner Aussage, denn könnte es Adguard auch sowie Unbound. Ich habe eben noch einmal eine Seite aufgerufen am Laptop (noch nie angezeigt), danach die gleiche Seite auf den Android Tablet und habe laut Adguard eine Antwortszeit von 1ms. Somit ist der Cache des Gerätes ja ausgeschlossen.

Mit der TTL kann ich nicht weiterhelfen, entweder selber ausprobieren oder auf Github nachfragen.

 

[Benares]

Was dein Video unterschlägt ist, dass ja auch jeder Client einen DNS-Cache hat. Die erste Anfrage geht immer den beschriebenen Weg, aber der "zuständige" DNS-Server liefert neben der IP auch die TTL (Time to live), also die Zeit, die sich der Anfragende die Antwort maximal merken sollte. I.d.R. sind das mehrere Stunden/Tage, bei DynDNS-Adressen evtl. auch nur Minuten, um Änderungen schneller zu publizieren. Weitere Anfragen nach dem gleichen Namen werden auf dem Client dann innerhalb von Mikrosekunden aufgelöst.
Jetzt will aber so ein Unbound-/PI-Hole-/Irgendwas-DNS-Server das nicht und möchte immer gefragt werden, damit sein Cache genutzt wird und nicht der des Clients. Also liefert er Antworten mit einer TTL von 0 an die Clients aus, um deren Cache quasi zu deaktivieren.

Wenn du also schreibst "Deshalb kommen die kurzen Zeiten von 1-3ms zustande" ist das Quatsch. Das ist nur die Zeit, die der Unbound-/PI-Hole-/Irgendwas-DNS-Server braucht, um eine Anfrage aus seinem Cache zu bedienen. Ohne den gings wesentlich schneller.

Aber das Ziel eines solchen Tools ist es ja, möglichst schnell auf irgendwelche Änderungen an Blacklists etc. zu reagieren. Deshalb müssen sie ja zunächst den DNS-Client-Cache aushebeln, damit sie überhaupt wieder mal innerhalb der TTL gefragt werden. Das ist verständlich. Aber die Aussage, solche Tools beschleunigen die Namensauflösung, ist schlichtweg falsch.

Edit: Mit "ipconfig /displaydns" kannst du dir übrigens den DNS-Cache eines (Windows-)Clients anschauen.

 

[EDvonSchleck]

Das ist ja alles schön und gut was du schreibst bezieht sich aber immer nur auf einen Client. Ich habe bereits geschrieben das ein manueller Aufruf einer Seite von unterschiedlichen Clients die Zeiten reduziert. Diese Internetseiten waren vorher noch nie in den einen und anderen Client aufgerufen worden. Weiterhin handelt es sich bei den Clients um unterschiedliche Betriebssystem,: Windows und Android. Somit kannst du mir nicht erklären das die schnelle Reaktionszeit vom Cache der Clients kommt. Diese Zeit hatte sich mit Unbound drastisch verkürzt, da ich Adguard vorher eine ganze Zeit (Monate) genutzt hatte.

Da du selbst schreibst das du diese Tools nicht kennst oder nutzt warum probierst du sie nicht aus und schaust dir das diekt an. eventuell findest du mit deinen Wissen noch was interessanten, Fehler oder... . Das ist doch schon das mindeste bevor man darüber herzieht.

Wie du siehst ist dei einstellung bei mir in Adguard zu Cache und TTL, egal ob verlängern oder verkürzen nicht aktiv:

 

[peterhoffmann]

Wenn ich das richtig verstanden habe, ist Unbound ein DNS-Cache, der es ermöglicht durch das Cachen von DNS-Anfragen kürzere Antwortzeiten zu bekommen. Das würde zum Tragen kommen, wenn mehrere Clients die selbe Domain aufrufen. Beim ersten Mal muss die DNS-Abfrage noch durchgeführt werden, beim zweiten Mal nicht mehr, da es aus dem Cache kommt.

Im Grunde ist das also ein Verlagern vom Cache, sprich von jedem Clients zentral zu Unbound. So kann jeder Client im Netzwerk vom zentralen Cache profitieren.

Habe ich das so richtig verstanden und wiedergegeben?

 

[EDvonSchleck]

Würde ich so zustimmen.

 

[DrDeath]

Einfache Erklärung wozu unbound benutzt wird:

https://strobelstefan.org/2021/02/2...nd-kontrolle-ueber-die-dns-anfragen-erhalten/

Mit unbound frägt der Pi-hole nicht bei irgendeinem externen DNS-Server an, der von eurem ISP betrieben wird.

Die Anfragen werden zielgerichtet an den Root-Nameserver, dann an den TLS und dann an den autoritativen Nameserver versendet.

Es gibt also keine Dritten die euer Surfverhalten auf Grund der abgesendeten DNS-Anfragen nachvollziehen können.

 

[peterhoffmann]

Das heißt, dass es bei Unbound weniger um die Geschwindigkeit geht, sondern eher um den Schutz des eigenen Surfverhaltens.
Das Vorgehen von Unbound, sich von oben nach unten über drei Stationen durchzuhangeln, dauert ja eher sogar länger, macht aber im Hinblick auf den Datenschutz durchaus Sinn.

---

DNS-Response-Test:
In der Zwischenzeit hatte ich mich mit dem Cache und den Laufzeiten einer DNS-Abfrage beschäftigt. Ich wollte wissen wie lange überhaupt eine Abfrage dauert. Dafür habe ich mir ein Skript (Bash) geschrieben, welches eine Liste (Top 100 Domains der Aufrufe in Deutschland) abfragt (mit dig) und sich die Zeiten notiert.

Bei geleertem Cache vom Pi-hole komme ich auf eine durchschnittliche Antwortzeit von 35ms, wobei der Hauptteil bei 15 bis 18ms liegt.

Bei (direkt) wiederholtem Aufruf der Liste liegt der Durchschnitt bei 2,2ms. Das liegt natürlich einzig daran, dass Pi-hole schon cacht und somit die meisten Antwortzeiten nah bei 0ms liegen.

Ich habe den gleichen Test noch mal mit externen DNS-Servern gemacht:
9.9.9.9 => 42ms im ersten Durchlauf, 34ms im zweiten Durchlauf
84.200.69.80 => 32ms im ersten Durchlauf, 31ms im zweiten Durchlauf
84.200.70.40 => 27ms im ersten Durchlauf, 24ms im zweiten Durchlauf

---

(Mein) Fazit:
Ein zusätzlicher Cache (Unbound) macht in meinen Augen überhaupt keinen Sinn, da die Antwortzeiten generell schon sehr schnell sind. Wenn man dann noch ein Pi-hole (oder ähnliches) betreibt, schrumpft der (eventuell vorhandene) aber geringe Vorteil auf 0 zusammen.

Einzig der Umstand, dass sich Unbound über drei Stationen durchhangelt, ist ein Vorteil. Hier sehe ich persönlich den einzigen Sinn von Unbound. Ich würde sogar soweit gehen, den Cache im Unbound zu deaktivieren bzw. sehr kurz zu setzen (falls möglich) und damit nur die Sache mit dem Datenschutz nutzen.

 

[the other]

Moinsen,
sorry, die ganzen Fragen weil ich da mal eben was erwähne und jetzt erst gelesen habe...
Mir geht es bei unbound darum, dass ich genau die üblichen Verdächtigen auslassen (also cloudflare, google, ISP DNS, meist...zu google). Natürlich kann auch auf unbound und die Idee dahinter verzichtet werden und es wird ein einfacher datenschutztauglicher(er) DNS eingetragen (gibt ja einige).
Anfangs hatte ich immer Pihole mit einer dieser DNS betrieben, nur wenn die dann mal ausfällt (sind ja mitunter nicht ganz so große DNS Anbieter, eher Initiativen und Vereine) ist eben doof.
Dann hatte ich mal mit stubby die DNS Anfragen verschlüsselt. Fand das aber auf Dauer auch etwas fehleranfällig, da Stubby manchmal etwas divenhaft wirkte.
Schließlich kam dann mit Einsatz der pfsense wieder das unbound Thema auf...wird hier nämlich als resolver genutzt. Die Idee dahinter war und ist immer eher Datenschutz als Speed. Ehrlich gesagt komme ich wie so einige ja noch aus ganz anderen Netzspeed-Zeiten (alt ist immer wie es sich anfühlt), da find ich jetzt die ein oder andere Millisekunde nicht sooo tragisch.
Aber das Meiden der DNS Schnüffeleien find ich dagegen wichtiger als damals...deswegen mach ich das mit unbound. Dazwischen geschaltet dann noch DNS Filterlisten, allerdings mittlerweile nicht mehr auf einem Raspi mit Pihole sondern anders.
Hoffe ich konnte etwas Aufklärung zu (meinem) faible für unbound beisteuern...


Das Cachen kann neben unbound auch anders eingerichtet werden, zB so:
https://www.kuketz-blog.de/pi-hole-...ine-werbung-groesstmoegliche-unabhaengigkeit/

 

[undead]

Der Thread war zwar bisschen Tod, jetzt aber nicht mehr.

Zur Schnelligkeit:
Also ich hab das jetzt so ohne unbound mal folgendermaßen eingerichtet:
Bei Adguard gibt's ja auch das DNS-Caching. Das jetzt so bei mir eingestellt daß es gefühlt schnell ist.
Bin gerade nicht an nem Rechner den ich über AdGuard laufen hab (im Moment nur Handy und Tablet) um das zu testen.
Würde aber mal im Urlaub via dig die Zeiten messen.

Danke für den Tip @peterhoffmann:

DNS-Response-Test:
In der Zwischenzeit hatte ich mich mit dem Cache und den Laufzeiten einer DNS-Abfrage beschäftigt. Ich wollte wissen wie lange überhaupt eine Abfrage dauert. Dafür habe ich mir ein Skript (Bash) geschrieben, welches eine Liste (Top 100 Domains der Aufrufe in Deutschland) abfragt (mit dig) und sich die Zeiten notiert.

Zur Sicherheit:
Hier nutze ich wie schon von

@the other erwähnt:

und es wird ein einfacher datenschutztauglicher(er) DNS eingetragen (gibt ja einige)

einfach meiner Meinung nach datenschutztaugliche DNS-Server, die ich jetzt zunächst mal aus folgender Vorschlagsliste von AdGuard habe:
https://adguard-dns.io/kb/general/dns-providers/

Hier nutze ich auch ein 2-stufiges System:
Bei den allgemeinen Einstellungen von AdGuard habe ich erst mal gängige DNS-Server eingetragen wie z.B. quad9 wobei ich jetzt mal angefangen habe den sichereren Standard DNS over https zu nutzen:
https://dns10.quad9.net/dns-query

Bei den Client-Einstellungen z.B. für die Kinder nutze ich dann die DNS-Server mit Family-Protection aus der Liste.

Ich denke mal das ist dann ziemlich performant und ziemlich sicher.
Zumindest reicht mir das völlig für den vergleichsweise geringen Aufwand und das wenige Know-How dass man investieren muss.

 

[peterhoffmann]

Mein DNS-Script habe ich noch etwas aufgebrezelt. Es testet nun beliebige Domainlisten mit bekannten DNS-Servern (29 Stück zur Zeit).

Verwendete Domainliste:
Es ist für 2022 die Top100-Liste für Deutschland, ermittelt von einem Anbieter für Seo-Tools. Kurioserweise heißt sie Top100, es fehlten aber 5 Domains und somit ist es nur eine Top95.

Verwendete DNS-Server-Liste:
Es ist eine Liste von 29 DNS-Servern. Wer da eine umfangreichere Liste (nur IPs) hat, kann die gerne posten. Dann lasse ich sie noch mal durchlaufen.

Abschneiden von Werten:
Um die Werte etwas zu "egalisieren" werden vom Skript bei allen Ergebnissen die jeweils 5% besten und schlechtesten Einzelergebnisse abgeschnitten und aus den verbliebenen 90% ein Durchschnitt für jeden DNS-Server errechnet.

Fehler:
Wenn eine Abfrage durch einen Timeout beantwortet wird, vermerkt das Skript dies als Fehler und die betreffende Abfrage wird mit 100ms als Antwortzeit in der Berechnung bestraft. Mit den 100ms bin ich gefühlt noch zu gnädig. Mir war aber ein belastbarer Durchschnittswert vom DNS-Server wichtiger. Wobei sich am Ende die Frage stellt, ob man überhaupt einen DNS-Server nutzen will, der sporadisch nicht antwortet.

Zwei weitere Hinweise:
In der Liste fehlt der DNS-Server 8.8.8.8, da dieser in meinem Netzwerk wegen einem Handy gesperrt ist.
Der letzte DNS-Server ist mein Pi-hole, wo ich vor dem Durchlauf den Cache gelöscht habe.

Ausgabe vom Script:

Liste                  : liste02_100_DE.txt
Anzahl der DNS-Server  : 29
Anzahl der Domains     : 95
Wartezeit zw. Abfragen : 2 Sekunde(n)

DNS-Server: 1.0.0.1         | Ø  27.04 ms |  0 Fehler | one.one.one.one.
DNS-Server: 1.1.1.1         | Ø  28.76 ms |  0 Fehler | one.one.one.one.
DNS-Server: 8.8.4.4         | Ø  15.09 ms |  0 Fehler | dns.google.
DNS-Server: 9.9.9.9         | Ø  57.48 ms |  1 Fehler | dns9.quad9.net.
DNS-Server: 64.6.64.6       | Ø  31.65 ms |  0 Fehler | rec1pubns1.ultradns.net.
DNS-Server: 64.6.65.6       | Ø  22.86 ms |  0 Fehler | rec1pubns2.ultradns.net.
DNS-Server: 77.88.8.2       | Ø  95.00 ms |  0 Fehler | secondary.safe.dns.yandex.ru.
DNS-Server: 77.88.8.88      | Ø  92.91 ms |  0 Fehler | safe.dns.yandex.ru.
DNS-Server: 8.26.56.26      | Ø  41.18 ms | 29 Fehler | ns1.recursive.dnsbycomodo.com.
DNS-Server: 8.20.247.20     | Ø  38.14 ms | 24 Fehler | ns2.recursive.dnsbycomodo.com.
DNS-Server: 156.154.70.5    | Ø  31.39 ms |  0 Fehler |
DNS-Server: 156.154.71.5    | Ø  23.03 ms |  0 Fehler |
DNS-Server: 195.46.39.39    | Ø  51.91 ms |  0 Fehler | dns1.safedns.com.
DNS-Server: 195.46.39.40    | Ø  36.28 ms |  1 Fehler | dns2.safedns.com.
DNS-Server: 84.200.69.80    | Ø  28.75 ms |  0 Fehler |
DNS-Server: 84.200.70.40    | Ø  26.51 ms |  0 Fehler |
DNS-Server: 185.228.168.9   | Ø  18.05 ms |  0 Fehler | customfilter9-dns.cleanbrowsing.org.
DNS-Server: 185.228.169.9   | Ø  35.02 ms |  0 Fehler | security-filter-dns2.cleanbrowsing.org.
DNS-Server: 198.54.117.10   | Ø 230.58 ms |  1 Fehler | safeservedns.com.
DNS-Server: 198.54.117.11   | Ø 174.35 ms |  0 Fehler | safeservedns.com.
DNS-Server: 94.247.43.254   | Ø  18.50 ms |  0 Fehler | opennic1.eth-services.de.
DNS-Server: 194.187.251.67  | Ø  41.92 ms |  0 Fehler | manchester-ns01.cyberghostvpn.com.
DNS-Server: 208.67.220.220  | Ø  23.59 ms |  0 Fehler | dns.opendns.com.
DNS-Server: 208.67.222.222  | Ø  23.01 ms |  0 Fehler | resolver1.opendns.com.
DNS-Server: 38.132.106.139  | Ø 120.83 ms |  0 Fehler | newyork-ns01.cyberghostvpn.com.
DNS-Server: 149.112.112.112 | Ø  86.25 ms |  1 Fehler | dns.quad9.net.
DNS-Server: 176.103.130.130 | Ø 130.71 ms |  0 Fehler | 176-103-130-130.dns.adguard.com.
DNS-Server: 176.103.130.131 | Ø 108.44 ms |  0 Fehler | 176-103-130-131.dns.adguard.com.
DNS-Server: 192.168.0.4     | Ø  22.15 ms |  0 Fehler | Pi-hole.fritz.box.

 

[peterhoffmann]

Und noch ein Nachtrag:
Ich habe das Script mit 1000 Domains (Top1000 weltweit) durchlaufen lassen.

Ergebnis:

Liste                  : liste01_1000.txt
Anzahl der DNS-Server  : 29
Anzahl der Domains     : 1000
Wartezeit zw. Abfragen : 2 Sekunde(n)

DNS-Server: 1.0.0.1         | Ø  92.95 ms |   0 Fehler | one.one.one.one.
DNS-Server: 1.1.1.1         | Ø  71.59 ms |   0 Fehler | one.one.one.one.
DNS-Server: 8.8.4.4         | Ø  27.48 ms |   0 Fehler | dns.google.
DNS-Server: 9.9.9.9         | Ø  76.61 ms |  12 Fehler | dns9.quad9.net.
DNS-Server: 64.6.64.6       | Ø  61.51 ms |   1 Fehler | rec1pubns1.ultradns.net.
DNS-Server: 64.6.65.6       | Ø  55.52 ms |   2 Fehler | rec1pubns2.ultradns.net.
DNS-Server: 77.88.8.2       | Ø 133.33 ms |   2 Fehler | secondary.safe.dns.yandex.ru.
DNS-Server: 77.88.8.88      | Ø 132.70 ms |   2 Fehler | safe.dns.yandex.ru.
DNS-Server: 8.26.56.26      | Ø  55.19 ms | 258 Fehler | ns1.recursive.dnsbycomodo.com.
DNS-Server: 8.20.247.20     | Ø  57.29 ms | 252 Fehler | ns2.recursive.dnsbycomodo.com.
DNS-Server: 156.154.70.5    | Ø  62.23 ms |   2 Fehler |
DNS-Server: 156.154.71.5    | Ø  56.30 ms |   2 Fehler |
DNS-Server: 195.46.39.39    | Ø 104.28 ms |  15 Fehler | dns1.safedns.com.
DNS-Server: 195.46.39.40    | Ø  87.30 ms |  33 Fehler | dns2.safedns.com.
DNS-Server: 84.200.69.80    | Ø  71.21 ms |   5 Fehler |
DNS-Server: 84.200.70.40    | Ø  71.13 ms |   5 Fehler |
DNS-Server: 185.228.168.9   | Ø  62.35 ms |   0 Fehler | security-filter-dns.cleanbrowsing.org.
DNS-Server: 185.228.169.9   | Ø  67.89 ms |   0 Fehler | security-filter-dns2.cleanbrowsing.org.
DNS-Server: 198.54.117.10   | Ø 263.51 ms |  38 Fehler | safeservedns.com.
DNS-Server: 198.54.117.11   | Ø 243.02 ms |  21 Fehler | safeservedns.com.
DNS-Server: 94.247.43.254   | Ø  37.68 ms |   0 Fehler | opennic1.eth-services.de.
DNS-Server: 194.187.251.67  | Ø  70.88 ms |   0 Fehler | manchester-ns01.cyberghostvpn.com.
DNS-Server: 208.67.220.220  | Ø  46.28 ms |   0 Fehler | resolver2.opendns.com.
DNS-Server: 208.67.222.222  | Ø  45.32 ms |   0 Fehler | dns.opendns.com.
DNS-Server: 38.132.106.139  | Ø 123.58 ms |   0 Fehler | newyork-ns01.cyberghostvpn.com.
DNS-Server: 149.112.112.112 | Ø 172.85 ms |  23 Fehler | dns.quad9.net.
DNS-Server: 176.103.130.130 | Ø 151.89 ms |   0 Fehler | 176-103-130-130.dns.adguard.com.
DNS-Server: 176.103.130.131 | Ø 145.46 ms |   0 Fehler | 176-103-130-131.dns.adguard.com.
DNS-Server: 192.168.0.4     | Ø  58.91 ms |   0 Fehler | Pi-hole.fritz.box.