[2018-08-07 08:40:25.466] WARN: Regex evaluation took 57.180 msec
[2018-08-07 08:40:28.953] WARN: Regex evaluation took 50.367 msec
[2018-08-07 08:40:31.185] WARN: Regex evaluation took 22.008 msec
[2018-08-07 08:40:32.512] WARN: Regex evaluation took 19.358 msec
[2018-08-07 08:40:32.927] WARN: Regex evaluation took 20.528 msec
[2018-08-07 08:40:33.429] WARN: Regex evaluation took 34.205 msec
[2018-08-07 08:40:34.025] WARN: Regex evaluation took 41.014 msec
[2018-08-07 08:40:41.010] WARN: Regex evaluation took 20.645 msec
das sind keine katastrophal hohen Werte, aber ja, es wird die Namensauflösung etwas verzögern. Wichtig zu bedenken ist aber, dass Domains nur ein mal (beim ersten Auftauchen) gegen die Liste abgeglichen werden und danach ohne Verzögerung aus dem Cache bedient werden.
Wie viele Einträge hat Deine Regex Liste? Die Zahl wird von pihole -g mit folgendem Befehl gemessen:
und wenn ich im Webinterface die Blacklist aufrufe, bekomme ich bei Regex & Wildcard blocking alle Einträge der ehemaligen Wildcardblock Liste angezeigt, allerdings formatiert zb: (^|.)000webhost.com$ (vorher nur 000webhost.com). Insgesamt sind es rund 8350 Einträge...
Ja, da gibt es einen Bug wie ich eben gesehen habe:
Das ist korrekt so. Wir haben uns nach langen Diskussionen dafür entschieden nicht zwei konkurrierende Systeme zu unterstützen. Es steht Dir natürlich frei die "alte" Wildcard-Methode weiter zu verwenden, allerdings haben wir den Support von der Weboberfläche entfernt.
Alles drei (Exakt, Wildcard und Regex) anzubieten würde gerade neue Nutzer überfordern. Zudem würden alle drei in unterschiedlichen Dateien und mit unterschiedlichen Implementierungen umgesetzt - da ist Ärger vorprogrammiert.
Über welche Größenordnungen sprechen wir denn hier? Ist der Effekt sichtbar wenn Du z.B.
dig google.de
aufrufst? Wenn ja, nur beim ersten mal oder auch bei wiederholten Abfragen der gleichen Domain?
Auf welchem System lässt Du das laufen? 8350 Einträge auf einem Raspberry Pi ist schon ein starkes Stück und ich denke dass wir da nicht mehr herausholen können. Evtl. könnte es sich lohnen allgemeinere Regex zu formulieren, die dann insgesamt weniger in der Anzahl sind.
Läuft auf nen Raspi, In der Testphase ist es auf einem QNAP. Auf beiden Geräten nach dem Update der gleiche Effekt - und ich kann es mir echt nicht erklären...
Das umstricken der Regex kommt nach und nach, aber viel weniger wird es nicht werden =)
dig google.de
; <<>> DiG 9.10.3-P4-Raspbian <<>> google.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25107
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.de. IN A
;; ANSWER SECTION:
google.de. 121 IN A 172.217.20.227
;; Query time: 63 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Aug 07 18:23:57 CEST 2018
;; MSG SIZE rcvd: 54
Es besteht immer noch die Möglichkeit dass Du wieder eine Liste im alten Format
server=/whatever.com/
in /etc/dnsmasq.d/ anlegst und nur das in der /etc/pihole/regex.list behältst wo die Regexformulierung wirklich von Vorteil ist.
Das vereint dann für Dich Geschwindigkeit mit Vielseitigkeit.
"Normale Nutzer" (im Kontrast zu "Power Nutzern" ) haben unserer Erfahrung nach eher so ein oder zwei Dutzend Wildcard Einträge. Deswegen haben wir die alte Wildcard-Syntax für solche Nutzer automatisch umwandeln lassen, denn die meisten Nutzer sind weiterhin eben "normal".
Wie lange bleiben die Seiten im Cache? Bzw. kann man die dauer einstellen? So ganz reibungslos scheint es nicht zu funktionieren. Heute morgen eine Seite mit "Verzögerung" aufgerufen , heute Abend die gleiche Verzögerung wieder =(
Wo ist das The Book of Regex? In welchem Regal stand das gleich noch?
OK, ich merke gerade, ich muss lernen =)
Nachtrag 1 - gestern Abend habe ich mal die beiden Custom IP's ausgetragen und das Conditional Forwarding wieder deaktiviert. Was soll ich sagen - alles funktioniert wie vorher .... =)
Nachtrag 2 - noch zwei kleine Schönheitsfehler in der 4er Version. Zum einen die Versionsanzeige der FTL Version vDev (FTLDNS, vDev-3e40158) und zum anderen Queries over last 24 hours sollte eventuell an das MAXLOGAGE aus der pihole-FTL.conf angepasst werden (in meinem Fall 168 Stunden)
Das ist ein guter Vorschlag, weil ich auch seeehr viele Wildcard Domains habe. Hier entsteht aber ein Problem mit dem Pihole Ereignisprotokoll.
Was muss ich ändern, damit Pihole sieht, dass eine Wildcard Domain, die, z.B., in /etc/dnsmasq.d/8-wildcard.conf ist, blockiert wurde? Der graphische Query Log zeigt keine Blockierung.
Hmm, stimmt, das geht zur Zeit nicht mehr. Bislang hatten wir das so gelöst, dass alle Wildcards in den Speicher geladen wurden und versucht wurde zu jeder Domain ein teilweisen Match zu finden. Das war jedoch ziemlich langsam und hat an mehreren Stellen für Probleme gesorgt, sodass wir das nun entfernt haben.
Der DNS Server dnsmasq lädt diese config Attribute einfach in seinen Cache und speichert nicht aus welcher Liste die Info kommt. Das grundsätzliche Problem ist nun:
Ist diese lokale Konfiguration eine Blockierung (boeses.de = NXDOMAIN) oder ist sie etwas gutes (pi.hole = 192.168.1.2)? Vielleicht kann man das so umsetzen, dass wenn das Ergebnis NXDOMAIN oder 0.0.0.0 ist, dann markieren wir es Rot.
) haben unserer Erfahrung nach eher so ein oder zwei Dutzend Wildcard Einträge. Deswegen haben wir die alte Wildcard-Syntax für solche Nutzer automatisch umwandeln lassen, denn die meisten Nutzer sind weiterhin eben "normal".