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.
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
> 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 havePI 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.
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
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.