HaGeZi DNS Listen (alt. Link)

JeGr

Einige von euch nutzen wie ich die DNS Listen von Hagezi, die normalerweise unter

https://github.com/hagezi/dns-blocklists

zu finden waren. Microsoft / GitHub in ihrer unendlichen Co-Pilotigen Weisheit (aka: AI did AI Bullshit, yet again) hat aber zum wiederholten Mal nun sein Repository gesperrt wegen... nunja weiß man eigentlich nicht weil das jedes Mal CoPilot Bots sind mit denen er sich rumschlagen muss, weil "Hossa AI".

Da auf Codeberg oder in seinem Gitlab nicht zu 100% alle Listen gespiegelt wurden (u.a. auch wegen Dateigrößen-Einschränkungen bspw. bei den NRD Listen) hat er sich jetzt via Reddit zu Wort gemeldet und bei seinem Mitkollegen, der das Projekt maßgeblich mit ihm lenkt, einen Mirror aufgesetzt:

Reddit Post: https://www.reddit.com/r/pihole/comments/1vk5kf7/what_happened_to_hagezi/

Mirror mit Listen: https://hagezi-mirror.dnsbunker.org/

Muss man zwar wieder mal alle Listen-Links tauschen, aber vielleicht bleibt der Mirror dieses Mal einfach bestehen und wir sehen evtl. einen Wechsel weg von MS/Github zu was stabilerem, was nicht ständig durch AI versaut wird.

Cheers

slu

@JeGr ich kannte diese Liste gar nicht, wo setzt Du die ein?
Privat oder im Büro?

Edit: Oh jetzt wo die Listen online sind sehe ich das es nicht die eine Liste ist. Ich schätze mal so einfach lässt sich meine Frage gar nicht beantworten. :)

JeGr

@slu Wo setzt man DNS Blocklisten halt so ein? Überall ^^

Egal ob das jetzt Firebog, Hagezi oder andere sind. Ich möchte eigentlich mindestens einen Pihole (oder vergleichbar) sehen, der mind. einen zweistelligen Millionenbetrag an Domains auf der Liste hat, ansonsten fühle ich mich sehr unwohl.

So sieht das schön aus.

slu

@JeGr said in HaGeZi DNS Listen (alt. Link):

Überall ^^

da hast Du recht!

slu

Ich kann ja wärmstens empfehlen das tmpfs zu vergrößern bevor man die ganzen Listen aufnimmt

JeGr

@slu said in HaGeZi DNS Listen (alt. Link):

Ich kann ja wärmstens empfehlen das tmpfs zu vergrößern bevor man die ganzen Listen aufnimmt

Ich würde da eher empfehlen auf der pfS die großen Listen NICHT zu laden. AFAIR lädt unbound die immer noch oft komplett in den RAM was bei 40Mio Einträgen tötlich für viele Setups ist. Das ist auch der Grund warum ich die ganzen "topmodernen DNS Alternativen zum oldscchool Pihole" (insert marketing BS here) wieder weggeworfen habe:

bis auf AdGuard und PiHole kommt keiner der ach so modernen Top DNS Teile mit GROSSEN Listen klar
die meisten TestVMs sterben sich komplett zu Tode wenn man die Listen einpflegt
vielgelobte Projekte wie Technitium und Co laden die Listen fast immer VOLL in den RAM -> werden zu RAMfressern!
Blocky, Technitium, und ich meine auch CoreDNS hatten im Test mit @micneu fast alle nach max RAM (als Limit gesetzt waren 2GB) Verbrauch gestorben. Warum 2GB? Mein PiHole läuft wie auch AdGuard durch DNSmasq mit 15Mio Einträgen mit nur 150MB RAM:

  [✓] Building gravity tree
  [✓] Building antigravity tree

  [i] Number of gravity domains: 16448319 (15606945 unique domains)
  [i] Number of antigravity domains: 0 (0 unique domains)
  [i] Number of exact denied domains: 0
  [i] Number of regex denied filters: 1
  [i] Number of exact allowed domains: 9
  [i] Number of regex allowed filters: 15

  [✓] Optimizing database
  [✓] Swapping databases
  [✓] Cleaning up stray matter

  [✓] Done.

15,6Mio Einträge. Systemstatus? Gerne!

Das war die Last vor einem Gravity Update
Volllast beim Update, das ist OK
RAM Verbrauch während der ganzen Zeit -> ~160MB nicht mal beim Update signifikant mehr (gut wurde auch nicht viel geupdated).
freier RAM ~800MB

Die ganze VM hat 1G. Ich könnte wahrscheinlich auf 512 reduzieren aber safety first.
Das schafft kein Unbound, kein CoreDNS, kein Technitium. Leider. Aber die Oldies gewinnen hier tatsächlich haushoch.

Cheers

slu

@JeGr danke ich bin überzeugt.

Das bedeutet das DNS Setup wäre:
Client -> pfSense -> Pi-hole -> Provider DNS

anstatt:

Client -> pfSense -> Provider DNS

JeGr

@slu said in HaGeZi DNS Listen (alt. Link):

@JeGr danke ich bin überzeugt.

Das bedeutet das DNS Setup wäre:
Client -> pfSense -> Pi-hole -> Provider DNS

anstatt:

Client -> pfSense -> Provider DNS

Nein, tatsächlich ist das Setup - wie es in meiner Welt auch am meisten Sinn macht:

<Clients_aus_diversen_VLANs> --> <PiHole(s)> --> <pfSense> --> Upstream

Grund sehr simpel: PiHole und AdGuard nutzen DNSmasq daher schnell und RAM freundlich. Aber DNSmasq braucht nen Forwarder. Der ist pfSense mit Unbound, der wiederum im Resolver Mode

DNS via Root DNS Server macht und damit weniger anfällig gegen DNS Probleme an einem SPOF ist (1.1.1.1 down - egal)
DNSSEC sauber machen/beantworten kann (bei Forwarding ist die Information oft wertlos, weil dem Forwarder vertraut werden muss)
Du dann auf Unbound nach wie vor deine internen Überschreibungen und Hosts definieren kannst ohne das alles im Pihole zu managen
Du damit die Sense selbst und ggf. ein zwei spezifische Geräte vom DNS Blocking ausnehmen kannst (bspw. pfSense, Hypervisor und NAS sprechen direkt weil wenig DNS notwendig aber wichtig dass es zu Updates läuft - alles andere spricht via internem DNS Pi).

Und wenn man irgendwann total abfährt, kann man sich statt dem Unbound auch ein DoHoT Konstrukt dazwischen werfen und das dann nutzen