North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: DNS DOS increasing?
> Date: Mon, 21 Jan 2002 11:51:17 -0700 > From: Joel Baker <[email protected]> > 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 > [email protected] 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 <[email protected]> To: [email protected] 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 <[email protected]>, or you are likely to be blocked.
|