Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

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 15:31:07 2002

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





Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.