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.

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

Conditional groups #1462

Open
p3lim opened this issue Apr 26, 2024 · 4 comments
Open

Conditional groups #1462

p3lim opened this issue Apr 26, 2024 · 4 comments

Comments

@p3lim
Copy link

p3lim commented Apr 26, 2024

In both upstreams and blocking we can define rules ("groups") for which source hits which resolver/blocklist, but this is not a thing for conditional.

I would like to, as an example, not allow my guest network to resolve my internal authoritative server, only upstreams and/or blocking.

An example wishful configuration (not a direct proposal):

upstreams:
  groups:
    default:
      - 1.1.1.1
    192.168.0.0/24: # my guest network
      - 1.1.1.2
blocking:
  ...
  clientGroupsBlock:
    default:
      - ads
      - gambling
    192.168.0.0/24: # my guest network
      - ads
conditional:
  mapping:
    my.internal.domain: 10.0.0.5 # my internal authoritative dns
    exposed-service.my.internal.domain: 10.0.0.5 # specific service that guests can query
  clientGroups:
    default:
      - my.internal.domain
    192.168.0.0/24: # my guest network does not get to query my entire domain
      - exposed-service.my.internal.domain

In cases where you wouldn't want a client to reach any mappings it could be an empty list, e.g:

clientGroups:
  ...
  192.168.0.0/24: []

This should be optional, both for brievity in the config and for backwards compatibility.

Copy link
Contributor

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days.

@github-actions github-actions bot added the Stale label Jul 26, 2024
@bjw-s
Copy link

bjw-s commented Jul 26, 2024

Not stale

@github-actions github-actions bot removed the Stale label Jul 27, 2024
Copy link
Contributor

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days.

@github-actions github-actions bot added the Stale label Oct 25, 2024
@Abraxos
Copy link

Abraxos commented Oct 25, 2024

Not stale, I think I might write up a PR for this... it would be my first time writing go though, so its gonna take a while to get something decent

@github-actions github-actions bot removed the Stale label Oct 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants