nanog mailing list archives

Re: dns and software, was Re: Reliable Cloud host ?


From: Owen DeLong <owen () delong com>
Date: Thu, 1 Mar 2012 04:20:08 -0800


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

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.

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.


TTL values are a DNS resolver function;  the application consuming the
sockets API
should not be concerned about details of the DNS protocol.

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.

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.

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



Current thread: