linux-kernel - Re: What's a good default TTL for DNS keys in the kernel

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87sgh22vs4.fsf@suse.com>
Date:   Fri, 17 Apr 2020 13:31:39 +0200
From:   Aurélien Aptel <aaptel@...e.com>
To:     Chuck Lever <chuck.lever@...cle.com>,
        David Howells <dhowells@...hat.com>
Cc:     Florian Weimer <fweimer@...hat.com>,
        Linux NFS Mailing List <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

Chuck Lever <chuck.lever@...cle.com> writes:
> The Linux NFS client won't connect to a new server when the server's
> DNS information changes. A fresh mount operation would be needed for
> the client to recognize and make use of it.
>
> There are mechanisms in the NFSv4 protocol to collect server IP addresses
> from the server itself (fs_locations) and then try those locations if the
> current server fails to respond. But currently that is not implemented in
> Linux (and servers would need to be ready to provide that kind of update).

We have a very similar system in CIFS. Failover can be handled in 2 ways
(technically both can be used at the same time):

a) with DFS, the mount can have a list of possible location to connect
   to, sort of like cross-server symlinks with multiple possible
   targets. Note that the target value uses hostnames.
b) the domain controler can notice the server is down and automatically
   switch the server hostname DNS entry to a backup one with a different IP.

>> CIFS also doesn't make direct use of the TTL, and again this may be because it
>> uses the server address as part of the primary key for the superblock (see
>> cifs_match_super()).

When we try to reconnect after a failure (using (a) or just reconnecting
to same server) we resolve the host again to try to use any new IP (in
case (b) happened). This is done via upcalling using the request_key()
API.

The cifs.upcall prog (from cifs-utils) calls getaddrinfo() and sets a
key with a default TTL of 10mn [2][3] but if the system uses DNS caching
via nscd[1] there's no way to tell how long the old IP will remain in
use...

1: https://linux.die.net/man/8/nscd
2: https://github.com/piastry/cifs-utils/blob/9a8c21ad9e4510a83a3a41f7a04f763a4fe9ec09/cifs.upcall.c#L66
3: https://github.com/piastry/cifs-utils/blob/9a8c21ad9e4510a83a3a41f7a04f763a4fe9ec09/cifs.upcall.c#L783

Cheers,
-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)