From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90116 invoked by alias); 2 Aug 2019 19:33:18 -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 90108 invoked by uid 89); 2 Aug 2019 19:33:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,MIME_QP_LONG_LINE,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=mins, H*f:sk:87v9vfc, H*i:sk:87v9vfc X-HELO: mx1.redhat.com From: David Howells In-Reply-To: <87v9vfcwkm.fsf@oldenburg2.str.redhat.com> References: <87v9vfcwkm.fsf@oldenburg2.str.redhat.com> <13914.1564764142@warthog.procyon.org.uk> To: Florian Weimer Cc: dhowells@redhat.com, jlayton@redhat.com, libc-alpha@sourceware.org Subject: Re: Can getaddrinfo() be extended to return the record TTL MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26320.1564774393.1@warthog.procyon.org.uk> Content-Transfer-Encoding: quoted-printable Date: Fri, 02 Aug 2019 19:33:00 -0000 Message-ID: <26321.1564774393@warthog.procyon.org.uk> X-SW-Source: 2019-08/txt/msg00055.txt.bz2 Florian Weimer wrote: > > 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). >=20 > Is this merely a correctness thing, or does this enable some > user-visible functionality? The kernel's DNS cache's ordinary records currently don't have their expiry set as I don't have anything to set it to - with the result that the entries in the cache never expire and have to be manually invalidated if you want t= hem to be reread. I can, and probably should, set the default timeout to something reasonably small and finite (say 10 mins) in the absence of such data, but it would be better, I think, to set the TTL from the record (if available). So, yes, this is actually causing a problem. > > Another possible additional field would be a source indicator of some k= ind > > that says where the data came from (e.g. 0=3Dfile, 1=3Ddns, 2=3Dyp, 3= =3Dldap, ...). >=20 > Interesting. It probably would have to be the name of the service > module (not a number). That would be fine. > Beyond the TTL, the security status was brought up as a suggestion. Interesting. What does that convey? > New ABIs have a lead time of around three years before productization. > Is this something you could work with? Well, I could put a better/configurable default in the code as a stopgap, so there is a workaround. Thanks, David