dns and software, was Re: Reliable Cloud host ?

Thu Mar 1 13:25:14 UTC 2012

> 
> On Wed, Feb 29, 2012 at 4:02 PM, Joe Greco <jgreco at ns.sol.net> wrote:
> > In the specific case of TTL, the problem is made much worse due to the
> > way most client code has hidden this data from developers, so that many
> > developers don't even have any idea that such a thing exists.
> >
> > I'm not sure how to see that a design failure of the TTL mechanism.
> 
> Hi Joe,
> 
> You shouldn't see that as a design failure of the TTL mechanism. It
> isn't. It's a failure of the system of which DNS TTL is a component.
> The TTL component itself was reasonably designed.

Think that's pretty much what I said.

> The failure is likened to installing a well designed sprinkler system
> (the DNS with a TTL) and then shutting off the water valve
> (gethostbyname/getaddrinfo).

No, the water still works as intended.  I think your analogy starts to
fail here.  It's more like expecting a water suppression system to put
out a grease fire.  The TTL mechanism is completely suitable for what
it was originally meant for, and in an environment where everyone has
followed the rules, it works fine.  If you take a light office space
with sprinklers and remodel it into a short order grill, the fire
inspector will require you to rework the fire suppression system to
an appropriate system.

Problem is, TTL is a relatively light-duty system that people have felt
free to ignore, overload for other purposes, etc., but there's no fire
inspector to come around and tell people how and why what they've done
is broken.  In the case of TTL, the system is even largely hidden from
users, so that it is rarely thought about except now and then on NANOG,
dns-operations, etc.  ;-)  No wonder it is even poorly understood.

> > I don't see developers ignoring DNS and hardcoding IP addresses into
> > code as a failure of the DNS system.
> 
> It isn't. It's a failure of the sockets API design which calls on
> every application developer to (a) translate the name to a set of
> addresses with a mechanism that discards the TTL knowledge and (b)
> implement his own glue between name to address mapping and connect by
> address.
> 
> It would be like telling an app developer: here's the ARP function and
> the SEND function. When you Send to an IP address, make sure you
> attach the right destination MAC. Of course the app developer gets it
> wrong most of the time.

That's correct - and it doesn't imply that the system that was engineered
is faulty.  In all likelihood, the fault lies with what the app developer
was told.

You originally said:

"If three people died and the building burned down then the sprinkler
system didn't work. It may have sprayed water, but it didn't *work*."

That's not true.  If it sprayed water in the manner it was designed to,
then it worked.  If three people took sleeping pills and didn't wake up
when the alarms blared, and an arsonist poured ten gallons of gas
everywhere before lighting the fire, the system still worked.  It failed
to save those lives or protect the building from burning down, but I
am aware of no fire suppression systems that realistically attempts to
address that.  It is an unreasonable expectation.

I have a hard time seeing the many self-inflicted wounds of people who
have attempted to abuse TTL for various purposes as a failure of the TTL
design.  The design is reasonable.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.