David MacQuigg 4/28/05
Consolidating email authentication information into one DNS record at a standard location can avoid the threat of abuse facing IP-based authentication methods. A simple, general record syntax can provide for the use of any authentication method or domain-rating service and facilitate changing methods, should that become necessary.
A fundamental requirement of any email authentication method is that it not create any new opportunities for Denial-of-Service ( DoS ) attacks or abuse of the Internet infrastructure. IP-based authentication methods are particularly vulnerable, because they require at least one query to the Domain Name System ( DNS ) by a Mail Transfer Agent ( MTA ) within each domain handling an email. Some of the current methods require multiple queries per MTA.
Many DNS servers are old, slow, but reliable machines, intended to answer only occasional queries from other domains, and very dependent on name servers in those other domains to cache the answers and handle the vast majority of queries locally. A typical query by an Internet Service Provider ( ISP ) for the address of a web page might be cached for days, and during that time, provide local answers to 1000 similar queries.
In requesting the support of DNS for email authentication, we must anticipate not just the increase in DNS load under normal circumstances, but what may happen in worst-case scenarios, when configurations are deliberately set up for abuse. We have to be especially careful about possible involvement of "third parties", i.e. those not involved in sending or receiving an email. Planning for this abuse is difficult, because we have to think about complex and unlikely scenarios. If there is a one-in-ten chance of a successful attack, we have to take it seriously, and design for this worst case.
We also have to avoid demanding so much of the new authentication methods, that no solution is possible. We must compare the potential costs, including the upgrade of DNS servers and a small possibility of DoS attack, to the real and present costs of continued email abuse. No method will avoid all possibility of abuse. Even the current uses of DNS for non-email services can be abused.
A reasonable goal for new services is that the DNS load be comparable in magnitude and risk to the load from current services. If it is not possible to meet this goal, then perhaps authentication queries should be handled by servers separate from those providing other critical DNS services. A well-planned authentication system should allow for rapid migration to such separate servers.
Authentication records must fit into a framework for supporting multiple authentication methods in a variety of environments. For one such framework see draft-macquigg-authent-IOP.htm. Two of the fundamental requirements in that document relate to authentication records.
7) Forwarders should minimize Internet traffic by minimizing queries and by
rejecting forged messages at the earliest opportunity.
8) Authentication methods should avoid creating any new opportunities for
Denial-of-Service (DoS) attacks or abuse of the Internet infrastructure.
To meet these requirements, we must minimize the number of DNS queries per MTA. We need to consolidate widely scattered information, and put it in a standard location. One query from each MTA for each mail-serving domain should be sufficient to determine the authentication method, and get enough information to reject most forgeries without further DNS queries. We must avoid "hunting" for records at locations specified by the various methods, or at different levels of subdomains.
The level at which DNS information is consolidated should be chosen by each domain administrator, balancing the advantages of decentralization versus fewer records and better caching. Typically, consolidating the information for ten busy subdomains will result in ten times fewer DNS queries. Consolidation can also reduce the need for frequent changes, allowing better caching and a substantial reduction in queries. The record need not change when mail servers are moved within existing IP blocks.
With a little planning, most domains can set aside just a few IP blocks for their Public Mail Servers. One cached record can provide authentication information for an entire domain, and avoid further queries to that domain for several days. This is the way DNS was intended to operate, and the way it can support email authentication without an upgrade to DNS servers worldwide. It is also a good way to avoid temptation to involve DNS in any Denial-of-Service attack.
Again, from draft-macquigg-authent-IOP.htm
8a) Authentication records should be set up so that a single DNS query can
provide complete and stable information for an entire domain, including all
needed authentication and accreditation data.
8b) Methods that allow multiple DNS queries, beyond the normal subdomain
referrals, must limit the number of extra queries, and should provide a
"one-query defense mode" which may be invoked during a DoS attack. In this
mode, mail which requires only one query should flow normally.
For a unified authentication record, we can add a few more requirements. The authentication record syntax should be simple and general enough to accommodate all methods. It should provide an easy "link" to other records in case one is not enough, or in case a domain is happy with its current authentication setup, and wants nothing but a link to the old record. It should include information from accreditation or domain-rating services.
Control of the information becomes an issue when ratings are added. We can't allow a spammer to give himself an A rating. A simple standard format for these records will allow easy sharing of information between a domain and the rating services. The detailed information for the authentication methods is normally maintained by each domain, and published using name servers under its control. The rating information, however, must be kept on name servers under the control of the rating services.
To avoid two queries from each MTA, rating services should work out efficient procedures for maintaining complete information on their own servers. For example, the domain could create the initial record, including which rating services it recommends, and publish it in a TXT record at _AUTH.<domain>. The rating services, periodically or on request, could query that record, insert their own ratings, and re-publish the complete record at a place like _AUTH.<domain>.<service>.
Taking this one step further, the entire industry could cooperate in publishing unified authentication records at a place like _AUTH.<domain>.mail. This will avoid duplicate records at the various services, hunting to find which services keep records on a domain, and delays while the services query each other for information needed to keep every record up to date. Industry cooperation on a common "one-query" email authentication database could provide the ultimate minimum load on MTA's, the DNS, and the worldwide email system.
In the examples below, we may assume DNS records at any of the locations above, but the protocol is the same regardless of where the records are kept.
This section shows one possibility for a unified record setup meeting the above requirements. Each method or service may define its own parameters, using its own names, syntax, and DNS records. This information appears in the unified record as a string value. The only restriction is that method and service names must be unique. We cannot have two methods claiming to be SPF1, or a service with the same name as a method.
Unified records are set up as TXT records in the subdomain _AUTH.<domain>, so no new record type is needed, and there is no conflict with other TXT records sharing the same limited space in a DNS packet.
One query to _AUTH.<domain>.mail gets all the authentication information for a domain in summary form, including a list of accreditation services and their ratings of the domain, a list of authentication methods the domain uses, and as many parameters as can be squeezed into approximately 450 bytes, a limit imposed by the 512-byte DNS response format. Links to additional records are provided if necessary.
Here is a 349-byte example record for a large, complex domain, with many subdomains and hundreds of servers all over the USA. This domain actually delegates all DNS responsibilities to its subdomains, but here we have consolidated everything into one record, just to show how a really large domain could minimize its DNS load. The record has been formatted for easy viewing, but in DNS, folding white space would be removed.
svc=S1:A,M2:A,H1+:B dmn=QR1,SPF1+5,DK2
QR1=ip4:?170(24.30.23;24.28.200;24.28.204;24.30.18;24.93.47;24.25.9),
+4(65.24.5.120;24.94.166.28;24.29.109.84;66.75.162.68;24.24.2.12)
DK2=dk:MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5
o6lMIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7
EXzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB
If this looks like the syntax for email headers, that is because we followed [RFC2822] as much as possible. This versatile, compact, and very readable syntax is almost exactly what we need. The main difference is we don't need so many special characters. Everything but "\" and DQUOTE can be part of a normal string. See below for syntax details.
The record is a sequence of name=value pairs. Names defined so far include svc for service data, and dmn for domain data. Names starting with x- may be used for experiments. Unknown names should be ignored to allow for later upgrades. These names may be used in name-value pairs if they appear first as a value. Thus QR1 in the dmn list may be further defined later in the record.
Well-known services have short names, like S1. Others may be listed with a fully-qualified domain name <FQDN>. A query to <domain>.S1.mail or <domain>.<FQDN> returns the rating for that domain by that service. Normally, these extra queries aren't necessary, because the summary above is adequate.
The example domain has A ratings from two services, and a B rating from a third. Service H1 provides one additional record at _H1.<domain>.<service>, probably some notes on the reasons for the B rating, status of cleanup efforts, etc.
This domain uses 3 authentication methods, QR1, SPF1 and DK2. These should be executed in the sequence shown. Generally, listing the simplest method first will avoid expensive testing on most of the forgeries.
Parameters for each method are given later in the record, or (if a + follows the method name) in additional records. The SPF1 method in the record above has no parameters within the record, but the +5 after SPF1 means that additional records are available, starting with a query to _SPF1.<domain>, and requiring no more than 5 queries to complete.
The first method QR1 offers a Quick Reject of any IP address outside the specified IP blocks. QR1 will reject the vast majority of forgeries that do not have an IP address anywhere "close" to an authorized address for the domain. See draft-macquigg-qr1.htm for details of this method.
The second method SPF1 is described in draft-schlitt-spf-classic-00.
The third and final method DK2 has one parameter dk, a 768-bit "DomainKey", which is completely specified in this record. See draft-delany-domainkeys-base-02 for details of this method. Normally, there is no need to put a DomainKey in this record, but here it makes a nice example to show what can be done in the limited space of one record.
Domains setting up their authentication records should specify at least one simple method first. Not all forwarders and receivers will implement all methods.
Domains should minimize the number of DNS queries generated by their authentication requirements. MTA's that are heavily loaded may temporarily reject messages that don't PASS with one DNS query, or they may forward the message with less than a PASS authentication result.
A query to a rating service should get a standardized response. One possible standard is detailed in draft-ietf-marid-csv-dna-02. The ratings A, B, etc. could have the meanings defined in that draft. One of the ratings, maybe "C" should have a special meaning "unknown". This will allow rating services to avoid listing large numbers of spammer-generated domain names.
5.1. Example Records
One of everything:
svc=S1:A,M2:A,H1+:B dmn=QR1,SPF1+5,DK2
S1=fqdn:dnsbl.spamcop.net
QR1=ip4:?170(24.30.23;24.28.200;24.28.204;24.30.18;24.93.47;24.25.9),
+4(65.24.5.120;24.94.166.28;24.29.109.84;66.75.162.68;24.24.2.12)
SPF1="mx include:s._spf.ebay.com include:m._spf.ebay.com
include:p._spf.ebay.com include:c._spf.ebay.com ~all"
DK2=dk:MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5
o6lMIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7
EXzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB
Encoded values are Base64, 6 bits per printable character. Compiled records like this should never be edited directly. There is too much chance of error. Tools are provided for each method that will convert to and from the compiled format and a simple user-friendly format.
Fully-qualified domain name instead of a service code:
svc=dnsbl.spamcop.net:A,M2:A,H1+:B
Minimum unified record for a domain that wants nothing but their current SPF1 record:
dmn=SPF1:redirect=mydomain.com
5.2. Semantics
Strings following the svc and dmn names are interpreted as comma-separated lists. Other strings have whatever interpretation is needed by their methods. The string following QR1 is delivered verbatim to the QR1 routines (minus the FWS). The quoted string following SPF1 is delivered verbatim with FWS converted to a single space.
Methods listed for dmn are processed left to right. If the result of a method is PASS or FAIL, that result is conclusive, and further testing is skipped. A NEUTRAL may be over-ridden by a more conclusive result from a later method. If not over-ridden, the final result will remain NEUTRAL.
List items for svc and dmn must have unique names, and the names must match any related DNS records ( less the leading underscore).
Parameters for each list item can be provided in strings immediately after the item, later in the record, or in separate records. All three are semantically equivalent.
+<number> in a list item means separate records are available, and no more than <number> DNS queries will be necessary to complete the processing of this item. The first record is found by a TXT query to _<name>.<domain> Subsequent records are found as specified by the method. (e.g. SPF1 uses commands like redirect. )
5.3. Collected ABNF
This section is normative, and any discrepancies with ABNF fragments in the preceding text are to be resolved in favor of this grammar.
See [RFC2234] for ABNF notation. Please note that as per this ABNF definition, literal text strings (those in quotes) are case-insensitive. Hence, "ip4" matches "ip4", "IP4", "iP4" and "Ip4".
record = name-value-pair *( ( 1*WSP / CRLF ) name-value-pair )
name-value-pair = name [WSP] "=" [FWS] ( string / quoted-string )
name = ALPHA *( ALPHA / DIGIT / "." / "-" / "_" )
string = 1*( stext ) *( FWS 1*( stext ) )
stext = %d33 / ; Any character except controls,
%d35-91 / ; SP, and specials.
%d93-126
specials = "\" / DQUOTE
quoted-string = DQUOTE *([anyspace] qcontent) [anyspace] DQUOTE
; anything but " and \
anyspace = ( WSP / FWS / NBFWS )
qcontent = qtext / quoted-pair
qtext = NO-WS-CTL / ; Non white space controls
stext
quoted-pair = ("\" text)
text = %d1-9 / ; All characters
%d11-12 / ; excluding CR and LF
%d14-127
list = item *( "," [anyspace] item )
item = name [ "+" [number]] [ ":" [anyspace] string ]
FWS = ( *WSP CRLF 1*WSP ) ; Folding White Space
; In a string FWS is semantically invisible. In a
; quoted-string, or between name-value pairs, it is
; equivalent to SP.
NBFWS = ( "\" CRLF 1*WSP ) ; No Break FWS
; Semantically invisible in either type of string
WSP = SP / HTAB
SP = %d9
HTAB = %d32
CRLF = CR LF
CR = %d13
LF = %d10
NO-WS-CTL = %d1-8 / ; US-ASCII control characters
%d11-12 / ; that do not include the
%d14-31 / ; carriage return, line feed,
%d127 ; and white space characters
number = 1*( DIGIT )
Problem: How to handle folding white space in a quoted string with a long word that must be split.
Ideal Solution: Redesign the authentication method that needs such a monstrosity. :>)
Possible Solution: The default for quoted strings is to leave one space in place of each removed FWS. To over-ride that default, use a \ at the end of the line. See NBFWS above.
XYZ="ip4:207.171.160.32/28
dk:o6lMIgulclWjZwP56LRqdg5ZX1\
5bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7 ~all"
[RFC2234] "Augmented BNF for Syntax Specifications: ABNF", D. Crocker, November 1997.
[RFC2822] "Internet Message Format", P. Resnick, April 2001.
draft-schlitt-spf-classic-00, "Sender Policy Framework: Authorizing Use of Domains in E-MAIL", M. Wong, W. Schlitt, (work in progress) December 2004.
draft-delany-domainkeys-base-02, "Domain-based Email Authentication Using Public-Keys Advertised in the DNS (DomainKeys)", M. Delany, (work in progress) March 2005.
draft-ietf-marid-csv-dna-02, "Domain Name Accreditation (DNA)", J. Leslie, et.al., (work in progress) February 2005.
draft-newton-maawg-spf-considerations-00, " Considerations for the use of the Sender Policy Framework", A.Newton (work-in-progress) April 2005.
draft-macquigg-authent-IOP.htm, "Email Authentication Inter-Operability Protocol", D. MacQuigg (work in progress) April 2005.
draft-macquigg-qr1.htm, " Quick Reject Method QR1, Defending the Network", D. MacQuigg (work in progress) April 2005.
The universal standard location _AUTH.<identity>.mail is based on the proposal by http://www.spamhaus.org/tld for a top-level .mail domain.
--- End of File ---