> Option C
A third option is to re-use the existing mechanism defined by the SRV
record. Essentially you use a DNS name that is not a legal domain name to
use as a selector for the item you want to retrieve. This scheme is I
beleive compeletely compatible with the existing DNS infrastructure since
even though underscore is not a legitimate DNS character, it is a
potentially a legitimate character in Heisod, Chaos or any of the other
name
spaces the DNS might be asked to support.
I like Option C. In addition to being "cleaner", it allows you to do
interesting things like this:
_spf.foo.com. TXT "v=spf1 mx -all"
future-extension._spf.foo.com. TXT "bar=baz"
param.future-extension._spf.foo.com. CNAME zot.example.com.
What confuses me in all these examples of SRV REQUESTs is that
no one is quoting examples of actual SRV ANSWERs. An SRV REQUEST should
return an SRV ANSWER or ANSWERs, as well as other stuff if you want (and if
your DNS server will let you do it). I know only a little more about
Bind than I did yesterday, but I doubt it will let you add TXT records
to an SRV REPLY, and it won't add them itself if it follows the RFC.
The RFC (2782) gives an
example of an SRV REPLY, which looks like this (edited but no TXT
records removed!)
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
_foobar._tcp SRV 0 1 9 old-slow-box.example.com.
SRV 0 3 9 new-fast-box.example.com.
SRV 1 0 9 sysadmins-box.example.com.
SRV 1 0 9 server.example.com.
server A 172.30.79.10
old-slow-box A 172.30.79.11
sysadmins-box A 172.30.79.12
new-fast-box A 172.30.79.13
//no other services
*._tcp SRV 0 0 0 .
*._udp SRV 0 0 0 .
The 0 1 9 stuff is about port, priority and balancing (not that order)
and SPF is not really a service in the way the RFC envisages (though it
is a great service! And the RFC won't let us write _spf.foo.com, because
a protocol, _TCP or _UDP, is required).
So it seems to me the first question to ask is what pseudo-info is going
into the ANSWER if we use SRV. There may be a good answer to this,
but let's not assume that freeform text like we can and do use so
successfully for spf TXT
can just assume the role. And then any client parsing SRV ANSWERs
must not be broken by an _spf ANSWER, so you need 3 integers and
something that looks like a domain and ....
TXT can take our magic string happily, whereas SRV records
would have to somehow be encoded to reflect spf interests.
I have spent the afternoon pondering a scheme, and it looks hard.
I'm starting to prefer TXT!
Geoff
--
Servatricks Pty Ltd
Suite 406
530 Little Collins St
geoffj(_at_)thestrix(_dot_)net
0438 855 542
0414 939 523
-------
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_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡