On Jun 4, 2007, at 3:43 PM, Jim Fenton wrote:
Hallam-Baker, Phillip wrote:
The policy record is only expressed using TXT. The discovery
process being first look for TXT, if that is not find look for an
XPTR and if found a TXT of the XPTR node.
This is apparently the central issue where I didn't understand your
proposal. I thought you always looked up the XPTR first, but I see
that is not the case.
Is the rule then to always publish the prefixed TXT record, even if
an XPTR is also published, since some verifiers may not be able to
support XPTR?
Either a process that makes assumptions based upon the location of MX
or IP address records, or a linear search is required to discover
policy records when support for some a new wildcard scheme can not be
assured.
The concept offered by Phillip is to use a wildcard with a new type
of PTR record. This XPTR record then points to a location where
policy records are located. One could attempt to first find a
prefixed policy record, and when that failed, attempt to find the
XPTR record. What happens with the XPTR pointer record does not
appear to exist? It would not mean there is no policy.
A scheme that relates policy locations to the location of an MX
record provides offers very similar overhead without introducing a
new RR type. To ensure policy can be discovered in this manner, the
MX record itself must not be using a wildcard. However the new XPTR
must be place at _every_ DNS node, otherwise some regions of a domain
is not protected.
Once the use of A or AAAA records are obsoleted as a means to locate
inbound SMTP servers, then only a policy record would be required at
the location of the MX record. Until then, only where A or AAAA
records are placed would a policy record need to be published. This
actually represents less overhead than that of the XPTR scheme.
Perhaps it is time to start requiring MX records for SMTP. Any type
of wildcard leaves a domain prone to a DDoS attack, where reliance
upon a wildcard would not represent the safest alternative.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html