Messages

It seems there is no way I can disable the Qfeeds domain blocklist - the content of dnsbl.json is still there and used after uninstalling the Qfeeds plugins completely.

The only way I found is to recreate an empty dnsbl.json and restart Unbound.

I had two lists, but both disabled. I deleted them and still get ~235000 entries in the blocklist, maybe those are the Qfeeds items.

However, they are there regardless of me having "Register domain feeds" enabled or disabled. How do you register your blocklist into Unbound technically? This looks like there is a downloaded domain list that is injected into Unbound, but after disabling it, the list persists.

I found /var/unbound/data/dnsbl.json that seems to have the data included. I wonder how the different blocklists and the Qfeeds lists are integrated without interfering with one another...

But the instructions given there will not work for this specific setup, because the ufs partition is not the last one on the disk. The swap partition is in the way for the enlargement and has to be deleted first.

Nein, das ist nicht notwendig. Ich würde mal schauen, welchen Weg die DNS-Update-Pakete nehmen (also TCPdump auf der OpnSense). Vielleicht ist noch etwas falsch konfiguriert.

Die einzige Möglichkeit wäre, dass der DNS-Server, dem Du die Updates schickst, zufällig in Deinem internen Unbound-DNS auf die interne IP umgelenkt wird. Deswegen muss man dafür einen eigenen DNS-Namen nehmen, der ungleich dem Webserver-DNS-Namen ist, z.B. ns.domain.de vs. www.domain.de. Und dann trägt man die lokale IP nur für www.domain.de ein, nicht für ns.domain.de.

Yep. But I cannot choose a "Qfeeds" blocklist and I also do not see anything special in the generated Unbound config files, so this seems to have no effect.

"!" bedeutet Negation, also die Checkbox "Destination / Invert" zu setzen. Und dann trägt man die Host-IP in das die Destination als "Single Host or IP" ein. Damit ist alles, was NICHT HOST-IP ist, von der Regel betroffen, nicht mehr "any". Die Einschränkung auf Deine lokalen Clients braucht es gar nicht, weil "any" genausogut funktioniert - wer soll denn sonst fragen?

Schau Dir einfach mal die Bilder im ersten Post des verlinkten Threads an, da sieht man, dass das "Destination / Invert" in der Regelliste zu einem vorangestellten "!" führt, z.B. in "! LAN Address".


Und nein, nochmal, den DNS-Server musst Du nicht ändern. Für die DNS-Requests kann er ganz normal die OpnSense nutzen. Die DNS Updates werden normalerweise sowieso an den authoritativen DNS-Server für die Domain abgesetzt - das ist meist einer im Internet.

Dummerweise sorgt die Redirect-Regel aber dafür, dass JEDER DNS-Request umgebogen wird, neben den DNS-Queries auch die DNS-Updates, die weiterhin nach draußen gehen sollen. Das liegt einfach daran, dass man nur auf den UDP Port 53 matcht, und der ist bei beiden Varianten gleich. Man müsste ins Protokoll hineinschauen, um zu sehen, dass es Update und keine Queries sind, aber das geht nicht so einfach.

Wenn Du die Regel komplett deaktivierst und Deine Clients sich "wohl verhalten", würden sie ja per DHCP auch die OpnSense als DNS-Server genannt bekommen und diese ohnehin nutzen. Die ganze Umleiterei macht man doch nur "on top", um das bei böswilligen oder fehlkonfigurierten Clients zu erzwingen.

Was ist meine ist, dass man das normalerweise so macht, dass man einen Port Forward für Traffic mit Zielport UDP 53 auf 127.0.0.1:53 macht. Dadurch würde jeder DNS-Request von internen Quellen auf die OpnSense umgebogen. Die einzige Änderung ist, dass man in der Regel die Quelle mit !HOST-IP einträgt. Damit ist HOST-IP als einziger von diesem "Umbiegen" ausgenommen.

Ist alles hier beschrieben, inklusive dieses Problems, ziemlich am Ende des Threads.

Es geht doch nur um eine Ausnahme für den Redirect für den Rechner, der das Zertifikat beantragt. Der Redirect soll doch nur dazu dienen, dass kein externer DNS-Server genutzt werden kann, sondern alle Requests auf Zielport 53 auf die OpnSense umgebogen werden (somit auch die DNS Updates).

Durch die Einschränkung erlaubst Du doch nur einem einzigen Host, diese Beschränkung zu umgehen. Das heißt nicht, dass er nicht als DNS-Resolver weiterhin die OpnSense nehmen DARF - nur eben nicht MUSS. Den externen DNS nutzt er doch nur für den DNS-Update. Klar, er KÖNNTE dann auch andere DNS-Resolver nutzen, aber da es sich mutmaßlich um einen Server handelt, wird das doch eher nicht passieren, oder?

Was man mit einer solchen Regel typischerweise erzwingen will, ist, dass IoT-Geräte oder Smartphones den eigenen DNS nutzen müssen.

Wie gesagt, wenn Du den DNS-Redirect wegnimmst, kannst Du ja den DNS update direkt absetzen. Das geht an jedem lokalen DNS-Sever vorbei und bedarf nur einer Regeleinschränkung im Port-Forwarding.

This is supposed to work with Unbound according to the docs, but even after I checked "Register domain feeds", I cannot see anything w/r to Qfeeds in the Unbound blocklists, although both sets (IPs and domains) seem to be licensed.

Oh, I never used those, didn't not know they exist. Are they in a useable format for Unbound?

Machst Du DNS-01 Verifikation? Falls ja, die DNS Updates werden weder durch Unbound noch durch DNSmasq durchgeleitet - beide Server können nur DNS-Queries verarbeiten. Ich habe das gemerkt, als ich versucht habe, mit einem Server "hinter" OpnSense einen DNS-01 update per RFC2136 durchzuführen, während ich alle DNS-Requests über den lokalen Unbound geforwardet hatte. Ich musste für den betroffenen Host eine Ausnahme eintragen.

Probably. The Qfeeds list contain IPs, not domains, so you have to use the alias in a firewall rule, not in a DNS blocklist.

Good question, but I think you could create that rule as the first interface rule as well. Creating a floating rule as suggested only makes extra sure it gets processed first.

It is true that you can inspect the rules. What I miss is the quick overview where you can see the list of rules with all preceeding rules before them like so:

You cannot view this attachment.