On 1.6.2015 20:58, Reindl Harald wrote: > > Am 01.06.2015 um 20:30 schrieb Andrew Lutomirski: >> On Mon, Jun 1, 2015 at 11:02 AM, Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote: >>> >>> Am 01.06.2015 um 19:55 schrieb Jason L Tibbitts III: >>>>>>>>> >>>>>>>>> "RSB" == Ryan S Brown <ryansb@xxxxxxxxxx> writes: >>>> >>>> >>>> RSB> I disagree; for server & cloud deployments it doesn't make sense to >>>> RSB> duplicate a DNS server on *every* host, and if you care about >>>> RSB> DNSSEC you likely already run a trusted resolver. >>>> >>>> I disagree generally in the case of server deployments. >>>> >>>> Having a local caching resolver is pretty much essential, even though we >>>> all know it's just a workaround for glibc. >>> >>> no it is not in case of a serious server setup - period >> >> I'm with Jason here. Glibc's resolver is amazingly buggy, and things >> break randomly and unreproducibly when this happens. A good setup >> would have a local resolver and glibc would be configured to cache >> nothing whatsoever. Then, if you need to perform maintenance on the >> local DNS cache, you can do it by flushing your local resolver rather >> than trying to figure out how you're going to persuade every running >> program to tell glibc to flush its cache > > i never saw glibc caching any dns response, at least on Fedora, new subdomains > are working from the moment they are provisioned even if they are tried a few > seconds before > > on Apple clients you need to flush the local cache > > so with setup a dns cache on each and every machine you fuckup your network > because you introduce the same negative TTL caching affecting OSX clients for > years now Please let me clarify few things: 1) Negative caching is controlled by zone owner. If you are not happy that OSX/Windows clients cache negative answers for zones your company use - no problem, set SOA minimum field to 1 second and be done with that. Please see http://tools.ietf.org/html/rfc2308 for further details. 2) Even if you have setup with site-wide caching resolvers, the responses from internal zones are cached anyway because all resolvers are not authoritative for all zones you care about (unless you are on a really small network). I.e. if the caching is a problem you have the problem even nowadays. The positive caching is controlled by zone owner, too. If you are worried about stale data on clients, go and lower TTL to 1 second. Lowering TTL should work for all clients, no matter if they have local cache or not, i.e. including Windows/OSX. Hopefully this shows that problem is not *technically* caused by caching on clients but by inappropriate TTL settings in zones. As a network administrator, you have the power to fix that centrally, without a need to touch every single client. I hope this helps. -- Petr Spacek @ Red Hat -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
