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

dns filters: mac filtered lookups are cached #3785

Closed
awmol opened this Issue Nov 14, 2018 · 4 comments

Comments

Projects
None yet
3 participants
@awmol
Copy link

awmol commented Nov 14, 2018

When using filter = mac lookups are cached which means nodes not triggering the filter will still get the cached results

@julsemaan

This comment has been minimized.

Copy link
Contributor

julsemaan commented Nov 14, 2018

Can you provide an example of the DNS filter you've used and that isn't working.

Also, how did you get to this conclusion?
And how can we replicate the issue?

@awmol

This comment has been minimized.

Copy link

awmol commented Nov 14, 2018

First time creating an issue on github, sorry if I missed something important. I mailed the mailing list with subject:"PF 8.2.0 dns filters, mac and dnscache" and got a response from a Durand Fabrice that I should create an issue here. I'll just post parts of that email here then:

"Currently playing around with the new(?) macaddress filter in dns_filter.conf trying to use it as a way to block nodes from getting access to the captive portal when using dns_enforcement.

My plan was to add them like this and change the ipadress of the portal to something where I could just show a page like ”your device has been blocked”. Lets say that the correct IP for portal.test is 192.168.0.1.

[mac_blocklist]
filter = mac
operator = regex
value = ^(aa:bb:cc:00:11:22|00:11:22:aa:bb:cc)

[portal_test]
filter = qname
operator = regex
value = portal.test

[dnsenforcement_mac_blocklist:mac_blocklist&portal_test]
scope = dnsenforcement
answer = $qname 1 IN A 10.0.0.1
rcode = NOERROR

This works fine, a client with a mac in the mac_blocklist will get 10.0.0.1 returned BUT the next client (not in the list) asking for portal.test will also get 10.0.0.1 instead of 192.168.0.1, it seems like the PF nameserver is caching the data since I can just wait a minute or two and then a client not in the list will resolve portal.test to 192.168.0.1.

Strange enough it does not cache it the other way around, if a client not in the list asks for portal.test and it resolves to 192.168.0.1 a client that is in the mac_blocklist will still resolve portal.test to 10.0.0.1 instantly."

@julsemaan

This comment has been minimized.

Copy link
Contributor

julsemaan commented Nov 14, 2018

Ah now I get it, so the caching is not in the filters themselves, it seems pfdns performs caching of the requests.

I guess @fdurand will investigate this if he asked the issue to be posted here.

Thanks,

@fdurand

This comment has been minimized.

Copy link
Member

fdurand commented Nov 15, 2018

So we need to:

  • create a cache key with the mac address of the device and the qname.
  • reduce the cache duration (right now it set to 300s) to 60s
  • Take care of the REJECT in dns enforcement (return 127.0.0.1)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment