9

I'm thinking that there's absolutely no reason or justification for this, but before I open my mouth and get some admin in deep kimchi, I thought I should ask.

Is there any circumstance in which an MX record should point to a loopback address? To me, this says any mail server that tries to send to this domain will instead send to themselves, and fail, but I'm not a mail guru, so maybe I'm missing something.

I came across the below when troubleshooting a why-aren't-we-getting-email?? issue for a client, and I'm having trouble wrapping my head around it. Maybe I'm overthinking things, though.

enter image description here

HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
  • 7
    This is basically saying, don't send mail to us... talk to the hand – Mike Pennington Aug 03 '12 at 15:48
  • @MikePennington If you wanted to not get email form anyone, why would you do this instead of, say, removing your MX record? – HopelessN00b Aug 03 '12 at 15:56
  • 5
    if you remove the MX record, mail is sent to the A record for the domain portion of the email address. with no MX record, you get a bunch of people knocking on your door looking for a mail server that isn't answering. with a loopback address, the sender knocks on their own door and doesn't waste your bandwidth. – longneck Aug 03 '12 at 16:33
  • @longneck That's the end result, but it's probably not the best way to go about it. IMHO polluting the public DNS is a pretty dick move to get rid of spammers who would only cost you a few bytes for an `RST` packet if you're not running a mail server... – voretaq7 Aug 03 '12 at 17:44
  • i didn't say it was a good idea. i was just explaining what happens when you remove your MX record, and how removing the MX records does not replicate the configuration asked about. – longneck Aug 03 '12 at 17:57
  • @longneck I think you should put that as an answer to this question, because I believe that (dubious "bandwidth savings") was ultimately the use case here, at least based on what I know about the client in question. So something along the lines of ~not accepting mail and saving a whole RST packet in bandwidth any time someone tries would seem to be the correct accepted answer here. Thanks. – HopelessN00b Aug 03 '12 at 18:08

6 Answers6

10

Definitely a NO, not with a 127.0.0.0 IP.The entire 127.0.0.0 range on IPv4 works as loopback addresses, thus when any machine connects to IPs in that range it will try to connect to itself.

Your MX record IP address should be accessible from the outside world and what that result is telling any server doing a MX query, to try to connect to itself.

If my server was trying to send you email, it would lookup the MX record and then connect its own IP address, send the email and fail.

Ankh2054
  • 1,404
  • 13
  • 23
  • 1
    +1 - The is ***NO*** good reason to ***EVER*** set a public DNS record to an address in 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/8... (As with all internet "rules" you can of course ignore it, but you do so at your own peril, and should only do so with full knowledge of what you're doing and why...) – voretaq7 Aug 03 '12 at 17:41
  • @voretaq7 `warez IN A 127.0.0.1` – Michael Hampton May 18 '13 at 00:44
  • @MichaelHampton served from public, world-facing DNS? I'm pretty sure theres something in the RFCs that says doing so is the equivalent of drowning kittens... – voretaq7 May 19 '13 at 02:01
  • @voretaq7 Yes, I've seen that, and in many places. It dates back at least to the 1990s. The way it was used was: someone would ask where to find warez, and be given the address `warez.example.com` which has this particular record... – Michael Hampton May 19 '13 at 02:03
6

The relevant RFCs say:

  • The MX resource record MUST point to a fully qualified domain name (not an IP address) of a server on the public Internet which accepts mail for the domain. Note that this server does not necessarily have to be in the same domain as the MX record. RFC 1035 section 3.3.9

  • Addresses in the 127.0.0.0/8 range MUST NOT ever appear on the public Internet. RFC 5735 section 3

Note that some mail servers will reject email from senders not in compliance with the relevant RFCs.

Community
  • 1
Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
4

Short answer: It shouldn't.

Long answer: If the domain in question (DIQ) should not receive email, then putting a loopback address in for the MX record causes the sending server to attempt to connect to itself. This saves the DIQ a few measley bytes and possibly cleans up the firewall logs (if anyone is even watching) when other mail servers attempt to connect. However, in my opinion, the bandwidth savings is not enough to justify violating RFC 3330.

longneck
  • 22,793
  • 4
  • 50
  • 84
  • It's an ugly practice but not a violation of RFC 3330 or RFC 1700. The restrictions there have nothing to do with hostnames. Those standards only prohibit letting an IP packet having a 127.0.0.0/8 address in the source or destination field escape the host. For example, ping 127.0.0.1 should never, ever cause an ICMP packet to be seen by any other host on the LAN. – MetaEd May 21 '22 at 15:18
4

When a host must be able to send mail to itself across different hosted domains but does not accept external mail, "MX 0 localhost." is acceptable. To indicate that a host has no mail server whatsoever, use "MX 0 ."

The "MX 0 ." is detailed in RFC7505.

Community
  • 1
Mr. X
  • 200
  • 1
  • 2
3

Well, I have a situation where setting a domain's MX to localhost appears to be necessary.

In March of 2012 I registered a cute domain that I was surprised to find available. It was for an artistic collaboration site my daughter wanted to set up. I set the MX to one of my other smtp servers. This worked well, but then I started to get lots of "unknown user" mail bounces to xxx@cute-domain.com (not the real domain name). So I used MailScanner to block all incoming messages to that domain except for one legitimate address. It seems that the domain was a free email service starting in 2001 but had apparently gone dark and gave up their cute domain name.

This worked well until a couple of days ago (11/20/12) when the smtp server started to reject incoming messages due to excessive open connections. These were smtp processes waiting for "receipt to" responses, I think. I looked at the traffic and I was getting bombarded by thousands of incoming messages for xxx@cute-domain.com from just as many smtp relays all over the world. (17,000 messages in one 24-hour period)

So I changed the MX to point to another server not running smtp with port 25 blocked. Sure enough, thousands of dropped sessions started showing up. Since this behavior looks like some sort of a spam torrent, maybe from a botnet, I figured that setting the MX to localhost might be called for.

I'll leave it like this for a while. We don't need email at all for the cute.domain.com, so nothing is lost except cycles for the botnet.

Wolfgang
  • 31
  • 1
-1

Why not use a MX target that doesn't resolve to anything? E.g.:

example.com. IN MX 10 something.invalid.

Spammers will see the resolution error and not bother with the next MX record, thinking the target is misconfigured. Real servers will try the next record. This won't bother anyone's closed TCP port 25 - i.e. no smtp traffic, only DNS.

MR.X
  • 1