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 - periodI'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 cacheso 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
no, thanks, not for static configured servers and even not for workstations running inside a relieable company network
and for "avoiding a single point of failure (your LAN nameserver)" - in a proper network it don't fail - never
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
