It does not matter on an operational level.
It just depends on the UI you have to manage records.
On the most bare bone case, that is the textual zonefile, you can always write records as fully qualified domain names (and then they end with a .
to clearly show they are absolute and full name from the root) or as relative from the zone.
It makes no difference to the nameserver serving those records.
And @
is a shortcut/alias to the zone name, so putting @
or example.com.
is the same.
It may matter on a maintenance level.
But it depends on how the zone is maintained. If it is not through an UI, you basically deal with "zonefiles". They are pure text documents encoding in "master zone file format" the details of the zone, that is the list of its records.
Now, you may be in the case of configuring a nameserver handling multiple zones and all zones being exactly the same as for their records. With some nameservers you can hence configure all zones by pointing them to the same zonefile... which will then work only if the zonefile has relative records (that is www
instead of www.example.com.
) because those relative records will be resolved per the zone they are in, so they can be applied to multiple zones.
It is a frequent trick to simplify maintenance. One may want to just use relative names even outside this case, to have less to type (and hence less chance of typos), and prepare anyway for the future where same file could be used for multiple zones.
If you are not directly managing nameservers but just using some provider UI to maintain records, you should never be exposed to any difference: a good UI will allow you to enter both versions (relative or absolute) and will adapt as needed (normally it should normalize to any one of the two so that when you come back to edit again all records look the same otherwise it will difficult to make sense out of them).
PS:
DNS settings propagation takes up to 24h
(as stated in post before edit)
That is false, please do not propagate this myth.
If you change records on your authoritative nameserver they should be there immediately. You can (and should) query first your authoritative nameserver directly when doing tests and then only after the recursive one. Also you control the TTL associated with your records anyway.
PS: do not obfuscate badly (I edited your post). Use example.com
and not any made up name, especially ones that do exist for real...
If you want details, please see RFC 2606 - Reserved Top Level DNS Names (note also that there are equivalent instructions, in other documents, for IPv4 and IPv6 addresses for the same reason). And if you are curious on why this needs to be followed, it is just that for example some TLDs like .home
or .mail
will "never" exist globally just because they were so much abused in documentation and hence in live systems as people just copy and paste things without edit, that if they are introduced globally they will make many systems fail. It is the same for IP addresses, some seems "appealing" like 1.1.1.1
but this is now a live IP address that hosts a public well known service and using it as documentation and people creating configuration with it and sending to it various crap is not good for the Internet. In fact this IP address is still in a block considered "for research" as people are continuing to carefully look at what happens here and all sort of unwanted traffic sent to it. If interested by that point look at https://conference.apnic.net/46/assets/files/APNC402/DNS-resolver-1.1.1.1-from-Cloudflare.pdf or https://networkingnerd.net/2018/04/05/reclaiming-1-1-1-1-for-the-internet/ or https://labs.ripe.net/Members/marty_strong/fixing-reachability-to-1-1-1-1-globally to see how much this IP address has been misused...