Message Board

Donating MX Entries

Older Posts ]   [ Newer Posts ]
 CNAME to make identification harder?
Author: G.Shammas   (25 May 07 12:54pm)
I don't know how many fake domain names that are being use as MX entries for domains, but to me that seems that is easy to attack and find.....

It easy to see where the MX records point by (On *NIX systems anyway) running host <domain> and it will pull up the domain in full, and show any records it has. But that does not recursively to resolve for the MX records.

So if someone where to make a cname, it makes it look like mail is handled by its own domain name. going to use two of my donated names so it can be seen how it works...

I am not sure how you would see it windows machines. (Has a cname entry) (Doesn't have one, just does with project honeypot says)

The nows shows up as has errors, which means 2 things. 1, that this technique will work against spammers, because it working already on this site.

Post Edited (5 Jun 07 8:52am)
 Re: CNAME to make identification harder?
Author: G.Shammas   (27 Aug 07 7:58am)
Not a single reply in 3 months, and I am still front page.... I see my thoughts are really cared about here.
 Re: CNAME to make identification harder?
Author: M.Prince   (28 Aug 07 11:43am)
Not that people don't care, just that, at least I, am not sure what you're proposing from your message above.

We're aware that it's possible to tell where MXs point. We have a number of protection measures in place to make this harder than it may initially seem. However, it is definitely a vulnerability of the Project.

I'm not sure how adding a CNAME record would add any benefit. But we're definitely all ears if you have an idea.

 Re: CNAME to make identification harder?
Author: A.Stanislav   (21 Sep 07 9:05pm)
I believe what GS is asking is this:

Suppose you have a domain, say and want to donate a subdomain, say to the project.

Now, normally you would make an MX entry of to handle the mail for

The question that GS was asking, I believe, is:

Could you instead create a record of, say, to be the CNAME for, and then make the MX record for
 Re: CNAME to make identification harder?
Author: F.De Mees   (2 May 09 5:41pm)

The RFC's tell that only a host (record type A) is legal in an MX. So setting CNAMES or bare IP's in MX definitions are protocol violations, although they may work.


 Re: CNAME to make identification harder?
Author: M.Moose   (25 Jun 12 10:41pm)
First, the OP demonstrated little knowledge of DNS (server and client-side resolvers). If there was a sound understanding to begin with the OP would understand his ability to look up records is not so "l33t"... DNS interrogation can be done equally as well on non *NIX systems as he so fashionably referred.

Furthermore, OP would have also understood that this is against the RFCs, as F.De Mees pointed out - though it will work.

OP would have understood that even with this configuration it does not hide the true underlying host... a few dig, host or nslookup queries will reveal all one wants to know.

Alas, none of this matters (largely speaking) since spammers don't care - it's a blast and run process... it either works or it doesn't. OP's "technique" will stop nothing nor will it hide anything. At best it will add another couple digs for anybody who is actually looking!
 Re: CNAME to make identification harder?
Author: J.Betts3   (11 Dec 13 5:45pm)
the only way you can legally use cname is on the primary hostname CNAME {something}

where {something} is some other domain that has mail routed to (eg. via MX) to

A better way to hide it might be to copy the IP address of into
the A record for a domain you control and use that domain as the MX you'd
probably need to automate this somehow. I don't know which DNS servers would
support that.

But attackers will still be able to easily find the IP address, And if they know it hosts a spamtrap they will know not to use it.

do not follow this link

Privacy Policy | Terms of Use | About Project Honey Pot | FAQ | Cloudflare Site Protection | Contact Us

Copyright © 2004–20, Unspam Technologies, Inc. All rights reserved.

contact | wiki | email