blocky
blocky copied to clipboard
0xERR0R
[Feature Request] Blocky should start resolving DNS traffic as soon as possible
I have noticed when I first start Blocky, the DNS resolution isn't available until Blocky has parsed all the block and allow lists. On powerful machines such as x86 devices this isn't much of an issue because they can easily parse large blocklists in seconds. However, on the embedded devices (especially routers), I've noticed the initial parsing of large blocklists take quite some time (sometimes over a minute). Until Blocky has done its work, the whole network just stays down.
Would it, at least, be possible to add an option to Blocky, where we can allow DNS resolution to take place before Blocky's DNS filtering abilities kicks in?
P.S.: Since we can now control how many lists are parsed concurrently with processingConcurrency attribute. If a person set the value of processingConcurrency to 1; with plenty of large blocklists a device like a low powered router is going to take a long time to get the whole network up and running.
I think trying to cache the the lists in a fast to parse format could also be worth trying to get the same end result, lower time to first response.
Cache refresh (loading all lists) can take a long time if many lists are defined and the network is slow. It makes sense to let the server start first completely (so server can already serve DNS responses) and then start the cache refresh in the background. The server should terminate if failStartOnListError = true and error occurs -> this could be a tricky part to implement
I think trying to cache the the lists in a fast to parse format could also be worth trying to get the same end result, lower time to first response.
It would provide plenty of mitigation, however, the problem would still remain on the extremely low spec devices. Imo, DNS resolution and DNS filtration should be seen as two different entities.
Interesting thing is, when I first start Blocky, the DNS resolution is available to the app itself, but it doesn't start responding to the client's queries because the app has to parse all the filter lists first.
"DNS resolution and DNS filtration should be seen as two different entities" - I disagree with this statement 😅
My whole setup depends on the fact that requests are only resolved if filtered correctly.
If changed to resolve incorrectly unfiltered requests this should be a config option.
"DNS resolution and DNS filtration should be seen as two different entities" - I disagree with this statement 😅
My whole setup depends on the fact that requests are only resolved if filtered correctly.
If changed to resolve incorrectly unfiltered requests this should be a config option.
That's why I asked in the original request that:
Would it, at least, be possible to add an option to Blocky, where we can allow DNS resolution to take place before Blocky's DNS filtering abilities kicks in?
Another edit😂: Plus I meant that when we first start Blocky. Of course after that DNS resolution and DNS filtration have to work hand in hand to serve Blocky's purpose.
Would love to see this too, the lists are pretty huge and the pod takes quite a while to get going when rescheduled.
Changing https://github.com/0xERR0R/blocky/blob/d8c69b1f1d3a2744715e3a15f8877ee51ce5f32f/lists/list_cache.go#L113-L117
like https://github.com/adyanth/blocky/commit/3ecd2baedcdbd5f5ca53939a9f5780f6a65dfacd to convert the b.refresh(true) to a goroutine fixes the issue. But as @0xERR0R pointed out, failStartOnListError will make it complicated, I cannot think of a trivial way to fix that without getting another chan for it. I do not need that anyway, so building my own for now :)
Proposal:
Mark failStartOnListError as deprecated and introduce startStrategy as enum value.
Values would be:
- Default = current behavior with failStartOnListError: false
- FailOnError = current behavior with failStartOnListError: true
- Fast = run initial list load in goroutine
This would solve the problematic configuration scenario as the options would be mutable exclusive.