|
Re: Wildcards - Downgrade HOLD to SELL
2005-05-06 13:11:14
David,
At 09:30 AM 5/6/2005, you wrote:
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. :>)
With all respect, your opening statement seems rather bold for someone who
has admitted to not being immersed in DNS all that long. To paraphrase the
article to which you point, if one wants to implement, one may freely go
ahead with a full understanding of the implementation issues. The author's
reasonable cautions are based upon consequences of not paying attention to
implementation issues, rather than making any blanket recommendation that
people not use the wildcard facility in DNS.
IMHO, your observations are completely off base regarding DNS
wildcards. If used properly and managed properly there are very useful
applications with which this feature can be used. There are other security
uses about which I shall not go into detail here.
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!!
When you discuss misrouted mail from a typo, that sort of thing certainly
happens every day, but frequently it has nothing to do with DNS operation
or any misperceived failing on the part of DNS. If anyone types an
address, they should reasonably expect that it gets delivered to the domain
it is sent to and may be read by the recipient, no matter who you send
to. I think you are trying to fix the wrong protocol service here. Rather
I think that this is far more a problem of user stick error from left side
of the @ sign typos or perhaps certain badly thought out SMTP
implementations or network designs.
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?
Have you ever managed DNS for a network or for that matter experienced the
joys of general network operations and security in a business
environment? Please don't presume on how others operate their networks in
the course of doing proper and responsible business. They may indeed have
very specific and justifiable reasons for implementing with DNS wildcards.
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].
NO. For one thing, you are using wildcards in an example immediately after
specifically stating that SPF implementations should not use them.
More importantly, I think that it is not the place of SPF to presume on how
another specification should operate. I am a big proponent of SPF, but if
through the SPF spec, you plan to tell me how to run my DNS servers (other
than how to implement an additional valuable feature such as protecting my
domains from identity theft), by telling me accepted and appropriate uses
of DNS wildcards is or may somehow become incompatible with SPF, it might
be time to start looking at another solution to domain name identity theft.
I'm not going to do that. Properly implemented SPF works and it works with
or without DNS wildcards.
I think that the idea behind this group is to encourage adoption of SPF,
rather than to turn off potential publishers and other adopters by making
demands that are inconsistent with legitimate business practices and uses
of DNS. There is nothing wrong with DNS, please stop trying to seemingly
promote views on this list that somehow DNS itself is broken or at least
seriously flawed.
Given who stewards and who holds responsibility for the largest deployment
of DNS code on the planet, feel certain that DNS has generally worked well,
is working well and arguably will work well into the foreseeable
future. Too much infrastructure relies on DNS for any other
outcome. Consider that a successful DNS attack is real news and receiving
spam is generally not considered news.
Paradoxically, even as a support of SPF, I look forward to the day when an
article is published about an SPF exploit, because it will signal that SPF
has actually grown to become so widely adopted that such an article is
indeed worthy of news. I think our job now is to make SPF strong enough
that such a future exploit is limited and can be worked around and / or
repaired quickly.
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>
Do RFCs point to URLs, which may or may not exist over time? I'm not sure
how many RFCs point to web pages, but given the dynamics of the Internet in
general and web site design specifically, this is probably a very bad
idea. Pointing to physically published works in attribution seems far more
sensible.
--
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 *
************************************************************ *
David, I am sorry if my tone appears strong because I still think that your
heart is in the right place, but please don't attempt to break a whole lot
of established and working infrastructure unless you have found a specific
hole that absolutely warrants it.
Even then, go back to the creators of the service in question and see if
that hole can be plugged without destroying parts of the infrastructure
that have real and legitimate uses. When you do, be very sure of what you
ask and its global implications. Should you not, this response will seem
quite kind and gentle in comparison with what you will likely receive from
those creators, who are saddled with the ultimate burden of responsibility
for the choices they make in their implementations. The choices those core
service creators make hold enormous global repercussions for everyone on
the Internet and they rightly take that responsibility very
seriously. They allow DNS wildcards for a reason.
Best,
Alan Maitland
WebMaster(_at_)Commerco(_dot_)Net
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/
|
|