netdev - 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 for Android: free password hash cracker in your pocket

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

Message-Id: <8DC44895-E904-4155-B7B8-B109A777F23C@oracle.com>
Date:   Thu, 16 Apr 2020 09:40:30 -0400
From:   Chuck Lever <chuck.lever@...cle.com>
To:     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

Hi David-

> On Apr 16, 2020, at 6:27 AM, David Howells <dhowells@...hat.com> wrote:
> 
> 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.  Would calling something like
> res_mkquery() use local DNS caching?
> 
>> 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.

Agreed. For example:

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).

> 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.  The
> keyring subsystem will itself dispose of dns_resolver keys that expire and
> request_key() will only upcall again if the key has expired.

Our NFS colleagues working on Solaris have noted that handling the expiry
of DNS information can be tricky. It is usually desirable to continue using
expired information when a new DNS query fails temporarily (times out, or
the network is partitioned, etc). That makes for a more robust network file
service.

> The problem for NFS is that the host IP address is the primary key for the
> superblock (see nfs_compare_super_address()).

I thought that NFSv4.1 and newer have server-provided unique information
that might be used in place of the server's IP address. This information
is supposed to be independent of a server's network addresses.

> 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()).

--
Chuck Lever