19

IETF RFC 7505 describes MX records for a domain/host that explicitly should not receive email. This is accomplished by pointing the MX at the Domain Name System root. For example,

nomail.example.com. 86400 IN MX 0 "."

Why is this needed? In my understanding, explicit refutation is available by using domains under the TLD invalid. For example,

nomail.example.com. 86400 IN MX 0 "spam.invalid."
nomail.example.com. 86400 IN MX 10 "null.invalid."

I see that RFC 2782, DNS SRV, likewise specifies that "A Target of '.' means that the service is decidedly not available at this domain." So I suppose my question is:

Why should we use the DNS root to mean "not available" when invalid already serves this function?

1
  • 3
    That is not an explicit refutation, though! It's merely invalid data. Aug 13, 2015 at 21:28

2 Answers 2

23

Because that is not what you are supposed to be using .invalid for. Like .example it is meant for local testing and documentation.

Additionally, using .invalid still causes additional things to happen - additional DNS look ups and queuing on the mail server for retries for one off the top of my head.

Using the "." format is supposed to cause an immediate hard fail. Causing the MTA to immediately stop attempting delivery. At least that's the way the intro to the RFC reads.

7
  • 3
    Thanks. The but BCP: 32/RFC 2606 Section 2 reads " '.invalid' is intended for use in online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid." 2606 says nothing to indicate that ".invalid" is only for local testing. It is for any domain that must be, well, invalid Aug 13, 2015 at 21:40
  • Ok I can see why something that looks like it could be a host's name would be disadvantageous to compared to ".". Aug 13, 2015 at 21:48
  • 1
    @AlphaWhiskey It's humans who can "glance" at something and draw conclusions. Computers need explicit instruction. Aug 13, 2015 at 22:39
  • 3
    to be fair, it's not exactly hard to give computers explicit instruction in this particular case.
    – muhmuhten
    Aug 14, 2015 at 2:01
  • @res It's even easier not to give computers that explicit instruction.
    – musiKk
    Aug 14, 2015 at 14:04
10

The question as a whole touches on a few different aspects which all need to be taken into consideration to answer why RFC7505 adds something useful.


First of all, the pre-RFC7505 definition of how mail delivery should be made does not have a way to cleanly indicate that no mail delivery attempts should be made for a name which has address records.

From RFC7505 section 1:

SMTP clients have a prescribed sequence for identifying a server that accepts email for a domain. Section 5 of [RFC5321] covers this in detail; in essence, the SMTP client first looks up a DNS MX RR, and, if that is not found, it falls back to looking up a DNS A or AAAA RR. Hence, this overloads a DNS record (that has a different primary mission) with an email service semantic.

If a domain has no MX records, senders will attempt to deliver mail to the hosts at the addresses in the domain's A or AAAA records. If there are no SMTP listeners at the A/AAAA addresses, message delivery will be attempted repeatedly for a long period, typically a week, before the sending Mail Transfer Agent (MTA) gives up. This will delay notification to the sender in the case of misdirected mail and will consume resources at the sender.

This document defines a null MX that will cause all mail delivery attempts to a domain to fail immediately, without requiring domains to create SMTP listeners dedicated to preventing delivery attempts.


Then there's the matter of how RFC7505 implements this (IN MX 0 .).

From RFC7505 section 3:

  1. MX Resource Records Specifying Null MX

To indicate that a domain does not accept email, it advertises a single MX RR (see Section 3.3.9 of [RFC1035]) with an RDATA section consisting of preference number 0 and a zero-length label, written in master files as ".", as the exchange domain, to denote that there exists no mail exchanger for a domain. Since "." is not a valid host name, a null MX record cannot be confused with an ordinary MX record. The use of "." as a pseudo-hostname meaning no service available is modeled on the SRV RR [RFC2782] where it has a similar meaning.

A domain that advertises a null MX MUST NOT advertise any other MX RR.

(emphasis added)

As is noted here, the implementation details for the "null MX" are based on an already established pattern from the SRV RR type. It makes sense to mimic this as the SRV RR type more or less is a generalized version of the MX RR type.

So, the decision was essentially taken already when defining the SRV RR type.


So, why not make use of `.invalid`?

From RFC2606 section2:

".invalid" is intended for use in online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid.

As can be seen here, this reserved TLD is for human consumption. There's no precedent of defining special handling of this in software.

Surely it could have been implemented in some different way but they chose to go with the minimal approach of using ., which is not a valid hostname and thus does not interfere with normal use anyway.

13
  • As far as I can tell there is no technical reason . couldn't have been used as MX record if A or AAAA records had been published at the root. When I type telnet . 25 it surely does look for A and AAAA records at the root.
    – kasperd
    Aug 14, 2015 at 8:43
  • 1
    @kasperd While the DNS protocol can surely represent it, I don't believe having address records at . or (pre-RFC7505) specifying . as the EXCHANGE value for an MX record would actually be valid. (It's not a valid hostname.) Aug 14, 2015 at 19:16
  • Valid or not - I can easily imagine implementations which when faced with an MX record pointing to a domain with no A records will retry delivery for days before giving up.
    – kasperd
    Aug 14, 2015 at 19:59
  • “If there are no SMTP listeners” - does this imply that if there are no A or AAAA records, the null MX record is not helpful?
    – twhb
    Jun 17, 2022 at 19:31
  • @twhb If there are no address records (A/AAAA) and no MX records, there would be no place to attempt delivering mail for this domain name anyway (at least based on DNS). Adding a null MX for such a domain name would just be making an explicit statement matching what was already the case. Jun 18, 2022 at 10:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .