On Thu, 2005-03-24 at 10:21, David MacQuigg wrote:
It has been mentioned that the %{i} macro could be included in the query,
and then the server could reply with PASS/FAIL. I think this is a bad
idea, because all those queries are uncacheable, so this truly
circumvents the benefits that were designed into DNS. When the DDOS
attempt does happen, caching can really help lower the impact. It may be
that I didn't understand the proposal well enough.
Good point. I hadn't thought of that. Also, since the PASS/FAIL response
takes the same single IP datagram as a list of IPs, there is not much to
be gained.
One more thought on this topic: Even though we see no advantage now in
having a DNS server reply with a PASS/FAIL,
I would say there are definite advantages to using exists: with %{i}.
In fact, if the exists: mechanism is serviced in a subdomain to a stunt
server, the stunt server can customize the cache time independent of the
rest of the domain's zone(s) based on the actual query.
Say the cache time set by the stunt server is zero (or as close to zero
as DNS allows). This means that the single exists: takes ONE query, and
_doesn't_amplify_in_a_way_the_receiving_MTA_is_affected_. Since the
record is not cached, the %{i} queries don't pollute the client's DNS
cache. But the stunt server has the option of setting a small cache
time if it notices it's getting a lot of hits for the same %{i} string.
This would obviously not be as useful (in terms of load) as using ipv4
literals, but the SPF publisher has the option of putting additional
logic behind the stunt server. Maybe checking their ISP's mx records
and serving a pass/fail based on that (the stunt server does that query,
which would presumably be more "local" than the remote MTA doing the SPF
evaluation). This would limit the number of queries that SPF evaluators
(receiving MTAs) have to do, and pushes the load (both CPU and network)
to the SPF record publishers. But the problem I outlined in message
<1111616499(_dot_)23207(_dot_)18(_dot_)camel(_at_)greys> still exists, since
someone nefarious
could use macros in such a way as to make someone else's DNS server
respond with a lot of NXDOMAINs during an attack.
I'd be interested in seeing an SPF compiler that compiled to exists: and
a series of A records (if this doesn't already exist).
I was going to suggest a new mechanism that allowed a DNS query to a
specific IP and port, but this opens up a hole whereby there can be
zombie DNS servers responding to SPF requests. So I won't.
would it be a good idea to
include the IP address in the DNS query anyway? That will add a negligible
4 bytes to the query,
I believe the query would need to be text encoded, so it's at least 15
(3*4+3) additional bytes. Beside that, this only takes into account
ipv4 addresses. ipv6 addresses are bigger.
and will allow for some future use of this
information. This might be, for example, a daemon that alerts a domain
owner when an IP in their domain attempts an unauthorized use of the domain
name. ( A zombie catcher !! )
A zombie catcher was one of the original reasons to use the exists
mechanism, although it was finally settled when it was realized that
this doesn't actually gain you anything. Most likely, the zombie will
be in a place that you can't get to or will disappear before enforcement
can take place, and in many cases "enforcement" is just notifying the
ISP that one of the customers is infected.
One of the other reasons exists was considered useful was based off the
fact that you could use exists: and query logging to determine if your
SPF record is accurate or not (if you've got a large network that you
don't know how people are sending mail on).
I raise this question now, because it will be a lot easier to modify the
standard now than later.
Is this actually true? Can we get this verified? What kinds of changes
can be made to the spec at this point? I thought someone had said
effectively "not many".
--
Andy Bakun <spf(_at_)leave-it-to-grace(_dot_)com>