Pihole Anzahl blockierte Domains

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo,

    gibt es ein Limit bei Pi-Hole 5.0 bei dem die Performance deutlich nachlässt oder eine technische Limitierung der Anzahl Domänen auf den Blocklisten?

    Habe aktuell ca. 4 Mio und plane noch was draufzusetzten. Bitte keine inhaltliche Sinn/Unsinn Diskussion sondern nur ob es technisch möglich ist, bzw. ab wann es deutliche Performance Einbrüche geben könnte.

    Danke und Gruß,

    Mike

  • Soweit ich weiß, nutzt auch der PiHole 4.x den Fork https://github.com/pi-hole/FTL

    Das ist ein modifizierter Fork von dnsmasq, dass Statistiken exponiert und die Sperrlisten lädt.

    Es sollte sich nichts ändern.

    Als Datenbank wird sqlite3 genutzt und regex wird auch angewandt.

    https://github.com/pi-hole/FTL/blob/master/src/regex_r.h

    Ich bin mir nur nicht sicher, wie lange das Anwenden von 4 Millionen Regex benötigt.

    Wie schnell läuft das denn bei dir? Hast du mal gemessen?

  • ich habe ca 100 white list domains, 4 regex white lists, ca. 110 black list domains 50 black list regex und ca. 4.1 Mio. Domains blocked aus diversen Listen.

    Zum Erstellen braucht der Pi seit 5.0 und der Umstellung auf sqlite etwas länger. Performance technisch im Betrieb habe ich keinerlei Performanceeinbußen festgestellt.

    Mich würde nur die technische Limitation interessieren, sofern es eine gibt, wieviele Eintrage der FTL verarbeiten kann, 4 Mio finde ich schon ambitioniert ....

    Für heute habe ich über 50k queries, und eine Blockrate von 62%+

    Wie sollte ich die Geschwindigkeit messen .... ?

  • Das ist ja interessant. D.h. der Pi-Hole hat schon mal generell auch Listen, die kein Regex nutzen.

    Der Benchmark ist gar nicht so einfach. Hier mal ein paar Tools: https://weberblog.net/benchmarking-dns-namebench-dnseval/

    Wichtig ist, dass man weiß was man testen will. Du wirst teilweise Antworten aus dem Cache bekommen und anderes wird abgefragt werden und gesperrte Domains braucht er gar nicht abzufragen.

    Eigentlich müsstest du alle Domains testen, die z.B. gesperrt sind und oder ein Match beim Regex erzeugen.

    Dann braucht der Resolver auch keine Anfrage zu machen und du testest ausschließlich die Performance des Programms selbst.

    Namebench hat sogar eine GUI.

    Man kann auch eine Textdatei mit Domains laden.

    Ich teste das gerade selbst, da ich mal die Leistung von Unbound wissen wollte.

    Code
      -i INPUT_SOURCE, --input=INPUT_SOURCE
                            Import hostnames from an filename or application
                            (alexa, cachehit, cachemiss, cachemix, camino, chrome,
                            chromium, epiphany, firefox, flock, galeon, icab,
                            internet_explorer, konqueror, midori, omniweb, opera,
                            safari, seamonkey, squid, sunrise)
  • DNS Benchmark by Steve Gibson

    Final benchmark results, sorted by nameserver performance:
    (average cached name retrieval speed, fastest to slowest)

    192.168.178. 6 | Min | Avg | Max |Std.Dev|Reliab%|
    ----------------+-------+-------+-------+-------+-------+
    + Cached Name | 0,004 | 0,006 | 0,009 | 0,001 | 100,0 |
    + Uncached Name | 0,020 | 0,077 | 0,271 | 0,068 | 100,0 |
    + DotCom Lookup | 0,038 | 0,071 | 0,120 | 0,028 | 100,0 |
    ---<O-OO---->---+-------+-------+-------+-------+-------+
    raspberrypi
    Local Network Nameserver


  • þ System's sole nameserver is alive and replying to queries.
    Although this system has only one DNS resolving nameserver, at least it is alive and replying to DNS queries. (If it were not, you would likely be painfully aware, since it would be difficult to accomplish anything requiring Internet access.)


    þ System nameserver is faster than ALL public alternatives.
    The DNS resolver your system is using is responding faster than any of the 100% reliable publicly available alternative DNS nameservers this benchmark utility just tested. Therefore, there would be no performance benefit from switching to any of those publicly available nameservers. However, since you only have a single system nameserver configured, it might be useful to use some of the fastest public nameservers as backups if that's possible in your situation. Please also note that this best performance appraisal assumes that this system's nameserver is 100% reliable. See the next item below for an appraisal of your nameserver's reliability.

    Note: If there appeared to be one or more faster public alternative nameservers, there was enough uncertainty created by the spread of benchmark timing results that it was not possible to be at least 95% confident that any of those faster seeming nameservers really were reliably faster than the nameserver this system is currently using. So it made no sense to alarm you about the need to change things when there was insufficient evidence.


    þ This system's nameserver is 100% reliable.
    DNS reliability is extremely important, since lookup requests that are dropped and ignored by nameservers cause significant delays in Internet access while the querying system waits for a reply. The system is then finally forced to reissue the query to the same or to backup nameservers. While your system is patiently waiting for a reply, you are impatiently waiting to get on with your Internet access.

    During this benchmark test, the system's nameserver tested returned a reply for every request sent. It doesn't get any better than that. Very nice.


    þ This system nameserver returns errors.
    This is a GOOD thing! Some DNS providers, such as OpenDNS and even the Earthlink, Roadrunner and Comcast ISPs, redirect incorrectly entered URLs to their own advertising-laden marketing-driven interception page instead of simply returning an error to the web browser. But this system's nameserver is returning errors when asked to lookup non-existent domain names.


    þ System nameserver is replying to all query types.
    During the development of this DNS Benchmark we discovered that the routers used by some pre-release testers were not returning results for the benchmark's Uncached and/or Dotcom testing queries. Even though these queries are admittedly unusual, they are completely valid. So the only conclusion was that those few routers were inherently defective. The good news here is that your nameserver is replying to these unusual but valid queries.

  • Man hat natürlich nach der ersten Abfrage einiges im Cache. Eine zweite Abfrage sollte dann mehr Cache-Hits liefern.

    Meiner Meinung nach müssten die Cache-Hits Aussage über die Performance des FTL + lookup geschwindigkeit des Caches in Unbound repräsentieren.

    Uncached ist eher interessant, wenn man wissen will, wie schnell der Resolver antwortet. Da unbound die Root-Server selbst abfragt, hat man eine etwas höhere Latenz als z.B. beim Google-DNS. Dafür ist man etwas anonymer unterwegs.

  • Man kann die Domains via sqlite3 in eine Datei exportieren: https://docs.pi-hole.net/guides/benchmark/

    Bash
    sqlite3 /etc/pihole/pihole-FTL.db "SELECT domain FROM queries LIMIT 100000;" > domains.list

    Für eindeutige Domains:

    Bash
    sqlite3 /etc/pihole/pihole-FTL.db "SELECT DISTINCT domain FROM queries LIMIT 100000;" > domains.list

    Mittels Python hab ich mir ein Script für den Bechmark erstellt:

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!