Re: Wildcards - Downgrade HOLD to SELL

Alan,  I appreciate your comments, and apologize for my rash 
statements.  The Subject line was intended to be humorous, not rude.
At 02:11 PM 5/6/2005 -0600, Commerco WebMaster wrote:

> 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.
Sorry for stating my opinion so bluntly.  The IAB paper is indeed more 
cautious in its recommendations, and you are right, it takes user error to 
get some of the worst consequences they describe.  I'll try to be more 
clear when I am stating an opinion, not an assertion of fact.  Still, I 
find it outrageous that a parent domain would redirect any emails with 
mis-spelled addresses to itself.
What are the benefits of wildcards, other than a smaller zone 
file?  Knowing what we do now, would wildcards be added to DNS?
> > 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.
The problem is not that 1 in 1000 chance that an email goes to an 
incorrectly typed, but valid address.  The problem is 1000 times worse, 
because *any* misspelled address will go to the wildcard MX.
> > 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 have never managed a network, but I feel that I don't need that 
experience to understand that misdirected emails are a serious 
problem.  This particular problem is not the fault of DNS or wildcards, 
however.  The folks intercepting emails in the example from the paper are 
doing it deliberately, and could do the same thing with a packet 
sniffer.  The data does flow through their office.
I'm an expert in IC design.  If someone said one of my designs was bad 
because it burned out in some likely circumstance, I would not defend the 
design by asking the person if they have ever designed an IC before.
Maybe there is a justification for a wildcard MX record in a top-level 
domain.  I just can't imagine what it would be.
> > 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.
Maybe we should say, "not recommended, but if you must, here is what you 
need to do."
An alternative would be to put your outgoing mail server records in their 
own zone file. (If I understand DNS correctly, the scope of wildcards is 
limited to the zone in which they occur.)  I typically see names like 
'smtp.mail.yahoo.com' and 'pop.mail.yahoo.com'.  Is there any need for 
wildcard MX records in 'smtp.mail.yahoo.com'?
> 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 agree SPF should not tell people they shouldn't use wildcards anywhere in 
their domain, but where they interact with SPF, and cause the SPF records 
to be more complex than they would otherwise be, as in the example above, 
then we should say something.  Perhaps we could suggest some alternatives, 
like separate zones.
Wildcards aren't incompatible with SPF, they just make SPF more complicated 
and prone to error.  The other methods (CSV and DomainKeys) actually are 
incompatible, because they use the _namehack.
> 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.
I don't know if you read the earlier thread when this first came up, but to 
summarize, what I said was I think DNS is a remarkably good design for such 
an old protocol, but it has a few flaws.  I would not point out these flaws 
except for their relevance to what I am trying to do.  I would also not say 
anything if I felt I already knew it all, case closed.
I know I should be more careful when I criticize the work of others, but I 
get in a hurry and sometimes get too short.  I hope my explanations here 
will make it more clear what I really think of DNS.
> 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.
DNS has worked remarkably well, and it really is the best way to provide an 
email authentication service.  I'm very surprised when I see apathy among 
the "DNS folks".  Instead of just shooting SPF down, why don't they jump in 
and say "Great idea.  Now if you just change this and that ...".  I guess 
from their point of view, the "SPF folks" aren't listening.
The proposal I'm working on will be (SPF3 I hope) the ultimate efficient 
use of DNS for email authentication.  One query to a known  server, and 
bingo, you get everything you need for authentication and domain-rating for 
all the mail servers in an entire domain. Zero worry of DNS loading.  This 
is not a difficult technical problem.  I believe A DNS expert could write 
this proposal much better than I can.  Why aren't they motivated?
> 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.
If Wayne is actually going to use this in the draft, I'll study the RFC 
rules and get it right.
> 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.
I can't see how my suggestion breaks anything.  I'm just saying try to 
avoid using an optional feature of DNS that makes SPF more complicated.
> 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.
I have gotten some good advice (offline) from a DNS expert who is unwilling 
to participate in these mailing list discussions.  It is really a shame 
that there is such hostility that experts and people with good ideas don't 
feel welcome.
I still wish someone could explain the fundamental benefits of 
wildcards.  The best I have so far is that some admins feel a need to 
"hide" the names of their MX hosts from the outside world.  Does that help 
avoid a DoS attack or something?  I'm still talking with the DNS expert 
offline.
--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg 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          *
************************************************************     *