[150680] in North American Network Operators' Group
Re: dns and software, was Re: Reliable Cloud host ?
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Mar 1 07:26:28 2012
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAAAwwbV7TmtdokvV2ii-kE3tK336Co1LN+BVMwCxKbtEq076yw@mail.gmail.com>
Date: Thu, 1 Mar 2012 04:20:08 -0800
To: Jimmy Hess <mysidia@gmail.com>
Cc: Nanog <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Feb 29, 2012, at 10:15 PM, Jimmy Hess wrote:
> On Mon, Feb 27, 2012 at 10:57 PM, Matt Addison
> <matt.addison@lists.evilgeni.us> wrote:
>> gai/gni do not return TTL values on any platforms I'm aware of, the
>> only way to get TTL currently is to use a non standard resolver (e.g.
>> lwres). The issue is application developers not calling gai every =
time
>=20
> GAI/GNI do not return TTL values, but this should not be a problem.
> If they were to return anything, it should not be a TTL, but a time()
> value, after which
> the result may no longer be used.
>=20
> One way to achieve that would be for GAI to return an opaque structure
> that contained the IP and such a value, in a manner consumable by the
> sockets API, and adjust connect() to return an error if passed a
> structure containing a ' returned time + TTL' in the past.
>=20
>=20
> TTL values are a DNS resolver function; the application consuming the
> sockets API
> should not be concerned about details of the DNS protocol.
>=20
> All the application developer should need to know is that you invoke
> GAI/GNI and wait for a response.
> Once you have that response, it is permissible to use the value =
immediately,
> but you may not store or re-use that value for more than a few =
seconds.
>=20
> If you require that value again later, then you invoke GAI/GNI again;
> any caching details
> are the concern of the resolver library developer who has implemented =
GAI/GNI.
>=20
> --
> -JH
The simpler approach and perfectly viable without mucking up what is =
already implemented and working:
Don't keep returns from GAI/GNI around longer than it takes to cycle =
through your connect() loop immediately after the GAI/GNI call.
If you write your code to the standard of:
getaddrinfo();
/* do something with the results */
freeaddrinfo();
with a very limited amount of time passing between getaddrinfo() and =
freeaddrinfo(), then, you don't need TTLs and it doesn't matter.
The system resolver library should do the right thing with DNS TTLs for =
records retrieved from DNS and a subsequent call to getaddrinfo() within =
the DNS TTL for the previously retrieved record should be a relatively =
cheap, fast in-memory operation.
Owen
