Domain verification range

A DNS server returns a certain amount of information. In particular, it returns the list of name servers (NS records), the list of mail servers (MX records), the list of host IP addresses (A records), the list of aliases (CNAME records) and the authority file (SOA record). The values returned by a DNS server are not taken at random, and require some thought as to their relevance. Conflicts can also arise, particularly with CNAME records. In order to verify the value of these fields in our dnslookup.fr tool, we decided to carry out a study of these values. We will therefore compare 3 types of source. The first source is represented by all the RFCs provided by the IETF. This is the most official source and is therefore our point of comparison. The second source is a DNS analysis tool built by Vitalie Cherpec, dnsvalidation. This tool is not an official source, but offers a large number of checks that are made on DNS responses, so it’s interesting to establish the relevance of these checks. The final source of comparison is the tool provided by AFNIC for domain analysis, ZoneCheck. This tool is an official source, as AFNIC (Association française pour le nommage Internet en coopération) is an association under the French law of 1901, created by the joint will of INRA and the French state. AFNIC also manages the .fr, .re and .tf TLDs.

Here is a table comparing the values used in dnsvalidation, zonecheck (formerly an Afnic service) and the RFCs:

SOA fields

The periodicity of version checking by secondary servers is defined by parameters flagged in the SOA RR assigned to the zone, which define the minimum interval between two checks. These parameters are called REFRESH, RETRY and EXPIRE. When a zone is registered in a secondary server, the latter will wait REFRESH seconds before checking on the primary to see if a new serial number has been given for the zone. If this check cannot be performed, new attempts will be made every RETRY seconds. Verification is a simple request to the zone’s SOA RR on the main server. If the serial number in the copy hosted by the secondary is equal to the serial number indicated in the RR returned by the request, then no update is necessary, and the REFRESH timer must be reactivated. If the secondary server fails to perform the check after the EXPIRE interval has elapsed, it must admit that its copy of the zone is obsolete and delete it.

This leads to the following formula to ensure consistency of verification periodicity: RETRY < REFRESH < EXPIRE.

The values of the “expire”, “retry”, “refresh” and “minimum TTL” fields marked above are recommendations and do not commit the user to respecting them. However, these fields are coded on 32 bits. The fields therefore accept values between 0 and 2147483647 (value in seconds, i.e. approximately 24855 days, or about 68 years). The maximum is the value of 2^31 – 1 because the sign bit is set to 0.

CNAME records

According to RFC 1912, a CNAME record cannot coexist with other data. In other words, if toto.domain.tld is an alias for server.domain.tld, then there can be no A, NS, MX or even TXT record for toto.domain.tld. For example, it is forbidden to have :

toto.domaine.tld     IN           CNAME           server.domaine.tld
toto.domaine.tld     IN           A               1.2.3.4

The fields must be entered as follows:

toto.domaine.tld     IN           CNAME           server.domaine.tld
server.domaine.tld   IN           A               1.2.3.4

Avoid combining CNAMEs with NSs as follows:

domaine.tld          IN           NS              ns1
domaine.tld          IN           NS              ns2
domaine.tld          IN           CNAME           toto
toto                 IN           A               1.2.3.4

If you want your domain name to be defined as a host, write it like this:

domaine.tld          IN           NS              ns1
domaine.tld          IN           NS              ns2
domaine.tld          IN           A               1.2.3.4
toto                 IN           A               1.2.3.4

As no other records can coexist with the CNAME records, the A record in the first example and the NS records in the second example will be ignored. However, CNAMEs are useful (and even recommended) for generic server names: ‘ftp’ for the FTP server, ‘www’ for the Web server …

On the other hand, CNAME records must not point to other names such as MX, CNAME, PTR and NS. For example, we strongly advise against :

domaine.tld           IN          MX              mail
mail                  IN          CNAME           toto
toto                  IN          A               1.2.3.4

The valid correspondence to these records would be :

domaine.tld           IN          MX              mail
mail                  IN          A               1.2.3.4

Furthermore, RFC 1034, section 3.6.2 states that this is prohibited. And RFC 974 explicitly states that MX records must not point to an alias defined as a CNAME.

However, RFC 2821 contradicts this. This RFC describes the technical aspects of the SMTP protocol. Section 5 is of particular interest to us, as it describes the technical aspects of address resolution for messaging. When resolving a mailbox, the SMTP client must lexically identify the domain for which mail is to be delivered.

A DNS lookup must be performed to resolve the domain name. The search first aims to locate an MX record associated with the domain name.

However, if a CNAME record is found instead, the resulting name is treated as if it were the domain name.

If no MX record exists but an A record is found, the latter is treated as if it were associated with an implicit MX record, with a preference of 0, pointing to this host.

If one or more MX records are found for a given name, SMTP systems must not use any A records associated with this domain name. If MX records are present, but none of them are usable, this situation must be reported as an error.

In conclusion, the SOA values “EXPIRE”, “REFRESH”, “RETRY” and “Minimum TTL” are similar between the different sources. Since no source tells us that these values must be strictly adhered to, or that they cause errors, we’ll find a compromise to set up the check in our dnslookup.fr tool. However, the order EXPIRE > RETRY > REFRESH is common to all sources and avoids update errors on secondary DNS servers.

For the respect of CNAME records, we will take the most recent RFCs as a reference. In this way, we check that no records corresponding to the domain name coexist with CNAME records, and that data from NS and MX records are not used in CNAME records.