ietf-mxcomp
[Top] [All Lists]

Re: consensus call of RR prefix

2004-09-04 14:15:57


On Fri, 3 Sep 2004, Andrew Newton wrote:

From the discussion on prefixes for the DNS record, there seems to have 
been no discernible outcome regarding the use of prefixes for the 
purposes of avoiding collisions with other DNS records (thus avoiding 
fallback to DNS over TCP).

Naturally, this issue wraps itself into both the versioning/scoping 
issue and the wildcard issue.  Based on the comments received so far, 
it is the opinion of the co-chairs that there is no consensus on how to 
handle wildcards and that most participants seem to agree that 
wildcards present a problem no matter the solution.  Based on the 
comments received so far, it is the opinion of the co-chairs that there 
is consensus on placing the "scope" in the RDATA of the record and no 
consensus on the scope being in the prefix.

Therefore, that leaves one under-discussed question: should a prefix be 
used to avoid collision with other records as one measure of preventing 
the requirement of DNS over TCP?

I'm not very strongly in favor or against using dns prefixes for TXT record
placement (my preference as indicated at the very end of message and it 
depends on other factors), but I'd like to summarize current arguments 
and points for and against using subdomain prefixes and explain how it 
all works so that others that are new to this can decide on their own.

As a reminder, in these posts:
 http://www.imc.org/ietf-mxcomp/mail-archive/msg03726.html 
 http://www.imc.org/ietf-mxcomp/mail-archive/msg03762.html
I sucessfully argued that because of how wildcards work (or don't work :) 
scoping can not rely on prefixes alone and version and scope must be part
of data portion (this chairs agree with as per their statemenet above).

It can be noted that original thread discussion about using or not using 
prefixes started from problems that may exist when user does want to publish
two types of SPF records (with presumably different version strings), like:
(*1*)     example.com. IN TXT   "v=spf1 ..."
          example.com. IN TXT   "spf2.0/pra ..."  

------------------------------
Option1
------------------------------

Since total size of RDATA space in udp dns packet is limited to approximately
480 bytes, each of the records from (*1*) would have to be smaller and be 
half that (up to say max 200 bytes to be safe), it has been said that is 
too small and hence using dns prefixes/subdomains was proposed, like:
(*2*)     _mfrom._rmx.example.com. IN TXT   "v=spf1 ..."
          _pra._rmx.example.com.   IN TXT   "spf2.0/pra ..."  

However same wildcard problem I have pointed out applies here, names that 
in case of wildcards, no matter if there are prefixes or not, you would 
have to put wildcard records in the root of the domain and thus have 
this limitation with size of records:
(*3*)     *.example.com. IN TXT   "v=spf1 ..."
          *.example.com. IN TXT   "spf2.0/pra ..."  

But as has been pointed out to me by David Blacka, that prefixes dont work 
with specific case of wildcards, doesnt mean its bad for everyone else
and use of wildcards is in general pretty rare, so we should not discard
usefullness of scenario (*2*) just because of wildcards. 

I agreed with that in this message:
  http://www.imc.org/ietf-mxcomp/mail-archive/msg03963.html
But have pointed out that there is another problem that we may have and 
that has to do with number of dns requests. In case like (*1*) when all
SPF records are located in the root of zone, in order to see all the
mail policies for different identities/scopes. a verification client 
program would only need to make one dns request for TXT record under that 
domain. But if we go with different prefixes for each scope as with (*2*), 
then client program would have to normally make two dns requests for each 
of those identities (i.e. for _pra._rmx and for _mfrom._rmx).

It can be noted that if identities have the same SPF record (and Mark 
Lentczner has pointed out that for most situations SenderID/PRA and 
SPF-Classic/Mail-From records are likely to be the same) then we maybe
able to deal with this by having records like:
(*4*)     _mfrom._rmx.example.com. IN TXT   "spf2.0/pra,mfrom ip4:10.0.0.0/24
          _pra._rmx.example.com.   IN TXT   "spf2.0/pra,mfrom ip4:10.0.0.0/24  

In that case a program looking pra or mailfrom identity scoping record 
(which it does first does not matter if records are the same) would
get the record indicating that the other identity is equivalent and would
presumably not have to do an extra dns lookup.  However this does lead to 
situation of having to enter and maintain two different but completely 
equivalent (as far as RDATA) TXT records. 

I'll note that to support programs checking SPFv1 records, additional record
may have to be added (also equivalent), so we would have:
(*5*)     _mfrom._rmx.example.com. IN TXT   "spf2.0/pra,mfrom ip4:10.0.0.0/24
          _pra._rmx.example.com.   IN TXT   "spf2.0/pra,mfrom ip4:10.0.0.0/24  
          example.com.             IN TXT   "v=spf1 ip4:10.0.0.0/24 ~all"

------------------------------
Option2
------------------------------

Another option maybe to place SPF TXT records in the same prefix no matter
what identity/scope this is, which allows to avoid collision with other 
TXT records that may exist for the domain/host:
(*6*)     _rmx.example.com. IN TXT   "spf2.0/mfrom ..."
          _rmx.example.com. IN TXT   "spf2.0/pra ..."  

In that case it is not necessary to make an extra dns lookups for multiple
identity records, nor is it necessary to have two separate records when
they are the same, as the following will work just fine:
          _rmx.example.com. IN TXT   "spf2.0/pra,mfrom ..."

However, this does mean that in case the two records are seriously different
size limitations would apply (since records share the same prefix) and records
would have to be limited to half of what they could have been. Solution
to this involves doing redirection, which would lead to 2nd dns lookup:
(*7*)  _rmx.example.com. IN TXT "spf2.0/pra redirect=_pra._rmx.example.com
       _rmx.example.com. IN TXT "spf2.0/mfrom redirect=_mfrom._rmx.example.com
       _pra._rmx.example.com. IN TXT "spf2.0/pra ...."
       _pra._mfrom.example.com. IN TXT "spf2.0/pra ...."

Additionally I'll note that there exist another possible plus side that
applies to how wildcards are entered. Because of how wildcards work normally
you need to have two separate records when using wildcards - one for domain
itself and one wildcard for all subdomains:
(*8*)     example.com.   IN TXT   "v=spf1 ..."
          example.com.   IN TXT   "spf2.0/pra ..."  
          *.example.com. IN TXT   "v=spf1 ..."
          *.example.com. IN TXT   "spf2.0/pra ..."  
In above the first two records apply to example.com itself while the 2nd
two apply to any subdomain under it (i.e. xxxx.example.com or even futher
down the tree like a.b.c.example.com) and normally these two would be the 
same, but entering wildcard seems to lead to duplicate entries.

But when using prefixes (and this applies to option 1 as well), we only need 
to have one record:
(*9*)     *.example.com. IN TXT   "v=spf1 ..."
          *.example.com. IN TXT   "spf2.0/pra ..."  

And this record would equially apply to both _rmx.example.com and to 
_rmx.xxx.example.com or to _rmx.a.b.c.example.com, etc.

------------------------------
Summary
------------------------------

So we have several options:
  Option1 is using prefixes with different one for each scope/identity
  Option2 is using prefixes but with same prefix no matter what spf scope
  Option3 is not using prefixes at all (SPF2 TXT record in zone root)
  Option4 is not using prefixes, nor even using new SPF2 version (in that 
  case scoping is achieved by using scope modifier with v=SPF1 record)

For Option1 the PROs are:
 1. Avoids collision with other TXT records for domain
 2. Avoids collision with different TXT records (except for wildcards)
    and thus avoids record size limit for different spf scope records
 3. Allows to specify wildcard entry for subdomain & domain using one record
The CONs are:
 1. Requires multiple dns lookups if SPF records for different scopes
    are different (no matter what size these records are)
 2. Requires multiple dns records if SPF records for different scopes
    are the same (no matter what size these records are)
 3. Requires separate SPFv1 records and dns lookup to support existing
    SPVv1 resolvers and libraries

For Option2 the PROs are:
 1. Avoids collision with other TXT records for domain
 2. Allows to specify wildcard entry for subdomain & domain using one record
 3. Allows to specify multiple scopes together in one record when they are same
 4. Does not require separate dns lookups for different scope records no
    matter if they are different or the same
The CONs are:
 1. Requires multuple dns lookups to avoid size limitations if multiple
    scope SPF records are different and are large
 2. Requires separate SPFv1 records and dns lookup to support existing
    SPVv1 resolvers and libraries

For Option3 the PROs are:
 1. Allows to specify multiple scopes together in one record when they are same
 2. Does not require separate dns lookups for different scope records no
    matter if they are different or the same
 3. Does not require separate dns lookups for SPFv1 records
    (but normally you would not need to do it anyway)
The CONs are:
 1. Collision problems with other (non-SPF) TXT records for the domain
 2. Requires multuple dns lookups to avoid size limitations if multiple
    scope SPF records are different and are large
 3. Requires multiple records to specify wildcard for domain & subdomains
 3. Requires separate SPFv1 records and dns lookup to support existing
    SPFv1 libraries and resolvers

For Option4 the PROs are:
 1. Allows to specify multiple scopes together in one record when they are same
 2. Does not require separate dns lookups for different scope records no
    matter if they are different or the same
 3. Does not require separate dns lookups for SPFv1 records and fully
    supports existing SPVv1 libraries and resolvers with one record
The CONs are:
 1. Collision problems with other (non-SPF) TXT records for the domain
 2. Requires multuple dns lookups to avoid size limitations if multiple
    scope SPF records are different and are large (*)
 3. Requires multiple records to specify wildcard for domain & subdomains

(*) I note that when using scoping modifier, different scope records can
    have shared data parts all in one SPF record and this allows for smaller
    size of records and avoids size limitations and necessity to do 2nd
    dns lookup in majority of situations. For more info see:
      http://www.imc.org/ietf-mxcomp/mail-archive/msg03677.html
      http://www.imc.org/ietf-mxcomp/mail-archive/msg03716.html
      http://www.imc.org/ietf-mxcomp/mail-archive/msg03731.html

------------------------------

In my opinion a lot depends on if we consider supporting existing installed
SPF v1 base important or not and consider that people using existing libraries
and publishing spfv1 records can upgrade quickly to new spf2 records or not.

If we do want to support SPFv1 base as much as possible and think that new 
scope for mailfrom will be deployed along with SPF1 records (and hence 
programs like spamassasin would do lookups for both for considerable time), 
then option4 is the best one and completely avoids these issues.

On the other hand if we think that transition to SPF2 records would be quick
and nobody would do SPF1 lookups in say one year time, then to me option2
(common prefix for all spf records) looks like the best one because compared
to option3 (no prefixes) it has the following advantages:
 1. Avoids collision with other TXT record for domain
 2. Allows to specify wildcard entry for subdomain & domain using one record
As far as everything else it is pretty much same as option3, with exception
that possibly some bad dns gui programs do not allow to enter "_" records
(but all dns servers support this just fine).

And in my opinion option1 (separate prefixes for different scopes) is the 
worst one because it leads to either multiple dns records or multiple
dns lookups and those exist no matter if record is large or small and so
would effect absolutely everybody.

Incidentally, the co-chairs note that many examples of the prefix have 
used "-marid".  We would note that "MARID" is the name of this working 
group and likely not meaningful beyond the context of discussions and 
process of this working group.  Therefore we recommend a more 
meaningful label such as "_rmx": the deduction of its meaning is easier 
and it references the genesis of the MARID idea.

I have no strong preference as far as prefix name, but I would like to 
note that _rmx has meaning if we're talking about MAIL-FROM identity
SPF scope records but in general SPF records might apply to different
identities (for example PTR scope from unified SPF) and might not not be 
related to mail-from or RMX at all. So I think general prefix such 
as _spf might be better. But I have complied with chair's request and 
have used _rmx in all above examples.

---
William Leibzon, Elan Networks:
 mailto: william(_at_)elan(_dot_)net
Anti-Spam Research Worksite:
 http://www.elan.net/~william/asrg/


<Prev in Thread] Current Thread [Next in Thread>