From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52477 invoked by alias); 2 Aug 2019 16:42:27 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 52469 invoked by uid 89); 2 Aug 2019 16:42:27 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=records X-HELO: mx1.redhat.com From: David Howells To: Florian Weimer cc: dhowells@redhat.com, jlayton@redhat.com, libc-alpha@sourceware.org Subject: Can getaddrinfo() be extended to return the record TTL MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13913.1564764142.1@warthog.procyon.org.uk> Date: Fri, 02 Aug 2019 16:42:00 -0000 Message-ID: <13914.1564764142@warthog.procyon.org.uk> X-SW-Source: 2019-08/txt/msg00050.txt.bz2 Hi Florian, The Linux kernel has an upcall to get name -> address mappings for network filesystems. The userspace side (key.dns_resolver.c in keyutils) uses getaddrinfo() to perform the lookup as this gives a greater range of sources than, say, using res_send(), giving access to NIS, YP, LDAP, files or whatever, but getaddrinfo() does not include any expiry information for the information. The userspace side of the upcall *should* be setting the expiry time on the record - but it can't as the C library doesn't give us that (and, indeed, it's not available from all sources). The userspace upcall program *does* do it for AFSDB records for the afs filesystem since those are looked up directly in the DNS and the TTL record is thus available. Anyway, looking at getaddrinfo(), it looks like the addrinfo struct should be extensible. Perhaps a flag, say AI_EXTENDED, could be provided that indicates that is replaced with a larger struct that has additional fields such as expiry time and a flag, AI_HAS_EXPIRY that indicates if the expiry time is actually set. This looks like it should work as the result records appear to be in a list rather than being an array. Another possible additional field would be a source indicator of some kind that says where the data came from (e.g. 0=file, 1=dns, 2=yp, 3=ldap, ...). If it's not possible to extend getaddrinfo() in this way, would it be possible to provide a getaddrinfo2() that returns this information through an additional parameter? Thanks, David