Clear pfSense DNS Resolver Cache effect?

[VerticalTechnik]

Good day all, I hope this message finds you well.

I got a question about the pfSense DNS Resolver Cache.

Situation:
I want to flush the pfSense DNS Resolver as we have more than 2900 entries (potential data leak)

Question:

1. can I clear/flush the DNS Resolver Cache by using the "Restart Service" button?
2. what effect does this have on the network and for Staff?
3. what can go wrong within a business environment?
4. Is this just a "normal" flush DNS as when flushing within Windows with - flush dns?

Network setup:

1. we are a company running about 20 Workstations on DHCP
2. we have a LAN with own E-Mail-Server and Synology-NAS
3. our voIP Network Phones settings are hosted externally, therefore going thru firewall and WAN

Thanks in advance for any clarification of above questions, highly appreciated.

Best regards, Timothy

[johnpoz]

@VerticalTechnik restarting the service will clear the cache, as to effect on the network - for a few seconds while unbound restarts, dns would not be available.. But this really should only be a couple of seconds.

As to the 2900 entries - I would hope you would have way more than that in your cache to be honest.. Not sure why you think that is a large number to be cached? And have no idea why you think items in your cache would be a "data leak"?

when someone looks up say www.google.com, the result will be cached for the length of the ttl, so that when the next guy asks for www.google.com its just returned vs having to look it up again. 2900 seems like a low number to be honest for 20 some users. Shoot even just 1 user that has been on the internet browsing for more than a few minutes ;)

Where exactly are you coming up with that 2900 number?

You can also just flush the cache via unbound control, or just flush specific records, etc.

[23.09.1-RELEASE][admin@sg4860.home.arpa]/: unbound-control -c /var/unbound/unbound.conf 
Usage:  unbound-control [options] command
        Remote control utility for unbound server.
Options:
  -c file       config file, default is /usr/local/etc/unbound/unbound.conf
  -s ip[@port]  server address, if omitted config is used.
  -q            quiet (don't print anything if it works ok).
  -h            show this usage help.
Commands:
  start                         start server; runs unbound(8)
  stop                          stops the server
  reload                        reloads the server
                                (this flushes data, stats, requestlist)
  reload_keep_cache             reloads the server but tries to
                                keep the RRset and message cache
                                if (re)configuration allows for it.
                                That means the caches sizes and
                                the number of threads must not
                                change between reloads.
  stats                         print statistics
  stats_noreset                 peek at statistics
  stats_shm                     print statistics using shm
  status                        display status of server
  verbosity <number>            change logging detail
  log_reopen                    close and open the logfile
  local_zone <name> <type>      add new local zone
  local_zone_remove <name>      remove local zone and its contents
  local_data <RR data...>       add local data, for example
                                local_data www.example.com A 192.0.2.1
  local_data_remove <name>      remove local RR data from name
  local_zones, local_zones_remove, local_datas, local_datas_remove
                                same, but read list from stdin
                                (one entry per line).
  dump_cache                    print cache to stdout
  load_cache                    load cache from stdin
  lookup <name>                 print nameservers for name
  flush <name>                  flushes common types for name from cache
                                types:  A, AAAA, MX, PTR, NS,
                                        SOA, CNAME, DNAME, SRV, NAPTR
  flush_type <name> <type>      flush name, type from cache
  flush_zone <name>             flush everything at or under name
                                from rr and dnssec caches
  flush_bogus                   flush all bogus data
  flush_negative                flush all negative data
  flush_stats                   flush statistics, make zero
  flush_requestlist             drop queries that are worked on
  dump_requestlist              show what is worked on by first thread
  flush_infra [all | ip]        remove ping, edns for one IP or all
  dump_infra                    show ping and edns entries
  set_option opt: val           set option to value, no reload
  get_option opt                get option value
  list_stubs                    list stub-zones and root hints in use
  list_forwards                 list forward-zones in use
  list_insecure                 list domain-insecure zones
  list_local_zones              list local-zones in use
  list_local_data               list local-data RRs in use
  insecure_add zone             add domain-insecure zone
  insecure_remove zone          remove domain-insecure zone
  forward_add [+i] zone addr..  add forward-zone with servers
  forward_remove [+i] zone      remove forward zone
  stub_add [+ip] zone addr..    add stub-zone with servers
  stub_remove [+i] zone         remove stub zone
                +i              also do dnssec insecure point
                +p              set stub to use priming
  forward [off | addr ...]      without arg show forward setup
                                or off to turn off root forwarding
                                or give list of ip addresses
  ratelimit_list [+a]           list ratelimited domains
  ip_ratelimit_list [+a]        list ratelimited ip addresses
                +a              list all, also not ratelimited
  list_auth_zones               list auth zones (includes RPZ zones)
  auth_zone_reload zone         reload auth zone (or RPZ zone) from zonefile
  auth_zone_transfer zone       transfer auth zone (or RPZ zone) from master
  view_list_local_zones view    list local-zones in view
  view_list_local_data  view    list local-data RRs in view
  view_local_zone view name type        add local-zone in view
  view_local_zone_remove view name      remove local-zone in view
  view_local_data view RR...            add local-data in view
  view_local_datas view                 add list of local-data to view
                                        one entry per line read from stdin
  view_local_data_remove view name      remove local-data in view
  view_local_datas_remove view          remove list of local-data from view
                                        one entry per line read from stdin
  rpz_enable zone               Enable the RPZ zone if it had previously
                                been disabled
  rpz_disable zone              Disable the RPZ zone
Version 1.18.0
BSD licensed, see LICENSE in source package for details.
Report bugs to unbound-bugs@nlnetlabs.nl or https://github.com/NLnetLabs/unbound/issues
[23.09.1-RELEASE][admin@sg4860.home.arpa]/: 

[VerticalTechnik]

@johnpoz Thanks for your fast reply on my question.

I come up with the number of approx 2900 entries when looking up: Status / DNS Resolver
This lists in total about 2900 entries on "DNS Resolver Infrastructure Cache Speed" and "DNS Resolver Infrastructure Cache Stats".

THX regarding the hint about flushing the cache via unbound control.
I will need to look into this, still new to pfSense.

[johnpoz]

@VerticalTechnik said in Clear pfSense DNS Resolver Cache effect?:

"DNS Resolver Infrastructure Cache Speed"

that is just the infra cache - ie where unbound goes to resolve stuff. That is not actual records.. Yes this will have lots of data in it, pretty much every NS unbound talks to when it resolves something..

this will include the roots, the gltd servers any delegated ns for stuff like when you lookup something that points to a cname, then all of the authoritative NS for any specific domain, etc.

Keep in mind unbound out of the box resolves - so if your resolving I would expect the infra cache to grow to include lots of NS that you have talked too. Now if you forward, to say googledns, then the only thing listed in infra cache would be googledns.

So when you resolve something down from roots
hey roots, what is the NS for .com, ok thanks
hey NS for .com what is the ns for domain.com, ok thanks
hey ns for domain.com what is the A record for www.domain.com

So now unbound caches those results, the infra cache - now if you lookup say otherthing.domain.com unbound knows hey just go ask ns for domain.com.. It also lists info about how fast a specific NS responds, etc. so when a domain has say 2 or 3 different NS, it will try and ask the one that has answered faster in the past, etc.

If you look for say otherdomain.com - it doesn't have to ask the roots for the NS of .com, since it already has those cached. etc. etc.. As with any cache, these items will be cached for the length of the TTL before they have to be looked up again, etc.

its rare that you would want to ever flush this info.. because now you have to walk all the way down from roots to look up anything again.. But sure if you have a bad entry or old entry that ttl is still active on and you want to lookup something that has changed which you have a cache record for because the ttl was long. Sure then you can flush, but might be better to just flush the specific stuff that you feel is old data because of ttl, etc.

Restarting unbound is the sledge hammer approach, it works sure - and normally only takes a few seconds to restart.. But I would be reluctant to flush everything if your only having a specific problem with some specific thing your trying to lookup. Would sure as a quick hey I don't want to look into any details and just flush everything - then a restart of the service is a viable option sure.

[VerticalTechnik]

@johnpoz Your detailed explanation is highly appreciated and much informative.
Last Question: Does this cache store any Login-Data or any Root-Data that could lead to the Login-Data users have stored on their browser "expl. FFox Passwords" etc.?

[johnpoz]

@VerticalTechnik no its a dns cache..

It stores info it has gotten via dns queries, ie host.domain.com or ns1.domain.com, etc. How would a user password be gotten via some dns query?

[VerticalTechnik]

@johnpoz I do understand that Firewalls operate at a lower level in the network stack, examining and controlling traffic based on IP addresses, port numbers, and protocols. They don't interact with the content of the data packets exchanged, and they don't have the functionality to store or manage user credentials.
Nevertheless I want to ask and make sure that I am not missing anything that could lead to dataleak which happens in the data-passthrough, caused by pfSense-GUI itself.

[johnpoz]

@VerticalTechnik I am not exactly sure what sort of data leak your worried about.. But the dns caching of unbound is not going to be able to store get or store user passwords. Not unless they were stored in some dns TXT record somewhere in the first place.

And you are correct, pfsense is a firewall/router - it moves packets, that allowed by its firewall rules. It has no info or care to the "data" in the packets.. And normally it wouldn't even be able to even if wanted to see data that would be concerned if leaked, like user info sent to some site, etc. Since those should all be inside a encrypted https tunnel anyway these days.

Now in theory since the data moves through pfsense - it "could" be possible to do some sort of mitm with data that the user believes is inside a https end to end encryption.. But unless you have specifically set that up pfsense has no care or method of storing the encrypted data between some user and a https site. It allows access to some port or destination IP or combo of such, and routes the traffic.. It really doesn't care what is in the data of that stream. And has no way of even seeing it at all without some on purpose setup by the admin of the firewall that is not all that easy to setup anyway. Doing mitm can be a daunting task, without either user knowing its happening by trusting a CA.. or the browser complaining that hey the ssl cert is not valid for www.domain.com we are trying to go too.

https is meant to be end to end encryption, and there are many features of it to prevent or warn that something is not kosher with the connection.

[VerticalTechnik]

@johnpoz well noted, thx a lot.