> [On 27 Jul, @11:49, Pekka wrote in "getaddrinfo/TTL and resolver a ..."]
> > Hi,
> > 
> > draft-gieben-resolver-application-interface-00.txt sketches what kind
> > of information the application and the resolver could have through an
> > interface.  This has been discussed in dnsext at least in Feb 2004.  
> > What has been the outcome?
> 
> nothing yet, we had a lot of discussion about it, but nothing
> materialized out of it.
> 
> Personally I think some other questions also need to be answered,
> like:
> 
> o what service does the DNS actually provide?
>       (it's a naming service, but application seem to want to know 
>       more and more about the resolution process. Esp. with DNSSEC).
> 
> o where do applications start and resolvers end?
>       A seen from the text below, apps now want to know TTLs. Where
>       does it stop? 
> 
> o Each "application" (IPSEC for instance) has different (security) needs,
>       and has a different set of "local policy" rules. What kind of
>       interface is needed to allow for an application to make it's
>       own policy decisions?
> 
> Following this line of thinking we could come to the conclussion that
> an application wants to know the entire resolving chain, from the root
> down to the leave node.  But when your local resolver does caching
> this might now be available... so there you go....
> 
> > The reason why I got interested was because section 8.2 of
> > draft-ietf-dnsop-ipv6-dns-issues-08.txt (see below)  shows that the
> > application should be able to be aware of the TTL of the records,
> > easily, so that it could discard expired records from the memory if
> > it's built around in such a way that it would be feasible to do so.  
> > As it is, the applications typically query a name when they start and
> > use it forever, irregardless of the TTL.  (And if the
> > application-resolver interface needs work in any case....)
> > 
> > IMHO, it seem to be worth adding the TTL information to getaddrinfo()  
> > functions.

        I object to change getaddrinfo().  getaddrinfo() deployment is ongoing
        and i do not want two variants of getaddrinfo - one with TTL, one
        without TTL, depending on platforms.  it just leads to confusion
        with small benefit just for the sake of small set of users.
        if a user wants TTL info, she can use getrrsetbyname().

itojun
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

Reply via email to