On Wed, Feb 29, 2012 at 4:02 PM, Joe Greco <jgreco@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.