ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Jim's issues - one more try

2007-06-11 17:37:08

On Jun 11, 2007, at 4:15 PM, Eric Allman wrote:


My interpretation of that is that a "place" is defined by an RR type as well as the address --- this requirement is to avoid overloading of TXT records.

Eric,

Policy related wildcard RRs are intended for non-existing sub- domains, however a Wildcard RR will not synthesize a resource record for all sub-domains. Full coverage therefore requires both non- wildcard and wildcard instances of resource record be placed at _every_ existing DNS node below or at the domain level where coverage is desired. It is not clear whether even illegal domain names are safe to ignore.

Rather than devising schemes that return policy records for _every_ possible label (revealing zone structure), existing domains used for email are already evidenced by appearance of MX (and A) records necessary for a discovery process. The anachronistic necessity of A records in a discovery process has long since passed. Within a similar time frame, support of A record discovery can be announced as deprecated, and then obsoleted when a few domains begin to refuse messages from domains lacking MX records.

When a message is received that is considered _not_ signed, a query would be made for an MX (or A) record. All resource records for this domain might be requested to expedite discovery of either MX (or A). When a policy record is placed below a prefix label, these records will not be returned by a query at the domain. This record would be at a different location. Use of a prefix therefore reduces the number of partial answers that might then demand separate specific DNS transactions. However, wildcard records will be at this common location.

 So when wildcard records are not used,
 after receiving a message considered not signed:

  - When neither an MX (or A) record are found, refuse the message.
  - When an MX (or A) record are found, query for a policy record.
- When no policy is found, there is no policy. (Searching not required.)
  - When policy requires DKIM signatures, refuse the message.

This approach will not require wildcards or the transversal (up or down) of domain labels.

Assume a message being received is from a bad-actor more than 90% of the time. A bad-actor will spoof _any_ number of sub-domains. A scheme returning a policy record for each spoofed sub-domain creates a separate instance of a (likely bulky) policy record. Just as there are an infinite number of domains a bad-actor might wish to spoof, there would be an infinitely higher demand placed upon DNS cache and transport. Each query will be generating fresh traffic, and placing a demand upon the cache.

Checking for an MX or A record is also likely to detect more spoofing than would checking for a policy record. MX (and A) records MUST be present, whereas there will be only a small percentage of a new RR type published. As currently constrained, this DKIM policy is unable to cause the refusal of messages from a bogus domain unless all messages MUST BE SIGNED. However, such a policy will prove disruptive in many cases. Hence, utilization of existing MX (and A) records will prove more effective at mitigating domain spoofing than will use of wildcard policy records.

-Doug

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