I've seen DOS-type behavior where a client will query a resolver for a name that doesn't exist, and the client does not accept the answer that the name does not exist and immediately sends another query, regardless of whether or not the resolver declared itself authoritative for the negative answer. -- /ak Get ready for more DOS-like behavior as systems get deployed that have 10 second TTLs in the DNS. These systems are used to provide multi-isp redundancy by pinging each upstreams router, and when a ping fails, start giving out a dns response using the other ISP IP range. Same FQDN, new IP. This of course is driven by the desire for redundancy in small businesses who make the Internet an integral part of their business plan. Either they can't get PI space and don't have (or don't want to spend) the $$$ to do BGP, or are unable to convince their upstream to cut a hole in their CIDR block and allow a 2nd party to announce that chunk (which for some is as small as /28). James H. Smith II NNCDS NNCSE Systems Engineer The Presidio Corporation
Date: Mon, 21 Jan 2002 10:07:32 -0500 From: James Smith <jsmith@PRESIDIO.com>
Get ready for more DOS-like behavior as systems get deployed that have 10 second TTLs in the DNS. These systems are used to provide multi-isp redundancy by pinging each upstreams router, and when a ping fails, start giving out a dns response using the other ISP IP range. Same FQDN, new IP.
Ughh. Constant pinging == RFC violation (I forget number). Short TTL = bad idea, stretching DNS beyond what it's meant to do. [Not intended as flamebait, but I know that not everyone will agree with this statement.]
This of course is driven by the desire for redundancy in small businesses who make the Internet an integral part of their business plan. Either they can't get PI space and don't have
PI space isn't that big of a deal for most small businesses. For service providers, yes. For other organizations that have at most half a dozen Internet-facing servers that might be renumbered every year or two, it is less of an issue.
(or don't want to spend) the $$$ to do BGP, or are unable to
??? BGP isn't that expensive.
convince their upstream to cut a hole in their CIDR block and
Find a clueful or cooperative upstream...
allow a 2nd party to announce that chunk (which for some is as small as /28).
This _is_ a problem. Returning to the issue of carpet-bombing DNS clients: IIRC, some extensions to the POP3 spec allow the POP3 server to tell clients to back off if they query too often. Perhaps something similar for DNS is in order? i.e., force clients to observe "reasonable" request intervals. (Alas, I fear that too many people would ask why DNS is broken, ignoring the issue of the renegade client.) I suppose that providers could also run transparent DNS proxies, thus saving origin servers. Then again, what is the motivation for an upstream to run a big proxy to mitigate the effects of a rogue downstream, when it doesn't directly affect them (upstream) much at all? I hate to suggest any sort of per-stream packet/bandwidth limiting anywhere, as this means keeping state. 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.
On Mon, Jan 21, 2002 at 05:08:21PM +0000, E.B. Dreger wrote:
Date: Mon, 21 Jan 2002 10:07:32 -0500 From: James Smith <jsmith@PRESIDIO.com>
Get ready for more DOS-like behavior as systems get deployed that have 10 second TTLs in the DNS. These systems are used to provide multi-isp redundancy by pinging each upstreams router, and when a ping fails, start giving out a dns response using the other ISP IP range. Same FQDN, new IP.
Ughh. Constant pinging == RFC violation (I forget number). Short TTL = bad idea, stretching DNS beyond what it's meant to do. [Not intended as flamebait, but I know that not everyone will agree with this statement.]
Yup. But there is a business drive. When technology and business conflict... you WILL find out who writes your paycheck.
This of course is driven by the desire for redundancy in small businesses who make the Internet an integral part of their business plan. Either they can't get PI space and don't have
PI space isn't that big of a deal for most small businesses. For service providers, yes. For other organizations that have at most half a dozen Internet-facing servers that might be renumbered every year or two, it is less of an issue.
*choke* 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. 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. (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.)
(or don't want to spend) the $$$ to do BGP, or are unable to
???
BGP isn't that expensive.
BGP isn't expensive. Buying swamp space so you can DO it reasonably is.
convince their upstream to cut a hole in their CIDR block and
Find a clueful or cooperative upstream...
allow a 2nd party to announce that chunk (which for some is as small as /28).
This _is_ a problem.
s/a problem/nigh-impossible/ Ever looked at the number of blocks now marked Non-Portable? Most providers I talked to in the above endeavor wouldn't allow slice-n-dice out of any of those blocks. [ snip ] 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. -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer@lightbearer.com http://users.lightbearer.com/lucifer/
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.
On Mon, 21 Jan 2002, Joel Baker wrote:
BGP isn't expensive. Buying swamp space so you can DO it reasonably is.
Last time I checked IP space was not assigned based on cash. If you have a good reason to use PI space other then your PA space, RIPE/ARIN/APNIC will assign it to you. -- Sabri Berisha "I route, therefore you are" ~ my own opinions etc ~ http://www.cluecentral.net
On Tue, Jan 22, 2002 at 10:21:16AM +0100, Sabri Berisha wrote:
On Mon, 21 Jan 2002, Joel Baker wrote:
BGP isn't expensive. Buying swamp space so you can DO it reasonably is.
Last time I checked IP space was not assigned based on cash. If you have a good reason to use PI space other then your PA space, RIPE/ARIN/APNIC will assign it to you.
What is officially approved of by the technical bodies, and what actually happens when money gets involved and people find a need to get around such bodies and are willing to pay to accomplish it, are two quite different things. Your statement is, however, not accurate. An *accurate* statement would be "If you have a reason they consider good". And even then, that doesn't get you out of the various filters across the net. Non-filtered IP space is a commodity which has been made valuble by the actions of some people with clout, as a consequence of the actions they take to protect their networks. Like any valuble commodity, people WILL find a way to aquire it for enough money. The gray market is most assuredly alive and well - and there is more than one way to play the shell game with ARIN/RIPE/APNIC to cover the facts of what you're doing, if you're in the market. Even if there wasn't - how much do you think it would take to bribe someone at ARIN? I'm sure that for *enough* money, you could manage it. They're only human. It would just raise the cost. After all, lots of folks still have a /8 - I would just *love* to see the RFC 2050 for justifying that. -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer@lightbearer.com http://users.lightbearer.com/lucifer/
participants (4)
-
E.B. Dreger -
James Smith -
Joel Baker -
Sabri Berisha