At 11:32 AM 3/24/2005 -0600, you wrote:
On Thu, 2005-03-24 at 11:03, David MacQuigg wrote:
> In addition to patches for the various name servers, it would be nice to
> have something that could be deployed rapidly, without even stopping a
> running DNS server.
I'm not sure what "stopping a running DNS server" means in this
context. DNS hosters who provide web interfaces to DNS zone maintenance
already effectively do just that, in as much as the person editing the
records doesn't need to do a kill -HUP or anything, they just need to
hit a button on a web form.
Patching a DNS server would be more disruptive than necessary. Installing
a daemon to automatically update SPF records could be done without any
disruption. The web interface you mention above is a good example.
> If we make this nice enough, admins will update their records long before
> SPF-doom arrives.
Update them to what? This putting the cart before the horse.
Update from an inefficient, manually-written SPF record to a compiled
record, generated automatically from the original SPF record, or its
subsequent updates. The update is the horse. The cart is an efficient
system for doing SPF queries, one that will never tempt virus writers to
try an attack. If updating were a big burden, then you might say, let's
wait until we see an attack, then push everyone to update. If we make it
simple and fun, many admins will update, just because it is easier than
what they did before.
Any updates have to be compatible with the current spec (or are we
thinking that there is some holy-grail of SPF mechanisms that is low DNS
load and completely describes the domain that we should add to the
spec?) Any changes to the DNS software to make them SPF aware, which
seems much more likely as being backward compatible, is not something
that someone who edits their zone files via web interface their DNS
service providers provides can do.
If there is any change that can happen to reduce the chances of this
mythical "SPF-doom" virus from having a significant impact, it is to
make a low-load SPF record that is all ipv4. But I thought we already
agreed that that removes the things that make SPF SPF and that's not
what we want. Are we pushing for RMX in that case? If so, then lets
just use RMX and be done with it.
As I understand it, the benefits of all the inefficient SPF mechanisms are
for convenience in setting up SPF records. The only thing needed by the
SPF checker is a list of IP addresses (or blocks). The SPF-compiling
daemon provides a versatile syntax for the user, and an efficient syntax
for the checker. None of this requires changing the SPF spec.
Where is the middle ground? If using any mechanisms other than ipv4
(and ipv6, of course) then the system has a DNS load/query amplification
issue. How much amplification is acceptable? I'm reading that none is
acceptable. In some cases, the amplification is directly related to
accepted DNS configuration and currently deployed network topologies
(mx:aol.com amplifies to greater than mx:leave-it-to-grace.com because
there are more queries and records behind aol's mx). Do none of the
other benefits of the SPF syntax and (comparatively) rich mechanisms
outweigh this possibility of an SPF-doom attack, an attack that may be
on SPF (either technically or socially) but isn't actually SPF's fault?
Maybe I'm misunderstanding something, but can we not keep all the mx
lookups, etc. in the user syntax, and still have the compiled record be
nothing but a list of IPs?
-- Dave
************************************************************* *
* David MacQuigg, PhD * email: dmquigg-spf(_at_)yahoo(_dot_)com *
*
* IC Design Engineer * phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* * 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. * Tucson, Arizona 85710 *
************************************************************* *