Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

block domain rules being marked/highlighted as allowed in DNS log? #1022

Closed
sinjoe opened this issue Aug 24, 2023 · 4 comments
Closed

block domain rules being marked/highlighted as allowed in DNS log? #1022

sinjoe opened this issue Aug 24, 2023 · 4 comments
Assignees
@hussainmohd-a
Labels
bug Something isn't working P0 Priority: 0 (urgent and important)

Comments

@sinjoe
Copy link

sinjoe commented Aug 24, 2023 •
edited

Setting custom blocked domain rules, it still being marked/highlighted as allowed in DNS log. If I tap on the DNS domain log, its says resolved, but drop down option shows its Block, instead of No Rule or Trust.

Is this normal?

I dont know if this is related, but custom blocked domain rules is for system app.

I dont know if someone already brought this up or this is already known. And sorry if its confusing
@ignoramous
Copy link
Collaborator

  1. Universally blocked domains showing up with answers in DNS log is fine as long as there's some app that trusts (allows) that blocked domain.

  2. If not, DNS should deny resolving universally (global) blocked domains.

We are aware of and have fixed the 2nd case in v055a (releasing in a day or two or three), if that's the bug you're reporting.

@ignoramous ignoramous added P0 Priority: 0 (urgent and important) bug Something isn't working labels Aug 24, 2023
@sinjoe
Copy link
Author

sinjoe commented Aug 25, 2023

ah ok, dont know how to categorize this issue.
I'll see if its fixed in 55a when its release.

ignoramous referenced this issue in celzero/firestack Aug 28, 2023
@ignoramous
dnsx/wall: if blockstamp is invalid, let local blocker take over
0dab5d3 
sometimes, the base64 blockstamp actually represents blocklists themselves
(when summaries are populated from caches or the alg transport), and in those
cases, fallback onto local blocklists to see if the answer must be blocked,
that is, IPs set to 0.0.0.0 or :: as the incoming  answer might be a resolved
answer (that is, not 0.0.0.0 or ::). This answer when sent to the client,
results in a TCP/UDP connection to IPs in the resolved answer. The firewall
must then decide (depending on presence of blocklists against that domain)
whether to allow / block the request.

In cases where TCP/UDP firewall must decide whether to block a domain or not,
for example when a domain is trusted by one or two apps but blocked globally,
this "may be blocked [by the firewall]" behaviour is fine. In other cases,
it is more efficient to simply block at the DNS layer with 0.0.0.0 or ::

Falling back onto local blocklists helps mitigate cases where the base64
blockstamp is set but is invalid AND the resolved answer is also left
unmodified by whoever sent the blockstamp (usually, caches), resulting in an
undesirable and avoidable "may be blocked [by the firewall]" behaviour.
@sinjoe
Copy link
Author

sinjoe commented Sep 4, 2023

it's fixed now thanks.

I was waiting for f-droid vers to be updated but reinstalled with github vers instead.

@hussainmohd-a
Copy link
Collaborator

Thanks for the update. Closing this as fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@hussainmohd-a hussainmohd-a

Labels
bug Something isn't working P0 Priority: 0 (urgent and important)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@ignoramous @hussainmohd-a @sinjoe