On Jun 7, 2007, at 10:15 AM, Jim Fenton wrote:
Doug Otis has proposed that a registry of such names be maintained,
which I doubt would be workable, and in any case wouldn't cover sub-
delegation. And we have already discussed the problems with
associating semantics with zone cuts; there are administratively
separate domains in common zones, and subdomains under common
administration in separate zones.
To prevent DKIM from substantially increasing DNS DDoS risks, avoid
having recipients performing domain transversals or placing reliance
upon the use of wildcard resource records. So what is left?
1) Domain transversal can be limited by registering with IANA a
fairly static list of registry domains. This would contain about
1000 domains and indicate which are being used by registries for the
purpose of publishing other domains.
DKIM already assumes that a parent domain is authoritative, where
such a list at least satisfies the last minute requirement added by
IESG. Any second or third level domain used by a registry would have
an incentive to ensure that their domains are entered into the list.
The traffic generated by all the unterminated queries will provide
the enticement without needing any other means of encouragement or
legal obligation.
Such a list also reduces caching and network overhead related to
retrieving domain related behavior information. Just information
related to the principal domain (the domain just below the registry
domain) often satisfies recipient's needs. Bad-actors tend to
utilize wildcard domain labels and attempt to flood these systems.
2) Anchor policy to the MX and A records (where the use of the A
record is deprecated). Future protocols would be encouraged to
define a DNS specific RR to establish a protocol "proof of existence".
An anchor approach would preclude domains that are being phished from
also using wildcard MX records. Any domain being phished is well
advised to not utilize wildcard MX records anyway.
Using this approach, policy records would only need to be placed
adjacent to any MX or A record. Eventually policy would only be
placed adjacent to MX records, once A records in a discovery process
have been finally obsoleted. Even placement adjacent to A records
represents far fewer entries than that needed to establish a
functional wildcard for the same purpose.
Email represents a rather special case. Email is a protocol pushing
data without prior arrangements. It is doubtful other protocols
would be best served by a wildcard scheme. Most other protocols
utilize a pull mechanism where policy requirements are significantly
different. In a pull protocol, policy is more easily handled within
the protocol without risking exposure to wildcard DDoS exploits.
3) Out of band policy publications.
Such policies as well as accreditations could be created by:
- the end-users leveraging their address-book,
- by social networks that construct sets of lists,
- by accreditation services.
Out-of-band policy publications could play a role in protecting other
resources beyond just email, such as blogs, and IM applications as well.
--------
The policy records should also be able to authorize SMTP clients,
SMTP MAILFROMS, and third-party signers. Domain association offers a
proactive means to curtail replay or back-scatter abuse, and
establish a reasonable means to administer Inter-Domain associations
via a single transaction without prior arrangements.
Once policy can be located quickly by using either strategy #1 or #2,
then adding a prefix hash of the associated domains to policy can
scale without incurring more than one additional transaction.
_dkim-all TXT "<email related policies (xyz also available)>"
(xyz:)
<hash>._dkim_mf TXT "<mail-from related policy>" relates DKIM domain
hash to email-address
<hash>._dkim_s TXT "<sender related policy>" relates DKIM domain
hash to email-address
<hash>._dkim_f TXT "<from related policy>" relates DKIM domain hash
to email-address
<hash>._dkim_c TXT "<client related policy>" relates SMTP client
hash to DKIM domain.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html