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.
We discussed, a while ago, adding TXT record support, specifically SPF
record support, to popular hosting control panel software, would be the
thing to do here. I don't know what became of that.
Then when the new admin needs to update an SPF record
written a year ago by someone who left the company, all he has to do is
download a wizard with a nice user interface, something like mxtoolbox.com.
Take a look at how that website displays the SPF record for pobox.com.
As a side note, mxtoolbox.com's SPF record thingy appears to be broken.
pobox.com's record is returned by the DNS server as two strings, which
should be concatenated:
$ dig txt pobox.com
;; ANSWER SECTION:
pobox.com. 3600 IN TXT "v=spf1 mx
mx:fallback-relay.%{d} a:webmail.%{d} a:smtp.%{d} a:outgoing.smtp.%{d}
a:discard-reports.%{d} a:discards.%{d} mx:stor" "e.discard.%{d}
a:emerald.%{d} redirect=%{l1r+}._at_.%{o}._spf.%{d}"
This makes pobox.com's record appear goofy. The mechanism should be:
mx:store.discard.%{d}
not
mx:stor
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.
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.
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?
--
Andy Bakun <spf(_at_)leave-it-to-grace(_dot_)com>