Let's pretend the IETF in its wisdom decides that The New SPF
absolutely may not reuse TXT.
There is a good argument for using a new RRtype: it is good
engineering and architecture.
The good argument against using a new RRtype, of course, is that you
don't want to require the whole world to upgrade their DNS servers
just to be able to publish SPF records. This is the argument that
reflects the last 6 months of consensus on the SPF list.
Part of the reason SPF has been successful so far is because it is
really really easy for people to publish records.
Every little bit of friction slows things down.
Requiring people to upgrade nameservers would be a lot of friction.
But maybe the whole "you need to upgrade BIND" argument is actually
shakier than we thought.
Since the last time we visited this issue, RFC3597 has matured:
http://www.ietf.org/rfc/rfc3597.txt
The attached emails show the use of "TYPE1234" syntax. If we find
that the majority of nameserver software today is actually capable of
these kinds of arbitrary new records, maybe we should reevaluate the
situation.
See also
http://www.imc.org/ietf-mxcomp/mail-archive/msg01423.html
Can people please try the experiment described below? We see results
with one version of BIND; I would like to see results with TinyDNS and
others.
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/spf-draft-200405.txt
Wiki: http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
--- Begin Message ---
On Tue, May 18, 2004 at 09:15:21PM -0700, Greg Connor wrote:
|
| My feeling is that reusing TXT (or SRV or A records for that matter) is a
| bit of a hack. It is acceptable, but not optimal. Shifting the label to
| add _spf or _ep or whatever is even more of a hack. BOTH of these are
| considerably-less-than-perfect replacements for getting our own record
| type, which is IMO the RIGHT answer.
|
Could someone with Copious Free Time (probably meaning someone not
attending the meeting :) please do an experiment and try publishing a
MARID type record using existing but relatively up to date DNS server
software? And post a commentary on the process and what you learned
along the way. For purposes of this experiment, allocate yourself a
new RRtype preferably in the experimental space. Getting to the point
where a dig returns an SPF record but with rrtype=MARID would be a
win.
--- End Message ---
--- Begin Message ---
On May 20, 2004, at 4:02 AM, Meng Weng Wong wrote:
Could someone with Copious Free Time (probably meaning someone not
attending the meeting :) please do an experiment and try publishing a
MARID type record using existing but relatively up to date DNS server
software? And post a commentary on the process and what you learned
along the way. For purposes of this experiment, allocate yourself a
new RRtype preferably in the experimental space. Getting to the point
where a dig returns an SPF record but with rrtype=MARID would be a
win.
Patrik's original post included a pointer to such an experiment:
http://www.rfc.se/interop3597/
Based on the zone file
(http://www.rfc.se/interop3597/interop3597.rfc.se), the following is
possible with dig:
anewton$ dig TYPE731 type731.interop3597.rfc.se
; <<>> DiG 9.2.2 <<>> TYPE731 type731.interop3597.rfc.se
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22752
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; QUESTION SECTION:
;type731.interop3597.rfc.se. IN TYPE731
;; ANSWER SECTION:
type731.interop3597.rfc.se. 300 IN TYPE731 \# 6 ABCDEF012345
;; AUTHORITY SECTION:
interop3597.rfc.se. 300 IN NS nic.rfc.se.
;; ADDITIONAL SECTION:
nic.rfc.se. 86399 IN AAAA 2001:670:87:10::20
nic.rfc.se. 86399 IN A 195.47.254.20
;; Query time: 400 msec
;; SERVER: 10.61.32.1#53(10.61.32.1)
;; WHEN: Thu May 20 08:08:19 2004
;; MSG SIZE rcvd: 150
-andy
--- End Message ---
--- Begin Message ---
Here is one example using Bind and Net::DNS perl library. Note that I
am not a perl programmer, so the encoding/decoding functions (which is
most of the code) is not as effective as it can be I guess.
I choose the type code 64999. The record exist for the paf.se owner,
and I choose to use the SPF text string as data.
The zone contain the following:
paf.se. 3600 IN TYPE64999 \# 15 763D73706631202B6D78202D616C6C
Encoding is like this:
junior>./encode.pl "v=spf1 +mx -all"
\# 15 763d73706631202b6d78202d616c6c
Querying is like this:
junior>./query.pl paf.se
v=spf1 +mx -all
The encode and query programs follows.
paf
----- ENCODE -----
#!/usr/bin/perl
($data) = @ARGV;
$s = "";
foreach $i (split(//,$data)) {
$s = $s . sprintf("%x",ord($i));
$l++;
}
printf "\\# %d %s\n",$l,$s;
----- QUERY -----
#!/usr/bin/perl
use Net::DNS;
sub parse64999 {
($d) = @_;
($head, $len, $data) = split(/ /,$d);
$i = 0;
$res = "";
while ($i < (2*$len)) {
$ch = substr($data,$i,2);
$res = $res . chr(hex($ch));
$i+=2;
}
return $res;
}
my $res = Net::DNS::Resolver->new;
my $d = $ARGV[0];
my $query = $res->query($d,"TYPE64999");
if ($query) {
foreach my $rr ($query->answer) {
next unless $rr->type eq "TYPE64999";
print parse64999($rr->rdata) . "\n";
}
} else {
warn "query failed: ", $res->errorstring, "\n";
}
--- End Message ---