lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
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