About the allow/block interaction see this example. I place "airbnb.com"
in the blockfile and "dev.staging.airbnb.com" in the allow-file
api.dev.staging.airbnb.com
▲ ▲
│ │
allow block
Essentially once a domain is matched (perfectly) the subdomains will
inherit the action linked to it until an optional override is found.
.com -> not-blocked
airbnb.com -> blocked
staging.airbnb.com -> blocked
dev.staging.airbnb.com -> not-blocked
api.dev.staging.airbnb.com -> not-blocked
Technically speaking if very the same domain (same length) is to be
found on both files, the "allow" should take precedence, but that's
probably bad config, so you'd expect the script that download lists from
Internet to look for a perfect match on both files an actually the
reference from the blockfile.
As mentioned in the OP, this subdomain blocking/unblocking is actually
the default dnsmasq behaviour, and can be reproduced using directives
like these:
address=/airbnb.com/#
server=/dev.staging.airbnb.com/#
But once again this will eventually crash or at least slow down DNS
operations as the number of addresses grows.
About the sorting I think you got a very valid point here, and I think I
went down the rabbit hole allowing multiple directives. So instead to
implement internal sorting, etc I think I'll produce a new patch soon
where only one directive is allowed. Ultimately a single file should be
good enough even for 100s of MB of blockfile. The sorting will still be
a prerequisite to allow for a fast binary-search to happen.
On 21/05/2026 21:43, Donald Muller wrote:
Interesting.
Is the allow-file used to allow domains that are in the block file?
Since you don't sort the entries how do you handle multiple block/allow
files?
------------------------------------------------------------------------
*From:* Dnsmasq-discuss <dnsmasq-discuss-
[email protected]> on behalf of Ercolino de Spiacico
<[email protected]>
*Sent:* Thursday, May 21, 2026 1:42 PM
*To:* [email protected] <dnsmasq-
[email protected]>
*Subject:* [Dnsmasq-discuss] patch: block-file/allow-file - for review/
feedback
In dnsmasq, domain filtering (for example, adblocking) currently relies
on built-in directives such as local and address. That approach works
well up to a point, but it does not scale: around 15 MB (≈700–800k
domains) the process hangs regardless of available system resources.
To take a different approach I developed this patch in attachment that
adds two new directives: block-file and allow-file. Summary of the
functionality:
- Uses mmap() to load domain lists into RAM.
- Multiple block-file directives are supported.
- Multiple allow-file directives are supported.
- Example syntax:
block-file=/path/to/blockfile#NX,1
NX is optional and can be replaced with any IP address to return instead
of NX.
The trailing ,1 is optional too, and enables logging when domains from
that file are matched (useful to log only blocked domains).
allow-file=/mnt/USB/blockfile-override,1
- Mapped files must be pre-sorted (sorting is not included in this
patch to keep the code minimal).
- Blocking/allowing behaviour mimics dnsmasq’s current semantics. For
example:
dnsmasq config:
local=/example.com/ (blocked)
server=/www.example.com/ (unblocked)
After the patch:
example.com → listed in block-file
www.example.com <http://www.example.com> → listed in allow-file
- Files are loaded one at a time and assesses against the amount of
RAM available. If Current RAM usage + blockfile >= 80% of Total RAM, the
loading is skipped and logged as a warning.
- This code does not change DNS resolution itself; it performs a very
fast name match to decide whether a query should proceed or be answered
with NX or a custom IP.
I developed this patch for FreshTomato router (dnsmasq v2.93rc1). On
those small devices I performed a functional test loading 2.2M domains
(55 MB blockfile) and reload the configuration without interruptions; no
packet drops were observed during a config when reloading. This is
already 3 time the current limit, but I haven't performed any proper
capacity testing yet, which is expected to be much higher.
Any comments or considerations are greatly appreciated.
Thanks.
_______________________________________________
Dnsmasq-discuss mailing list
[email protected]
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
