spf-discuss
[Top] [All Lists]

Wildcards - Downgrade HOLD to SELL

2005-05-06 08:30:52
DNS wildcards are a dangerous feature with very little benefit. For a good discussion of the dangers, see <http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html>http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html - IAB Commentary: Architectural Concerns on the Use of DNS Wildcards. The sole benefit appears to be a smaller zone file. Hand editing should not be a problem. Even if a domain has hundreds of MX records, and those records need to be identical, and they need to be frequently changed, then they may have to invest in a text editor with a search-and-replace function. :>)

Wildcard MX records pose a serious problem with common user errors, like misspelled email addresses. Instead of a simple bounce message, which users will expect, the mail could go to the wrong party. If someone sends an email with a typo to <mailto:me(_at_)mycopany(_dot_)gain(_dot_)com>me(_at_)myconpany(_dot_)tld, and .tld has an MX wildcard catching all misspelled names, it could go to some employee at .tld, who might sell it to the plaintiff's lawyer!!

It seems that some top-level-domains are actually using wildcard A and MX records without the consent of their delegated domains! See the link above. I can understand their wanting wildcard A records. That allows them to cut ahead of Microsoft and Melbourne IT in offering registration services for new domain names, but why MX? What the hell do they want with emails intended for someone else?

I think we need to use stronger language in the draft. Here is my recommended revision:

3.1.5  Wildcard Records

   Use of wildcard records is not recommended
   in any zone file with SPF records.  If a zone file has
   wildcard MX records, it may need to publish wildcard SPF records with
   similar structure.  In particular, the SPF records
   must be repeated for any host that has any RR records at
   all, and for subdomains thereof.  For example, the example given in
   [RFC1034], Section 4.3.3, could be extended with:

       X.COM.          MX      10      A.X.COM
       X.COM.          TXT     "v=spf1 a:A.X.COM -all"

       *.X.COM.        MX      10      A.X.COM
       *.X.COM.        TXT     "v=spf1 a:A.X.COM -all"

       A.X.COM.        A       1.2.3.4
       A.X.COM.        MX      10      A.X.COM
       A.X.COM.        TXT     "v=spf1 a:A.X.COM -all"

       *.A.X.COM.      MX      10      A.X.COM
       *.A.X.COM.      TXT     "v=spf1 a:A.X.COM -all"

   Notice that SPF records must be repeated twice for every name within
   the domain: Once for the name, and once for a wildcard to cover the
   tree under the name.

   Use of wildcards is discouraged in general as they cause every name
   under the domain to exist and queries against arbitrary names will
   never return RCODE 3 (Name Error).  For more on the dangers of wildcards
   see [IAB].

13.2 Informative References
<add>
[IAB] <http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html>http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html - "IAB Commentary: Architectural Concerns on the Use of DNS Wildcards", Sept 2003.
</add>

--
Dave
************************************************************     *
* David MacQuigg, PhD      email:  dmquigg-spf at yahoo.com      *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                   9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.              Tucson, Arizona 85710        *
************************************************************ *


<Prev in Thread] Current Thread [Next in Thread>