Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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!

share|improve this question
    
The first and second example has no connection with the reverse lookup. The reverse lookup is controlled by the PTR record for that particular IP. en.wikipedia.org/wiki/Reverse_DNS_lookup –  artifex Mar 31 '10 at 12:55
    
@artifex, yes, I know :) It's just for simplicity I didn't include the PTR records, but for each IN A there is a corresponding IN PTR. –  rytis Mar 31 '10 at 13:43
    
"This is bit of a theological question": theology only comes into play when your hostname ends in .va. –  janmoesen Apr 2 '10 at 18:22
add comment

3 Answers 3

up vote 6 down vote accepted

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.

share|improve this answer
add comment

Generally speaking, the hostname should be an A record, since there are places where it's not permitted to use CNAME when that hostname is referred to in other DNS records (e.g. the MX record 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:

$ORIGIN example.com
@       IN SOA (...)
en0.server IN A 10.0.0.1
en1.server IN A 10.0.1.1
lo1.server IN A 192.168.1.1
www        IN CNAME lo1.server

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 A record pointing at the public interface (seeing as that's the one the outside world sees) and then separate A records for the two internal interfaces.

share|improve this answer
    
This is interesting. Firstly (I'm also going to update the question with this info) 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). Now going back to your example, what would you set the hostname to? Would that be 'server'? Or one of the interfaces (en0,1,lo1)? Or would that be a nonresolvable entry like server.example.com ? –  rytis Mar 31 '10 at 10:25
    
re update. So I'd then have two A records pointing to the same IP? again, nothing wrong with that, technically, but from management POV it requires someone to keep that in mind when updating the DNS if the IP ever needs to change... –  rytis Mar 31 '10 at 13:41
1  
yup, that's right, it's slightly more management overhead. However there are many cases where you can't use a CNAME anyway (e.g. if you want a webserver without a www prefix). –  Alnitak Mar 31 '10 at 16:31
add comment

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

share|improve this answer
2  
Most servers will include the A record in the additional records section of the CNAME query, so it doesn't have to require two queries. –  Spiff Mar 31 '10 at 8:22
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.