Re: Re: draft-ietf-marid-protocol-03 - scope questions and comments
2004-09-28 14:29:21
Koen,
At 02:33 AM 9/28/2004, you wrote:
On Sun, Sep 26, 2004 at 02:52:53PM -0600, Commerco WebMaster wrote:
> Questions for consideration -
> Should we look at employing an _spfX.domain.tld standard (where X = major
> version - e.g., 1, 2, etc), as that will help an administrator to know
what
> version the inquirer is looking for in an SPF record? After a point,
.. snip ..
The use of prefixes does not work nicely with wildcards (in my opinion
that is, others have a different opinion varying from 'it works ok' to
'you shouldnt use wildcards anyway').
Agree. Wildcards require more planning and work to implement. I am
guessing that some different DNS server implementations might address
wildcards differently or perhaps not support them at all.
> Should we maintain code and SPF TXT records that presume upward
> compatibility in the specification, such that an spf1 aware application
> will simply look at the spf part of the v= and presume that it can always
> use spf1 syntax as was understood in spf1? While I like this approach, I
..snip..
The problem is I think that then at some point you publish v=spf1,
v=spf2.0, v=spf2.1, v=spf3, etc.. Because you don't want to drop support
for older record types as long as people are requesting it. At some point
it becomes too much for the dns protocol to handle...
Agree. Which is why establishing a good answer to your original question
seems rather important.
> Alternatively, should we maintain and code presuming that we check for SPF
> TXT records based upon a need to handle an incrementing quantities of data
> strategy? By this, I mean should code look at the spf1 record, get
what it
..snip..
>
> IN TXT "v=spf1 ip4:1.2.3.4 -all"
> IN TXT "v=spf2.0/mfrom <whateverthepropersyntax> -all"
>
> Rather than:
>
> IN TXT "v=spf1 ip4:1.2.3.4 -all"
> IN TXT "v=spf2.0/mfrom <whateverthepropersyntax> ip4:1.2.3.4 -all"
>
> which repeats data, in this example for the ip4 information.
This sounds interesting I think, but you can only do this for the mfrom
scope. As soon as the scope is mfrom,helo for example, your spf1 semantics
don't map to your spf2.0 semantics anymore.
Still, if the group considers the way versions are to roll, forward
compatible semantic design might become more of a consideration. I am
still not clear as to the best way to implement in an spf1 / spf2.0
world... even less so as spfx.x versions come down the road. My concern
stems from avoiding being painted into a corner because of implementation
choices.
> Now that we are seeing a growing number of variants for the record
> structure (e.g., support for multiple implementation types, etc), would it
> be prudent to consider implementing base functionality of spf1 for as
> designed, in DNS responses (with future spf versions depending upon
> something like an HTTP based XML or predefined text formatted response)?
Don't say xml on this list please, it will induce heart-problems with many
people here :)
.. snip ..
Funny.
> imagination, rather than technology limits future SPF growth
potential. It
> seems to me that after a point, asking DNS to deliver too much data is
> going to be a problem for some or all of today's DNS server
implementations.
This has been discussed already for spf1, and was rejected because there
is a lot of overhead attached to making an http connection (setting up a
tcp session requires all these handshake packets, whereas a dns query is
just a one-shot udp exchange: one request, one reply packet). Perhaps we
could think about some kind of udp server that serves policy information,
but this greatly complicates the work to be done by spf publishers. The
beauty at this point is that it's relatively simple to publish spf
records, which allows for rapid deployment (at the sending side at least).
I certainly agree that DNS was and is entirely the right choice for
delivering spf1 data.
In my original message, I had hoped to show by example that spf1 should
continue to be served in normal DNS UDP packets as always. My thought was
that as the complexity of future versions necessitated, having possible
alternate paths to data via a provision for pointers in the syntax might
make sense to allow for getting data from other sources when it would be
too much to expect DNS to deliver such a volume of data. Basically
allowing the flexibility to extend via alternate paths if needed. A side
benefit to doing this might also be to allow TXT records to migrate users
into a formal SPF service down the road. e.g.,
IN TXT "spf1 ip4:1.2.3.4 - all"
IN TXT "spfx.x/need:service spf=1.2.3.123:nnn"
Perhaps this might be a transitional stepping stone to a more formal SPF
service specification down the road when it gets its own RR.
This all still gets back to your excellent original question about how one
should implement the next version(s)... Should it be concurrent,
incremental or something else? As we understand, overburdening DNS with
large UDP or many UDP packets is going to cause its own problems (e.g.,
fallback to TCP, etc). Deciding how future versions are to be implemented
for existing and possible future environments seems an important issue to
get resolved (or at least clear) and something I hope will be discussed
further by others on this list.
Koen
--
K.F.J. Martens, Sonologic, http://www.sonologic.nl/
Networking, embedded systems, unix expertise, artificial intelligence.
Public PGP key: http://www.metro.cx/pubkey-gmc.asc
Wondering about the funny attachment your mail program
can't read? Visit http://www.openpgp.org/
Best,
Alan Maitland
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: Re: draft-ietf-marid-protocol-03, (continued)
- Re: Re: draft-ietf-marid-protocol-03 - scope questions and comments, Commerco WebMaster
- Re: Re: draft-ietf-marid-protocol-03 - scope questions and comments, Koen Martens
- Re: Re: draft-ietf-marid-protocol-03 - scope questions and comments,
Commerco WebMaster <=
- Re: Re: draft-ietf-marid-protocol-03 - scope questions and comments, Greg Connor
- Re: draft-ietf-marid-protocol-03 - scope questions and comments, Roger Moser
- Re: Re: draft-ietf-marid-protocol-03 - scope questions and comments, william(at)elan.net
- Re: Re: draft-ietf-marid-protocol-03 - scope questions and comments, wayne
- Re: Re: draft-ietf-marid-protocol-03 - scope questions and comments, Commerco WebMaster
- Re: Re: draft-ietf-marid-protocol-03 - scope questions and comments, william(at)elan.net
- Re: Re: draft-ietf-marid-protocol-03, David
- Re: Re: draft-ietf-marid-protocol-03, william(at)elan.net
- Re: draft-ietf-marid-protocol-03, Frank Ellermann
- Re: Re: draft-ietf-marid-protocol-03, Mark Shewmaker
|
|
|