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

[Florian Weimer <fweimer at redhat dot com>]

* David Howells:

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

I actually meant whether it enables some user-visible functionality,
like failover or service migration.

It's tricky to make this work in practice using DNS even if you know the
TTL, which is why I'm asking. 8-)

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

Status of the AD bit in the reply, indicating whether the (trusted)
recursive DNS resolver has performed DNSSEC validation or not.

Thanks,
Florian