In <20041111232607(_dot_)GA9953(_at_)slot(_dot_)hollandcasino(_dot_)net> Alex
van den Bogaerdt <alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net> writes:
Sure, we need to really think about this. Separating the version could,
for instance, result in being able to query for a record that checks
RFC821 addresses, RFC822 addresses, or both.
As an example to start discussing: The two low bits (------10) could signal:
00: actively not participating in email (alias for "-all" ?)
01: check rfc821 headers only
10: check rfc822 headers only
11: check either or both
Querying for version 0x03 returns 0x01, 0x02 or 0x03 records.
Querying for version 0x01 returns 0x01 or 0x03 records but not 0x02.
0x00 will always be returned (if present) to any query. This could be
an implicit record (our much desired wildcard) if and when DNS servers
are configured to provide it.
DNS queries don't work this way. You can not do subqueries based off
data in the RR, only the domain name, the RR type and the Class (which,
effectively, is always "IN").
Creating a new RR with a version number wouldn't be of any real use.
It wouldn't save many bytes, and it would require more changes to SPF
implementations and DNS servers than just re-using the TXT format.
*IF* the DNS folks insist on having a binary format for a new SPF RR,
then something more extensive like the libspf2 byte-code would be the
way to go. (Oh, yeah, it handles unknown modifiers like ses= and
accredit= just fine.)
In my opinion, it doesn't make any difference what format the new SPF
RR will be as it will never be widely used. In this case, I
completely agree with Phillip Hallam-Baker, Harry Katz, and Jim Lyon.
-wayne