-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 18 December 2003 23:08, Meng Weng Wong wrote:
On Thu, Dec 18, 2003 at 10:43:12PM +0000,
matthew-list(_at_)bytemark(_dot_)co(_dot_)uk wrote:
| On Thursday 18 December 2003 01:47, wayne wrote:
| > Currently, the SPF spec says that a conforming implementation must
| > support include recursion depths of at least 10. I think there needs
| > to be much tighter limits placed on this.
|
| Hi Wayne, I've noticed this too, but I think it's a symptom of SPF
| copying some design mistakes in DNS as a whole: namely the tendency by
| admins (and sometimes encouragement by software design) to points names
| at names, and not at IPs.
The includes and redirects would still be needed if we switched from
a/mx/ptr to ip4; they're aimed at solving a different problem.
Hi Meng, I thinksI see the problem:
This facility is intended for use by organizations that wish to apply
the same SPF record to multiple domains. For example:
la.example.com. TXT "v=spf1 redirect=_spf.example.com"
ny.example.com. TXT "v=spf1 redirect=_spf.example.com"
sf.example.com. TXT "v=spf1 redirect=_spf.example.com"
_spf.example.com. TXT "v=spf1 mx:example.com -all"
In this example, mail from any of the three domains is described by
the same SPF record. This can be an administrative advantage.
The administrator can ensure more reliable SPF lookups for his domains by
simply duplicating the bottom TXT record four times with a script to generate
his zone files. No second query needed from the client. If the DNS server
has knowledge of the SPF format, it would know to return the _spf.example.com
record with any of the other example.com domains as "additional information";
but as things stand, it won't and the lookup will take twice as long as it
needs to.
Likewise for the include directive, why can't the administrator periodically
fetch and update his own SPF records from those he wishes to include? It
would be bad practice for a webmaster to write pages which reference external
resources which aren't under their control; the page the viewer sees may load
unpredictably as a result, or simply break. The good webmaster periodically
fetches and caches external information like news headlines etc. rather than
pointing the viewer somewhere else in hope. Why should DNS servers be
encouraged to do the same?
Regarding a/mx/ptr, Dan Boresjo made an interesting observation.
(requoted here)
This is backwards in terms of the DNS design principles as laid out in
RFC1035 section 3.6, to wit:
"The present system attempts to minimize the duplication of data in the
database in order to insure consistency. Thus, in order to find the address
of the host for a mail exchange, you map the mail domain name to a host
name, then the host name to addresses, rather than a direct mapping to host
address. This approach is preferred because it avoids the opportunity for
inconsistency. "
Applying this, the preferred mechanisms should be A, MX and PTR. There is
actually a very good case for disallowing IP4 and IP6 mechanisms entirely.
There's only a good case if you agree that this DNS design principle is
well-founded :) You can perfectly easily ensure consistency in your DNS data
without forcing clients to follow arbitrarily long chains of lookups-- the
indirection can always be handled on the server side, and in SPF's case this
would result in a far simpler protocol.
Is is that hard to programmatically generate and manage DNS records with BIND
that SPF needs to complicate itself? (genuine question, I've never used it).
- --
Matthew Bloch Bytemark Hosting
tel. +44 (0) 8707 455026
http://www.bytemark-hosting.co.uk/
Dedicated Linux hosts from 15ukp ($26) per month
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/4sSsT2rVDg8aLXQRAjjRAJ9+wKCIgKZewoU7wG4QOBQ0l4XuRQCfVvUt
+5ySS55kd1m4GYNKtSquvVc=
=WMw/
-----END PGP SIGNATURE-----
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)½§Åv¼ð¦¾Øß´ë ù1Ií-»Fqx(_dot_)com