Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

ZONE09: MX record present

Test case identifier

ZONE09

Table of contents

Objective

It is strongly recommended in RFC 2142, section 7, that every domain should have a mailbox named HOSTMASTER@domain (where "domain" is Child Zone in this test case).

For simplicity and regularity, it is strongly recommended that the well known mailbox name HOSTMASTER always be used <HOSTMASTER@domain>.

This test case therefore expects for every domain (zone), excluding some cases described below, to publish an MX record in apex of the zone (i.e. in the same node as the SOA record).

If MX is not present, SMTP can deliver email using an address record (A or AAAA) as specified in RFC 5321, section 5.1, but that possibility is not in common use. This test case only checks for MX record and ignores the possibility to use address records for email.

Even if not mentioned in RFC 2142, there are some exceptions to the rule to include MX and a mail exchange for a domain.

The purpose of a zone in the .ARPA tree is to hold infrastructural identifiers, and it is not expected that such a zone name is used as Email Domain (RFC 3172). This also means that the well known mailbox is not expected for reverse zones (zone under in-addr.arpa or ip6.arpa). Such zone are therefore excluded by this test case from the requirement of MX in the apex.

The root zone cannot be an Email Domain since the email domain is the part to the left of the trailing dot, and the root zone owner name has nothing left of the trailing dot. The root zone is excluded by this test case from the requirement of MX in the apex.

Top-level domains (TLDs) can technically function as Email Domains (RFC 5321, section 2.3.5) but they rarely have that function and are probably not meant to be included in the specification in RFC 2142. Internet Architecture Board concludes in a report "Dotless Domains Considered Harmful" that domain names that only consists of one label, e.g. "se", "fr" or "com", should not be used for various Internet services. This means TLD names should not be used as Email Domains. In this test case TLDs are not only excluded from the requirement of being an Email Domain, if found to be, a message will be generated that points that out.

RFC 7505 standardizes "Null MX" which means that there is no email service for the domain. A "Null MX" is accepted for any type of domain. RFC 7505, section 3, also specifies that the "Null MX" must be the sole MX record and its preference must be zero.

In this test case, the following zone types are excluded from the requirement of MX, and in such zones it is not expected to find any MX (in apex).

  • Root zone
  • TLD zone
  • Zone in the .ARPA tree

For a TLD zone it is considered to be harmful to include MX in apex (IAB Statement).

Scope

It is assumed that Child Zone is tested and reported by Connectivity01. This test case will just ignore non-responsive name servers or name servers not giving a correct DNS response for an authoritative name server.

Inputs

  • "Child Zone" - The domain name to be tested.

Summary

Message TagLevelArgumentsMessage ID for message tag
Z09_ARPA_EMAIL_DOMAINNOTICEThe zone is in the ARPA tree and has an unexpected MX RRset (non-Null MX).
Z09_INCONSISTENT_MXWARNINGSome name servers return an MX RRset while others return none.
Z09_INCONSISTENT_MX_DATAWARNINGThe MX RRset data is inconsistent between the name servers.
Z09_MISSING_MAIL_EXCHANGENOTICEns_listThe child zone has no mail exchange (no MX), as returned by name servers "{ns_list}".
Z09_MX_DATAINFOns_list, mxrdata_listThe MX RDATA in the MX RRset, "{mxrdata_list}", as returned by name servers "{ns_list}".
Z09_MX_FOUNDINFOns_listMX RRset was returned by name servers "{ns_list}".
Z09_NON_AUTH_MX_RESPONSEWARNINGns_listNon-authoritative response on MX query from name servers "{ns_list}".
Z09_NO_MX_FOUNDINFOns_listNo MX RRset was returned by name servers "{ns_list}".
Z09_NO_MX_FOUND_OR_EXPECTEDINFOMX RRset was neither found nor expected for the zone.
Z09_NO_RESPONSE_MX_QUERYWARNINGns_listNo response on MX query from name servers "{ns_list}".
Z09_NO_SERVERS_MX_RESPONSEWARNINGNo server responds to MX query.
Z09_NULL_MX_NON_ZERO_PREFNOTICEThe zone has a Null-Type MX record with non-zero preference.
Z09_NULL_MX_WITH_OTHER_MXWARNINGThe zone has a Null MX or a Null-Type MX record mixed with other MX records.
Z09_ROOT_EMAIL_DOMAINNOTICERoot zone with an unexpected MX RRset (non-Null MX).
Z09_TLD_EMAIL_DOMAINNOTICEThe zone is a TLD and has an unexpected MX RRset (non-Null MX).
Z09_UNEXPECTED_RCODE_MXWARNINGns_list, rcodeUnexpected RCODE name ({rcode}) in response to MX query. Responses from name servers "{ns_list}".
Z09_VALID_NULL_MXINFOThe zone has a valid Null MX record as the only MX record.

The value in the Level column is the default severity level of the message. The severity level can be changed in the Zonemaster-Engine profile. Also see the Severity Level Definitions document.

The argument names in the Arguments column lists the arguments used in the message. The argument names are defined in the argument list.

The name server names are assumed to be available at the time when the msgid is created, if the argument name is "ns" or "ns_list" even when in the "Test procedure" below it is only referred to the IP address of the name servers.

Test procedure

In this section and unless otherwise specified below, the terms "DNS Query" follow the specification for DNS queries as specified in DNS Query and Response Defaults. The handling of the DNS responses on the DNS queries follow, unless otherwise specified below, what is specified for DNS Response in the same specification.

  1. Create a DNS Query with query type SOA and query name Child Zone ("SOA Query").

  2. Create a DNS Query with query type MX and query name Child Zone ("MX Query").

  3. Obtain the set of name server names and IP addresses using methods Get-Del-NS-Names-and-IPs and Get-Zone-NS-Names-and-IPs ("Name Servers").

  4. Extract the unique set of name server IP addresses from Name Servers ("Name Server IPs").

  5. Create the following empty sets:

    1. Name server IP address ("No Response MX Query").
    2. Name server IP address and associated RCODE Name ("Unexpected RCODE MX Response").
    3. Name server IP address ("Non-authoritative MX").
    4. Name server IP address ("No MX RRset").
    5. Name server IP address and associated ordered list of MX RDATA ("MX RDATA Lists").

  6. For each name server IP in Name Server IPs do:

    1. Send SOA Query over UDP to the name server.

    2. Go to next name server IP if at least one of the following criteria is met:

      1. There is no DNS response.
      2. The RCODE Name of the response is not "NoError".
      3. The AA flag is not set in the response.
      4. There is no SOA record with owner name matching the query.

    3. Send MX Query over UDP to the name server. Collect the DNS response and:

      1. If there is no DNS response, then add the name server IP to the No Response MX Query set.
      2. Else, if the RCODE Name of response is not "NoError", then add the name server IP and the RCODE Name to the Unexpected RCODE MX Response set.
      3. Else, if the AA flag is not set in the response, then add the name server IP to the Non-authoritative MX set.
      4. Else, if there is no MX record with matching owner name in the answer section, then add the name server (IP) to the No MX RRset set.
      5. Else do:
        1. Extract the MX records from the response.
        2. For each MX record down case the (mail) exchange (domain name).
        3. Ignore duplicate MX records (identical RDATA).
        4. For each MX record extract the RDATA as a text string of space separated preference (integer) and exchange, i.e. in the same format as MX RDATA is shown in presentation format.
        5. Create a sorted list of the RDATA text strings where primary sort key is the preference (ascending order) and the secondary sort key is the exchange (ascending order).
        6. Add the name server IP and the sorted list to the MX RDATA Lists set.

  7. If the No Response MX Query set is non-empty, then output Z09_NO_RESPONSE_MX_QUERY with the name server IP addresses from the set.

  8. If the Unexpected RCODE MX Response set is non-empty, then for each RCODE Name in the set output Z09_UNEXPECTED_RCODE_MX with the RCODE Name and the name server IP addresses from the set.

  9. If the Non-authoritative MX set is non-empty, then output Z09_NON_AUTH_MX_RESPONSE with the name server IP addresses from the set.

  10. If the MX RDATA Lists set is non-empty then for each unique list in MX RDATA Lists, output Z09_MX_DATA with the list and the associated name server IP addresses in the set.

  11. If both No MX RRset set and MX RDATA Lists set are non-empty then:

    1. Output Z09_INCONSISTENT_MX.
    2. Output Z09_NO_MX_FOUND with the name server IP addresses from the No MX RRset set.
    3. Output Z09_MX_FOUND with the name server IP addresses from the MX RDATA Lists set.

  12. If the MX RDATA Lists set is non-empty then do:

    1. If the lists in MX RDATA Lists are not equal for all name servers then do:
      1. Output Z09_INCONSISTENT_MX_DATA.
    2. Else do:
      1. Extract the unique list of RDATA from MX RDATA Lists.
      2. If any of the MX in the list is a Null MX or a Null-Type MX, then do:
        1. If there are more than one item in the list, then output Z09_NULL_MX_WITH_OTHER_MX.
        2. Else, if the preference in the MX RDATA in the list is non-zero (Null-Type MX) then output Z09_NULL_MX_NON_ZERO_PREF.
        3. Else, output Z09_VALID_NULL_MX.
      3. If at least one MX record in the list is neither a Null MX nor a Null-Type MX then do:
        1. If Child Zone is a TLD then output Z09_TLD_EMAIL_DOMAIN.
        2. If Child Zone is the root zone then output Z09_ROOT_EMAIL_DOMAIN.
        3. If Child Zone is a zone in the ARPA tree, not .ARPA itself, then output Z09_ARPA_EMAIL_DOMAIN.

  13. If the No MX RRset set is non-empty and the MX RDATA Lists set is empty then:

    1. If Child Zone is the root zone ("."), a TLD or a zone in the .ARPA tree then output Z09_NO_MX_FOUND_OR_EXPECTED.
    2. Else, output Z09_MISSING_MAIL_EXCHANGE with the name server IP addresses from the No MX RRset set.

  14. If both the No MX RRset set and the MX RDATA Lists set are empty, then output Z09_NO_SERVERS_MX_RESPONSE.

Outcome(s)

The outcome of this Test Case is "fail" if there is at least one message with the severity level ERROR or CRITICAL.

The outcome of this Test Case is "warning" if there is at least one message with the severity level WARNING, but no message with severity level ERROR or CRITICAL.

In other cases, no message or only messages with severity level INFO or NOTICE, the outcome of this Test Case is "pass".

Special procedural requirements

If either IPv4 or IPv6 transport is disabled, ignore the evaluation of the result of any test using this transport protocol and log a message reporting the ignored result.

Intercase dependencies

None.

Terminology

  • "Null MX" - The term is used for an MX record where the preference is 0 and the (mail) exchange is "." as defined in RFC 7505 with the specific restrictions given in section 3 of that RFC.

  • "Null-Type MX" - The term is used for an invalid Null MX where the mail exchange is "." as in Null MX but the preference is non-zero. See Null MX.

  • "TLD" - The term is used for "Top Level Domain", i.e. a zone whose name consists of a single label (ignoring the empty label after the final dot).

  • "Email Domain" - The term is used for the domain name at right of the at-sign ("@") in an email address.