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(a)thelounge.net> wrote:
>>
>> Am 01.06.2015 um 19:55 schrieb Jason L Tibbitts III:
>>>>>>>>
>>>>>>>> "RSB" == Ryan S Brown <ryansb(a)redhat.com>
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