dns and software, was Re: Reliable Cloud host ?

Tue Feb 28 04:57:30 UTC 2012

On Feb 27, 2012, at 19:10, Owen DeLong <owen at delong.com> wrote:

>
> On Feb 27, 2012, at 3:50 PM, William Herrin wrote:
>
>> On Mon, Feb 27, 2012 at 3:43 PM, david raistrick <drais at icantclick.org> wrote:
>>> On Mon, 27 Feb 2012, William Herrin wrote:
>>>> In some cases this is because of carelessness: The application does a
>>>> gethostbyname once when it starts, grabs the first IP address in the
>>>> list and retains it indefinitely. The gethostbyname function doesn't
>>>> even pass the TTL to the application. Ntpd is/used to be one of the
>>>> notable offenders, continuing to poll the dead address for years after
>>>> the server moved.
>>>
>>> While yes it often is carelessness - it's been reported by hardcore
>>> development sorts that I trust that there is no standardized API to obtain
>>> the TTL...  What needs to get fixed is get[hostbyname,addrinfo,etc] so
>>> programmers have better tools.
>>
>> Meh. What should be fixed is that connect() should receive a name
>> instead of an IP address. Having an application deal directly with the
>> IP address should be the exception rather than the rule. Then, deal
>> with the TTL issues once in the standard libraries instead of
>> repeatedly in every single application.
>>
>> In theory, that'd even make the app code protocol agnostic so that it
>> doesn't have to be rewritten yet again for IPv12.
>
> While I agree with the principle of what you are trying to say, I would argue
> that it should be dealt with in getnameinfo() / getaddrinfo() and not connect().
>
> It is perfectly reasonable for connect() to deal with an address structure.
>
> If people are not using getnameinfo()/getaddrinfo() from the standard libraries,
> then, I don't see any reason to believe that they would use connect() from the
> standard libraries if it incorporated their functionality.

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
they connect (due to aforementioned security concerns, at least in the
browser realm), instead opting to hold onto the original resolved
address for unreasonable amounts of time. Modifying gai to provide TTL
has been proposed in the past (dnsop '04) but afaik was shot down to
prevent inconsistencies in the API. Maybe when happy eyeballs
stabilizes someone will propose an API for inclusion in the standard
library that implements HE style connections. Looks like there was
already some talk on v6ops headed this way, but as always there's
resistance to standardizing it.

~Matt