static versus dynamic nature of DNS: rate limiting

On Sun, Feb 22, 2004 at 10:30:52AM +0100, Hadmut Danisch wrote:
| 
| - That's one reason why I came to the conclusion that static 
|   authorization records are too limited. *We need dynamic records*
|   to allow such policies as described above. E.g. to allow your
|   machine to directly deliver not more than 20 mails to the world.
| 
|   This can't be implemented with DNS.
| 
|   With the current proposals like current-state-RMX, DMP, SPF,
|   Microsoft's CallerID, you're lost in the scenario you describe.
| 
|   Dynamic authorization or moving the evalution from the MTA to the 
|   authorization server allows to instantly detect such an intrusion. 

Traditionally, DNS data has been served from a static source: the zone file.

But the DNS protocol itself is not inherently static.  If you set the
TTL low enough, you can (mostly) defeat caching and begin to approximate
dynamic lookups.

In the early days of the web, everything was static: web servers just
pushed out .html and .gif content.  Then CGI came along, and mod_perl
came along, and today dynamically generated web pages are fast becoming
the norm.

If DNS wants to take that step, there is nothing to stop it; people have
written custom DNS servers to serve dynamic responses.  A custom DNS
server can implement precisely the kind of rate-limiting that you
described.

A few months back, SPF added the "exists" mechanism and the macro
capability.  When that happened, I had the feeling that people would
combine these features in powerful ways.

And sure enough, they did:

  http://archives.listbox.com/[email protected]/200401/0118.html

In that message, Philip Gladstone, who originally proposed the macro
feature, describes the use of an "exists" directive that talks to his
custom DNS server.  His server keeps track of the number of messages
sent from a given IP in a day, and returns an allow/deny accordingly.
It is a proof of concept that shows that you *can* teach an old DNS new
tricks.

cheers
meng