Eric S. Raymond wrote:
THE BIG ONE...the hack of using specially named subdomains and TXT has
got to
go. I can't support that. It's unclean in a way that I feel certain
will get us in deep doo-doo someday. There are at least two bad
effects:
I disagree here, IMHO the SPF proposed TXT usage is legitimate, and does
not contradict any rfc, or DNS usage.
I think it is better if SPF can be implemented without changing the DNS
specs,
IMHO changing DNS spec would only be legitimate if we want to use a
new RR
record with DNS additional processing attached.
1. It muddles together host-namespace information (which is the only thing
that ought to be to the left of IN) with attribute information (which is
the only thing that ought to be over on the right).
I do not see anything wrong with putting the attribute name at the left
of IN
in the record.
SRV (http://www.ietf.org/rfc/is a good example of an accepted standard that
makes it legitimate to use some attribute information in the host-namespace
information (the recommended use is domains like _ldap._tcp.example.com),
the underscore is proposed as a way to distinguish the "natural" hostname
space from attribute space put in the name at the left of IN.
I think your objection would be valid only if the domain names on the
left side
was not hierarchically structured (but it is), or if the left side of
DNS records
could be the result of some searchs (but not such operation exists).
2. It hijacks TXT. TXT is intended to be a comment attribute.
I do not find any "comments limitation" for TXT in any RFC,
though using it for any attributes is not explicitely endorsed, there
are a few
references that seems to make it legitimate.
- In http://www.ietf.org/rfc/rfc1183.txt,
"AFSDB records cause type A additional section processing for
<hostname>. This, in fact,
is the rationale for using a new type code, rather than trying to build
the same functionality
with TXT RRs."
It looks like the only motivation there for a new record was to reduce
DNS traffic rather
than any inapropriateness of TXT for storing attributes.
- while only an experimental RFCs: http://www.ietf.org/rfc/rfc1464.txt
is an illustration of
attribute storing in TXT records.
Finally http://www.ietf.org/rfc/rfc1035.txt which defines the TXT record
says:
"TXT RRs are used to hold descriptive text. The semantics of the text
depends on the domain where it is found."
while there seems to be a hint that TXT should be human-readable, it
does not preclude attaching
strong structure and semantics to it, (my reading is that the statement
almost explicitely
legitimate TXT records with special semantics associated with a specific
domain name).
In RFC1183, TXT usage related to the RP record is defined explicitely a
comment, but that
only applies for RP related usage.
Anyway, even if comment usage was the main intent for the creation of
TXT (I argue it is no), I would
not see any sound reason not to extend its use as long as there is no
possibility of conflict with
previous usage (which is the case thanks to _smtp_domain and/or the
syntaxical use of the v=spf...
at the start of the record which is close to rfc1464 suggestion)
I strongly urge that the proposal be modified to use the obsolete RR
types MD and MF from RFC1035.
RFC 1123 says "The MD and MF types are obsolete and MUST NOT be
implemented; in particular,
name servers MUST NOT load these types from configuration files.",
we cannot use them without modifying the DNS specs first.
While we could suggest the use of a specific new record with the same
format than a TXT, I strongly think the strategy behind SPF is to be as
easily and quickly deployed as possible. Otherwise if we were willing to
go through the hassle of significant change to the internet, I think in
the long-term, it would be better using cryptographic signing solutions
moving south as explained by Erik Corry in
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200310/0175.html.
Regards,
Loic
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡