North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: DNS DOS increasing?

  • From: E.B. Dreger
  • Date: Mon Jan 21 12:23:31 2002

> Date: Mon, 21 Jan 2002 10:07:32 -0500
> From: James Smith <[email protected]>

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