On Sun, 2004-10-03 at 09:48, John Levine wrote:
We can not keep tacking crap onto DNS and this is why I continue
with my insistence of a callback service unaffiliated with DNS.
Hmmn. We can't even get people to deploy a new DNS record type within
an existing well defined spec, and you're proposing a new scheme, with
new servers, new clients, new ports to poke holes in firewalls, and
new rules for NAT boxes to translate and forward packets. It'll also
need new caches if its data purports to be cacheable, and new tools to
create the data and debug the results. Good luck.
Thats because it means upgrading their DNS server, something no one
wants to do. This is another reason why a separate service on a
separate port, thanks for pointing this out as its one I've forgotten to
raise in the past.
Although I sympathize with your desire to move the work away from
recipients, callbacks don't move the work to the sender, they move it
to the innocent victims of address forgery. There's more spam than
real mail, and the spam all has forged return addresses.
Any sort of per message callback (or per sender callback which amounts
to the same thing in view of the random way spammers forge return
addresses), will be in practice a DDOS on forged domains. Only a
little of the spam with forged abuse.net bounces back to me, but
dealing with the existing bounces is an issue. I don't want to think
about what would happen if every recipient of all that spam started
asking me "is this one OK?" even if the question is as lightweight as
a DNS query.
The question can be as lightweight or lighter than a DNS query. Or it
can use TCP, which is step up over the vulnerable UDP method and the way
it would ideally be used.
Your argument has little weight John, since we're both talking about the
same thing, only I believe I'm not asking the unreasonable. Its time
for something new, and there is no real reason why we shouldn't have a
PROPER and DEDICATED service to deal with these questions rather than
tossing it in DNS just because thats easy. DNS is vulnerable to the
very thing you are complaining about, a DoS attack.
The only way we're going to REALLY stop spam is with a callback and I
I'm telling you, the benefits had through the callback will happily fit
where CPU cycles would have been spent on SpamAssassin.
Furthermore, who cares if someone uses it to DoS you? I assure you,
there are FAR better and MORE effective ways to take someone's
connection down, I'm personally familiar with this as both recipient and
purveyor of such attacks both on and off the LAN. This is I think my
strongest argument here and I really think it has a lot of merit.
Honestly, anyone can get in a car and kill someone by running them over,
yet you don't see any laws being passed stating that "well we should
drive because some individuals are incapable of operating a vehicle".
No, instead, we have laws to bring judgement upon the abusers.
I'm not on AOL's size of network, but part of my job is in the operation
of a network with multi-path connections to the internet backbone at
Gigabit and OC/3 speeds. We get attacked at least once a month, and the
last attack used up almost all of our bandwidth
(http://6o4.ca/ouch.html).
Do you know how many DoS attacks I've had used on me involving DNS since
I've been involved with service providers? ZERO. The attacks
inevitably always end up being SYN/SYN+ACK floods with varying packet
sizes. There are so many more effective ways of attacking people, and I
think you have and are attempting to attribute far too much concern in
this area. ESPECIALLY when we have a chance to design something
specific to its intended purpose rather than seeing DNS be abused with
yet another (tm) "feature".
CLEAR already has BATV and CSV on the table. We have plenty of people
who are ready to move them ahead as standards, and I suspect that I am
not the only one here who has no interest in new UDP services or
callbacks.
See above. It is warranted.
If you want to build some sort of C/R system, I encourage you to round
up anyone else who thinks that C/R is a good idea, charter a C/R
working group starting with SES, TMDA, and any other C/R schemes that
people are trying out, and use the IETF process to move something
ahead on the standards track. If people want to try it, fine, the
world can do some experiments to see what happens and a draft standard
will let me know which ports to block in my router.
I've already done this (designed the C/R system). Whilst you start out
with a great idea, and I'm nodding my head thinking "yeah John is right
I should take that path", you end your paragraph unnecessarily with a
rude and poor attempt a humour, one I do not appreciate and one that is
out of line with your reputation as far as I have come to know it. I
would suggest that you treat myself and the ideas I'm voicing with a tad
more respect then you just have. Doing so will aide in myself and
others actually listening to you when you have something to say.
Honestly, I shouldn't even have to say this.
Cheers,
James
--
James Couzens,
Programmer
( ( (
((__)) __\|/__ __|-|__ '. ___ .'
(00) (o o) (0~0) ' (> <) '
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :
http://mipassoc.org/pipermail/ietf-clear/attachments/20041003/239fcfe2/attachment.bin