If you are like me, proper DNS formatting was elusive and challenging to wrap your head around, particularly because of the trailing period. I would consistently create incorrect DNS records because I did not understand the DNS trailing period and how it was interpreted by different UI systems. My records would end up looking like this:
domain.com.domain.com. A 220.127.116.11
domain.com. NS ns1.domain.com.domain.com.
I never needed domain.com repeated, and could never understand why it was happening.
DNS itself has a root zone and that zone is literally called “.”. A fully qualified DNS name always includes the . or root zone. Depending on the DNS system you are using and it’s UI implementation you may or may not need to add the trailing period. You would not need the trailing period if the UI assumes the root zone for you and ensured you would always have FQDN (Fully Qualified Domain Name, including the trailing period). The trailing period ultimately indicates that you do not want .domain.com. added to the end of your value. If the trailing period were omitted, then domain.com. would be automatically added to the end of the value. In UIs that do not automatically assume a FQDN you could end up with the duplicate domain problem.
The Solution for Different UIs
If you are using a system that assumes the root zone for you and you entered something like the following, you would end up with duplicate domains:
domain.com. NS ns1.domain.com
Note how there is no trailing period at the end of ns1.domain.com. What this does is cause the backend to append the domain.com along with trailing period which is the root zone. Depending on the UI you are using, you will either want to specify just ns1 and let the the backend assume the root zone .domain.com. for you, or specify the FQDN yourself as ns1.domain.com.
If in doubt what your systems UI expects, using the FQDN ns1.domain.com. with the trailing period should almost always give the intended results.