Date: Mon, 21 Jan 2002 11:51:17 -0700 From: Joel Baker <lucifer@lightbearer.com>
Yup. But there is a business drive. When technology and business conflict... you WILL find out who writes your paycheck.
Been there, done that. The saying that business = "if it works, it must be right" whereas technical = "if it isn't right, it doesn't work" comes into play.
You've never actually worked for a small business that had some basic need for serious uptime (5 9s minimum) and serious security have you? Sure, they might need only a /26 for their entire network - but that network can easily be handling a few million dollars of value every hour, 24/7/365. Yes, I've had to lay this out. It was for a financial company which had to comply with banking requirements.
I think that all agree that being filtered into oblivion (/25 and longer, some /20 and longer when dealing with certain providers) ruins one's day...
PI space is not a valid answer for a small business. For a medium-sized business (especially if they can buy out an old company and the swamp /24 that comes with it), yes, but not a small one.
...PI space is an issue when 1) renumbering or 2) upstreams refuse to punch holes in aggregation. Everyone on here knows how to deal with those without resorting to miniscule DNS TTLs.
(The answer, BTW, was to use 4 separate colocation providers, and clients which could handle SRV records, because we controlled it end-to-end. If we hadn't controlled both clients and servers, we would have been totally hosed - and the SRV TTLs were still only 5 minutes long.)
Yup. IMHO, it would have been nice if we'd never had IN MX[*], and gone with the more general IN SRV to begin with, but it was not to be. [*] Surely people didn't think that SMTP was the only service that needed failover capability?
BTW, setting minimum TTLs, while a valid *business* response, isn't a valid technical one. After all, if they said TTL 5, they had a reason for it. The fact that your *business* considers this excessive is a counter to their *business* need for having short TTLs. After all, if it were solely reasons based on technical merit... DNS resolvers scale well, as does bandwidth.
Which, if someone is paying for bandwidth and server utilization, is fine. The problem that I noted was when a client carpetbombs an origin server, as noted by James Smith. If enough people enforce min TTLs, all is fine... broken clients will learn the lesson. Else it's "why is the origin server broken?" when min TTL is enforced. One can always pass the cost on to the origin, but that's a shame when it's necessitated by sloppy client code. Maybe return a separate RR for rogue clients... one where the L7 service then tells the client to knock it off. :-)
*************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer@lightbearer.com http://users.lightbearer.com/lucifer/
Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.