This is bit of a theological question, but nonetheless...
So, a server has a hostname, let's say the fqdn is hostname.example.com (to be really precise about what I mean, this is the name that is set in /etc/sysconfig/network).
The very same server has multiple interfaces on different subnets. Let's say the IPs are 10.0.0.1 and 10.0.1.1.
Now the question is, is it theoretically (mind you, this is important, I know that practically it works, but I'm interested in purely academic answer) allowed to have the following setup:
interface1.example.com. IN A 10.0.0.1
interface2.example.com. IN A 10.0.1.1
hostname.example.com. IN CNAME interface1.example.com.
OR should it rather be:
hostname.example.com. IN A 10.0.0.1
interface2.example.com. IN A 10.0.1.1
interface1.example.com. IN CNAME hostname.example.com.
I guess it's obvious which one is making more sense from the management/administration POV, but is it technically correct?
The argument against the first setup is that a reverse lookup to 10.0.0.1 returns interface1.example.com and not what one might expect (ie the hostname: hostname.example.com), so the forward request and then sub sequential reverse lookups would return different results.
Now, as I said, I want a theoretical answer. Links to RFC sections etc, that explicitly allows or disallows use of CNAME name as a hostname. If there's none, that's fine too, I just need to confirm. I failed to find any explicit statements so far, bar this book, where this situation is given as an example and implies that it can be done as one of the ways to avoid MX records pointing to a CNAME.
UPDATE: Multiple interfaces are not for redundancy (they're bonds anyway) but to achieve a logical separation in traffic. For example all DB traffic is on subnet A, services traffic is on subnet B and public access is on subnet C.
UPDATE2: Looks like this is not regulated by RFCs/other rules and is a matter of preference. Therefore I'll mark @Vatine answer as the workable answer for now which implies that there are no regulations. Also many thanks to @Alnitak for suggestions and discussion!
I'd go as far as saying that there is no connection, at all, between the records in DNS and what a server tells you its name is, so from a DNS point of view, the only difference between your two scenarios is what name goes where.
From the machine's point of view, it doesn't care. However, from your users' perspective, I'd pick one of the two and then stick to it.
Generally speaking, the hostname should be an
Arecord, since there are places where it's not permitted to useCNAMEwhen that hostname is referred to in other DNS records (e.g. theMXrecord case you gave).For what it's worth, I'd wonder what you're trying to achieve by having multiple interfaces?
If they're to provide redundancy, then a better method than publishing the IP address of a specific physical address is to configure a public IP address on a "virtual" (or loopback) interface. Then use routing protocols (e.g. OSPF) to ensure that traffic to that address can use either physical interface.
What you might then get is:
This achieves resiliency by ensuring that the announced public IP address is reachable even if one of the physical interfaces go down.
update: as this is for traffic separation, I'd personally make the bare hostname an
Arecord pointing at the public interface (seeing as that's the one the outside world sees) and then separateArecords for the two internal interfaces.I would put it in this way: an IN CNAME requires two DNS queries, an IN A requires a single DNS query.
Personally, I don't like IN CNAMEs and I use only IN A