In message <cap-gugv09hf7in+vzbkpgk0rr1q4gpmmo5jqreuzvej+ewz...@mail.gmail.com>, William Herrin writes: > On Tue, Feb 28, 2012 at 12:45 AM, Mark Andrews <ma...@isc.org> wrote: > > getaddrinfo was designed to be extensible as was struct > > addrinfo. Part of the problem with TTL is not [all] dat= > a sources > > used by getaddrinfo have TTL information. > > Hi Mark, > > By the time getaddrinfo replaced gethostbyname, NIS and similar > systems were on their way out. It was reasonably well understood that > many if not most of the calls would return information gained from the > DNS. Depending on how you look at it, choosing not to propagate TTL > knowledge was either a belligerent choice to continue disrespecting > the DNS Time To Live or it was fatalistic acceptance that the DNS TTL > isn't and would not become functional at the application level.
No. Propogating TTL is still a issue especially when you do not always have one. You can't just wave the problem away. As for DNS TTL addresses are about the only thing which have multiple sources. You also don't have to use getaddrinfo. It really is designed to be the first step in connecting to a host. If you need to reconnect you call it again. > Still works fine deeper in the query system, timing out which server > holds the records though. > > > > Additionally for > > many uses you want to reconnect to the same server rather > > than the same name. > > The SRV record was designed to solve that whole class of problems > without damaging the operation of the TTL. No one uses it. You don't need to know the TTL to use SRV. > It's all really very unfortunate. The recipe for SOHO multihoming, the > end of routing table bloat and IP roaming without pivoting off a home > base all boils down to two technologies: (1) a layer 4 protocol that > can dynamically rebind to the layer 3 IP address the same way IP uses > ARP to rebind to a changing ethernet MAC and (2) a DNS TTL that > actually works so that the DNS supports finding a connection's current > IP address. DNS TTL works. Applications that don't honour it arn't a indication that it doesn't work. > Regards, > Bill Herrin > > -- > William D. Herrin ................ her...@dirtside.com b...@herrin.us > 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> > Falls Church, VA 22042-3004 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
