[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87v9lzu3cx.fsf@oldenburg2.str.redhat.com>
Date: Thu, 16 Apr 2020 12:33:34 +0200
From: Florian Weimer <fweimer@...hat.com>
To: David Howells <dhowells@...hat.com>
Cc: linux-nfs@...r.kernel.org, linux-cifs@...r.kernel.org,
linux-afs@...ts.infradead.org, ceph-devel@...r.kernel.org,
keyrings@...r.kernel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: What's a good default TTL for DNS keys in the kernel
* David Howells:
> Florian Weimer <fweimer@...hat.com> wrote:
>
>> You can get the real TTL if you do a DNS resolution on the name and
>> match the addresses against what you get out of the NSS functions. If
>> they match, you can use the TTL from DNS. Hackish, but it does give you
>> *some* TTL value.
>
> I guess I'd have to do that in parallel.
Not necessary. You can do the getaddrinfo lookup first and then perform
the query.
> Would calling something like res_mkquery() use local DNS caching?
Yes (but res_mkquery builds a packet, it does not send it).
>> The question remains what the expected impact of TTL expiry is. Will
>> the kernel just perform a new DNS query if it needs one? Or would you
>> expect that (say) the NFS client rechecks the addresses after TTL expiry
>> and if they change, reconnect to a new NFS server?
>
> It depends on the filesystem.
>
> AFS keeps track of the expiration on the record and will issue a new lookup
> when the data expires, but NFS doesn't make use of this information.
And it will switch servers at that point? Or only if the existing
server association fails/times out?
> The keyring subsystem will itself dispose of dns_resolver keys that
> expire and request_key() will only upcall again if the key has
> expired.
What's are higher-level effects of that?
I'm still not convinced that the kernel *needs* accurate TTL
information. The benefit from upcall avoidance likely vanishes quickly
after the in-kernel TTL increases beyond 5 or so. That's just my guess,
though.
Thanks,
Florian
Powered by blists - more mailing lists