This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Can getaddrinfo() be extended to return the record TTL


Florian Weimer <fweimer@redhat.com> 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).
> 
> 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 them
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 kind
> > that says where the data came from (e.g. 0=file, 1=dns, 2=yp, 3=ldap, ...).
> 
> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]