Re: [ietf-dkim] wildcards, draft-ietf-dkim-rfc4871bis-03 submitted

2011-02-17 Thread Wietse Venema
John Levine:
  2. Advice about wildcards in TXT records.
  Proposed change: Add a note in section 6.1.2 warning about the effect
  of wildcard TXT records on finding DKIM key records.
 
 Section 3.6.2.1 currently says:
 
   INFORMATIVE OPERATIONAL NOTE: Wildcard DNS records (e.g.,
   *.bar._domainkey.example.com) do not make sense in this context
   and should not be used.  Note also that wildcards within domains
   (e.g., s._domainkey.*.example.com) are not supported by the DNS.
 
 That first sentence is just plain wrong.  I have been using wildcard
 DNS records of exactly that form for months, and they work fine.  I
 put a unique selector on each message, and when I get around to it
 will extract the DNS lookup info to figure out how many people are
 looking at my signatures.  This may be morally reprehensible, but it
 does make sense.
 
 I suggest we delete the whole note.

I suggest replacing this with the replacement 6.1.2 text proposed
below, but I would not object to John's proposed changes either.

So that's a +1 from me.

Wietse

 Section 6.1.2 says:
 
NOTE:  The use of wildcard TXT records in the DNS will produce a
   response to a DKIM query that is unlikely to be valid DKIM key
   record.  This problem applies to many other types of queries, and
   client software that processes DNS responses needs to take this
   problem into account.
 
 This is only true if the name of the record doesn't include
 _domainkey, so *._domainkey.example.com or
 *.foo._domainkey.example.com is OK, but *.example.com is not.  So I
 suggest we rewrite it as:
 
NOTE: Wildcard TXT records whose names are not in the _domainkey
   subdomain will generally produce a response to a DKIM query that
   is not a valid DKIM key record.  This problem applies to many
   other types of queries, and client software that processes DNS
   responses needs to take this problem into account.
 
 Regards,
 John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for 
 Dummies,
 Please consider the environment before reading this e-mail. http://jl.ly
 ___
 NOTE WELL: This list operates according to 
 http://mipassoc.org/dkim/ietf-list-rules.html
 
 

___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] wildcards, draft-ietf-dkim-rfc4871bis-03 submitted

2011-02-16 Thread John Levine
 2. Advice about wildcards in TXT records.
 Proposed change: Add a note in section 6.1.2 warning about the effect
 of wildcard TXT records on finding DKIM key records.

Section 3.6.2.1 currently says:

  INFORMATIVE OPERATIONAL NOTE: Wildcard DNS records (e.g.,
  *.bar._domainkey.example.com) do not make sense in this context
  and should not be used.  Note also that wildcards within domains
  (e.g., s._domainkey.*.example.com) are not supported by the DNS.

That first sentence is just plain wrong.  I have been using wildcard
DNS records of exactly that form for months, and they work fine.  I
put a unique selector on each message, and when I get around to it
will extract the DNS lookup info to figure out how many people are
looking at my signatures.  This may be morally reprehensible, but it
does make sense.

I suggest we delete the whole note.

Section 6.1.2 says:

   NOTE:  The use of wildcard TXT records in the DNS will produce a
  response to a DKIM query that is unlikely to be valid DKIM key
  record.  This problem applies to many other types of queries, and
  client software that processes DNS responses needs to take this
  problem into account.

This is only true if the name of the record doesn't include
_domainkey, so *._domainkey.example.com or
*.foo._domainkey.example.com is OK, but *.example.com is not.  So I
suggest we rewrite it as:

   NOTE: Wildcard TXT records whose names are not in the _domainkey
  subdomain will generally produce a response to a DKIM query that
  is not a valid DKIM key record.  This problem applies to many
  other types of queries, and client software that processes DNS
  responses needs to take this problem into account.

Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies,
Please consider the environment before reading this e-mail. http://jl.ly
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html