In the example zone files given by Gandi I notice that the CNAME and MX records end with a period "." However, TXT and A records do not. Is that the correct format for these types of DNS entries in Gandi? I know this differs depending upon the registrar. Some require the period at the end and some do not.
Yes, that is the correct format.
CNAME and MX records refer to other DNS names. The dot at the end of the DNS name (such as in CNAME and MX records) indicates that you have entered an name that is the absolute name (traced back to the DNS root) rather than a relative name.
A records refer to an IP address and are always considered absolute. TXT records contain arbitrary text, so the difference between "absolute" and "arbitrary" doesn't apply.
Say if you have the domain name "example.com", and you want to set up an MX record so that mail addressed to username@example.com is handled by the server "mail.example.net".
In the example.com zone file, you would enter:
@ 10800 IN MX 10 mail.example.net.
If, instead, you entered a name with a trailing dot,
@ 10800 IN MX 10 mail.example.net
the DNS server would interpret that line as being a name relative to example.com ("mail.example.net.example.com"), rather than an absolute name.
Of course, one could use relative names. For example, say you have the domain "example.com" and want the server "mail.example.com" (note that both are in the example.com domain, rather than being in separate domain names as before) that exists at IP address 10.0.0.1 to handle mail for the domain. You could configure the example.com zone file in two ways:
#1 - Absolute Names
mail 10800 IN A 10.0.0.1
@ 10800 IN MX 10 mail.example.com.
#2 Relative Names
mail 10800 IN A 10.0.0.1
@ 10800 IN MX 10 mail
Both function exactly the same way and are equally valid, but you can only use relative names if you're referring to names within the same domain. You must use absolute names when referring to names at other domains.
I find that using absolute names for CNAME and MX records, even those within the same domain, is less error-prone as there is no ambiguity.
Last modified: 14 Mar 2012 at 13:34 by Pete S.