That may be true for a SOHO environment. But for a corporate network with
numerous firewalls, my option is that firewalls should be firewalls. Tagging
core services into a security appliance is not the right solution for DNS
servers that manage to cache different results.
I like Otto's suggesti
Than you I'll have a look at your dnsdist suggestion, I hadn't considered that
yet.
I'd rather not get into an off topic argument about the various reasons for
using an FQDN in a firewall rule versus undisclosed public IP addresses. And I
have no intention of requesting that cache management i
If you are applying a firewall rule based on hostname, it makes sense that
the firewall should be the one providing DNS recursive service to the DNS
clients or to the downstream DNS caching servers, or you should resort to
URL filtering.
Best Regards,
Óscar Zovo.
A sábado, 17/09/2022, 01:01, Dj
Cache maintenace is alreayd quite a complex part of any recursor. IMO
adding cache syncing would introduce way too much complexity te be
worth the trouble to solve what in essense is a questionable firewall
rule design.
Maybe dnsdist with a packet cache in front of two recursors might
be worth
Hi Otto,
Thank you for the clarification. Yes, I'm aware that the source may change, but
TTL exists for that. So I don't think this is a valid reason to not sync cache.
As the current situation is worse:
Resolver A caches IP address 1.1.1.1 and resolver B caches IP address 2.2.2.2.
Subsequentl
Hello,
cachs syncing is not something we have and even with it (or using a
single resolver) there is an issue that records can change:
the scenario:
- a client asks the record, record gets cached
- client A asks and gets cached value,
- publisher of records changes the re
