Subject: Re: Faux wildcards

From: wayne <[email-masked]>
Date: Sun, 16 Jan 2005 12:41:38 -0600

In <[email-masked]> "Hallam-Baker, Phillip" <[email-masked]> writes:

> Actually the wildcards do absolutely nothing to solve any of the maintenance
> issues that John is concerned with, not one.
>
> The problem is that a wildcard only matches a node that DOES NOT EXIST AT
> ALL. The only use for a DNS wildcard in the context of spam is to say THIS
> NODE DOES NOT EXIST AT ALL from which the only reasonable assumption would
> be DO NOT ACCEPT EMAIL FROM THIS NODE.

If you do not accept email from nodes that don't exist, then you will
be throwing out a lot of legitimate email.  Far too much email gets
sent using HELO domains with either domain names that are only
viewable inernally, are typos, or are due to misconfigurations for
most people to take this stand.  Spammers and phishers have taken
advantage of this situation.

> What John is trying to do is to make it easier to administer a zone. It is a
> reasonable feature to put in a DNS server, it is a feature that should be in
> a DNS server. It is not a feature that belongs in a protocol.
>
> The DNS configuration file need not be the same as the zone transfer file. 

In theory, this is very true.  In practice, it has problems.  Such
features do not exist in name server software, requiring everyone to
create local modifications.  Also, if every host in your zone file
needs to have an SPF, CSV, DK, RP, etc. record added to it, you are
going to greatly increase the size of the zones.

-wayne

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Danny Mayer <[email-masked]>
Date: Sun, 16 Jan 2005 22:33:36 -0500

>advantage of this situation.

All the more reason for enforcing the rules by refusing invalid names.
People will quickly fix the problem if it's preventing mail getting through.

Danny

---

From: John Levine <[email-masked]>
Date: 17 Jan 2005 04:37:31 -0000

>>most people to take this stand.

>People will quickly fix the problem if it's preventing mail getting through.

See if you can get Hotmail to fix their HELO's.  Once they do it,
then we can get everyone else to fall into line.

R's,
John

---

From: John Levine <[email-masked]>
Date: 17 Jan 2005 04:36:13 -0000

>What John really needs to address his admin issues is a DNS server macro.
>People who need that feature can unilaterally upgrade their DNS server to
>one that supports the feature needed. Nobody else need be affected.

Yes indeed.  If I could tell my server to serve this record for any
request that matches _client.smtp.*.example.com I'd be a happy camper,
and CSV clients could just make the one obvious query and be done.
And if it were just me, I'd do it.  I've written funky servers before;
caches and resolvers are hard, but servers turn out to be surprisingly
easy.  (There's a reason that tinydns is called tinydns.)

>In fact I don't even need to do that, I just put a preprocessor in
>front of BIND.

Are you sure?  Offhand I can't think of any way to fake a.*.b in a BIND
zone other than a terabyte of all possble bit patterns.

>The prefix architecture works exactly as well as a new RR deployment
>and does not depend on any DNS infrastructure changes being deployed.

Well, it works a lot better if your servers can match a.*.b.  But you're
right that the clients will work just fine.

The wildcard theory is that if you deploy new RR types, you don't need
prefixes, so wildcards work.  As Phill and I agree (wow, alert the
media) actually, they don't, since any RR at a node keeps wildcards
from matching, even queries for other RR types.  So, for example, in
my case where I want to mark a big farm of hosts all as not valid,
even if I had a shiny new RR type, I still couldn't use a wildcard
because the A records for those hosts would keep the wildcard from
matching any of them.

Given how many people misunderstand this point, including a couple of
IETF greybeards I talked to at IETF 61, I think we can make a rather
strong argument that this aspect of wildcards is just wrong.  But if
we're going to change the way that wildcards work, I'd rather make big
changes to make them really useful.

Since wildcards are invisible to DNS clients, the only place the current
definition matters is in AXFR data between servers, and in the code in
the server that matches them.  Should we be saying that if you want to
deploy SPF or CSV or DK or IIM or any other anti-spam scheme that needs
to be able to say "anything else is bogus" you'll need a better server
than BIND?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
http://www.taugh.com

---

From: wayne <[email-masked]>
Date: Sun, 16 Jan 2005 23:09:26 -0600

> People will quickly fix the problem if it's preventing mail getting through.

Three comments:

1) This mailing list is about DNS, not about email or spam.  My
   comment was in relation to the need for a different form of DNS
   wildcards, but this is quickly drifting off topic.

2) It is wildly recognized in the email/anti-spam community that
   people have a very wide range of tolerances for false positives
   (legitimate email being falsely rejected), and false negatives
   (spam that gets through).

   What I stated was a recognition of this and, since there are no
   protocol police, trying to change how the world works is hard.  If
   you think it is worth your while to try change this, you might try
   starting with changing the IETF.

3) Let's look at the Received: headers from Danny's email:

      [Received: headers coming from the list deleted]
   
      Received: from [208.218.130.12] (helo=gis.net)
      	by psg.com with esmtp (Exim 4.43 (FreeBSD))
      	id 1CqNeH-0005VP-MC
      	for [email-masked]; Mon, 17 Jan 2005 03:33:49 +0000

   Note that Danny's MTA gave a HELO of gis.net, which doesn't have the
   IP address of 208.218.130.12.

      Received: from tecotoo.localhost ([207.7.195.195]) by
                mx04.gis.net; Sun, 16 Jan 2005 22:33:48 -0500

   Note that tecotoo.localhost is not a valid domain.

   Note that 207.7.195.195 does not have a valid rDNS PTR.

      Received: from tecotoo (tecotoo [127.0.0.1]) by
                tecotoo.localhost (NTMail 3.03.0017/1.aaaa) with ESMTP
                id va000983 for <[email-masked]>;
                Sun, 16 Jan 2005 22:33:41 +0000
   
   Note that tecotoo is not a valid domain.

   It is a good thing that Danny's MTAs don't practice what Danny
   preaches, otherwise we would never had heard from Danny.  But hey,
   don't feel too bad.  I once went and checked the quality of HELO
   domains given by people on the IETF MARID WG, a group chartered to
   find solutions to email-forgery/spam/phishing problems, and the
   results were pretty bad.[1]

-wayne

[1] http://www.imc.org/ietf-mxcomp/mail-archive/msg03102.html
    Note that that the comments involve very heavy sarcasm, much of
    which will not be recognized if you aren't very involved in email
    and the MARID WG.  Also note that since that post, I changed from
    my midwestcs.com domain to my schlitt.net domain.  Also, by
    "invalid HELO domain", I did not limit myself to just domains that
    returned NXDOMAIN.

---

From: Danny Mayer <[email-masked]>
Date: Tue, 18 Jan 2005 19:49:42 -0500

>3) Let's look at the Received: headers from Danny's email:

Your points 2 and 3 (I deleted the actual analysis) shows that looking
at the names being sent is useless and confirms that you should stick
to the IP address only. I have my local system set up as a local smtp
server whose job it is to forward my mail to my ISP (as well as handle
my personal mailinglists). That's not an unusual situation. My ISP's
SMTP server is set up to only accept mail from those IP addresses
that it owns as well as to deliver to domains that it is responsible for
receiving email (like gis.net). These are the situations that antispam
protocols need to handle.

You should be able to make use of any record type that DNS supports
including PTR, SRV, TXT and any new record type that you wish to
propose to support your efforts (modulo what the DNS community thinks
should be supported and obtained through the usual IETF process.

Danny