-
Notifications
You must be signed in to change notification settings - Fork 63
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.
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
Be able to use ECS in "client-blocklist" #348
Comments
Can you try #351 ? Completely untested so far. It relies on the ECS IP to be a full IP, not just a network though. |
That should be okay, no? As the blocklists can use CIDR. The normal (non ecs) client-ip is an IP as well. The difference is that the ECS mostly will be a subnet (by default in most implementations,, but depends on the sender of the query how to represent the client ip in ECS (in my case, I put a /32 IPv4 or /128 IPv6 address). Will test over the week, no access to the environment at the moment. |
The issue is if you were to use a non-/32 address in the query, this won't really work. So basically for |
Gotcha. I think we can fix this by "documentation" and point out why/how. And it is a |
Just thinking... Maybe this is better and more usable in |
That'd be more generic and useful I think, could also handle the network-ranges properly that way. Going to come up with a draft for this |
Tried Brache-348, it works. I was wondering. What if we just strip the bitmask from the ecs-ip? So it becomes a /32 or /128 anyway. I think the IP-List that is matched against should have the logic of being put together right then, no? If I block 192.168.0.0/16 it really doesn't matter what IP-Address in that subnet is in ECS, as long as it matches on subnet-level (so 192.168.0.0, 192.168.1.0, 192.168.2.0 etc will match anyway). |
That's basically what's happening currently, it'll only use the ECS address, not the associated mask. In the current implementation it's treated as a /32 (/128). So to be blocked, it's just the address part that needs to be inside 192.168.0.0/16 in your example. If the ECS IP was 192.0.0.0/8 then it wouldn't match. |
That works. Will test later today and feedback. Guess this needs clear documentation if not done already. |
It works as expected/discussed... But... Checking with my configs and needs, and implementing it, I think supporting |
As the subject says, be able to use the ECS (ENDS0) network/subnet information in the query instead of the IP where the query comes from.
I think an extra option on
client-blocklist
that saysuse-ecs = true
would be most convienent, then the IP information is matched against the blocklists.When there is no ECS, then the default-resolver should be used. Default of
use-ecs
would befalse
.Use case: When centralizing filtering of queries, you can "profile" certain groups of IP-Addresses that are behind gateways and such, instead of doing everything local (as alternative). In my case, I know my "inside" IP ranges that are used by my kids so I can filter non-kid stuff centrally on my central DNS box (which runs on Internet). Handy when not home (on travel) and I need to do modifications when not be able to go inside my home-network as example.
The text was updated successfully, but these errors were encountered: