F23 System Wide Change: Default Local DNS Resolver

[Petr Spacek]

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