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

[Florian Weimer <fweimer at redhat dot com>]

* David Howells:

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

Is this merely a correctness thing, or does this enable some
user-visible functionality?

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

I think we would add accessor functions for that, along with an internal
flag, so that gain some flexibility in the representation.

In previous discussions, it was suggested just to increase the size of
struct addrinfo, but this is not something we can do in glibc.

> This looks like it should work as the result records appear to be in a list
> rather than being an array.

Due to the existence of freeaddrinfo, we can use the pointer itself as a
hash table key as a last resort.

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

Beyond the TTL, the security status was brought up as a suggestion.

> 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?

That definitely would be a new ABI.

New ABIs have a lead time of around three years before productization.
Is this something you could work with?

Thanks,
Florian