Barry Leiba wrote:
> On Thu, Oct 14, 2010 at 12:45 AM, SM <s...@resistor.net> wrote:
>> At 17:31 13-10-10, Hector Santos wrote:
>>> My proposal to add more informative notes to help minimize this for
>>> the systems with the lack of DNS admin expertise on board. In
>>> particular for those with currently one existing need for a TXT record
>>> and that is SPF and incorrectly believe since its a TXT record, adding
>>> the DKIM public key data to it will work.
>> There is an assumption that people managing DNS zones will have a
>> basic understanding of DNS. �I don't think that the DKIM
>> specification should get into badly designed GUIs.
>
> I agree, more generally, that the DKIM spec can't tell people the
> right way to manage their DNS records. DKIM already separates its TXT
> records with the "_domainkey" identifier, as SPF does with _spf. If,
> given that separation, people still merge the TXT records and whatnot,
> that problem's well beyond the scope of our work to fix.
>
> I appreciate the desire to put more information in there to help, but
> we really can't be writing a tutorial on managing DNS records.
I know you realize I was not advocating information on managing DNS
records.
But what happen today, is further evidence that even DNS
administrators or software developers who are asked to write a
WEB-BASED manager for their service to support SPF and now DKIM, are
not aware of how mixing it is can be in conflict.
All I ask is that possible a simple statement or sentence in that
short section provide some insight regarding not mixing it up with
other TXT records and that wildcards should not be used for other TXT
records because this can fail the DKIM public key lookup.
In this case, a customer is using Network Solutions and in their add
TXT record, it doesn't allow a blank sub domain. The only way to do
it is to have a
subdomain: "* (ALL OTHERS)"
domain: .xyz.com
value: v=spf1 .............
Clearly, this a software bug and the customer called NS about how to
get a non-wildcard SPF record because it was interfering with their
new DKIM public and ADSP records setup. NS's (first level support)
answer was (erroneous) - "not possible. It doesn't work that way."
So sure, this has to be fixed by NS, but what I am saying is that ISP
people will also be reading the specs too perhaps to see what is
required to implement Web-based DNS Records Management tools with DKIM
and SPF support and what I am proposing is helpful insight on the
design guidelines that would avoid conflicts.
BTW, the customer (a government newsletter bulk spammer) had to delete
his SPF record to get our DKIM implementation running with verifiable
signatures. With the conflict, they were getting dkim invalid
signatures with selector DNS errors.
I'm sure they will be many customers who may not want to delete their
SPF record in order to get DKIM working. So my suggestion is to help
avoid these potential conflicts.
It is not about going deep into DNS management issues. Just the basic
DKIM public key integration issues with existing TXT records.
If you don't think that is possible, ok. I think it is, but... :)
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
