I believe that the easiest answer for the first question is "No, You have "A" for this", but I accidentally setup some subdomain using CNAME pointing to ip address and it worked on few computers in my office. I wonder how it was possible?
Now, when I'm checking it from home I have following error:
beast:~ viroos$ host somesubdomain.somedomain.com
Host somesubdomain.somedomain.com not found: 3(NXDOMAIN)
I'm 100% it used to work at my office (currently it looks like it doesn't, but I'm checking it on different machine). Therefore I'm not 100% if it worked due to some special network setup or because I tested it just after adding DNS entry.
I know this story sounds, a little crazy/incredibly, but can someone help me solve this puzzle.
//edit: I'm adding dig output
; <<>> DiG 9.6-ESV-R4-P3 <<>> somesubdomain.somedomain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60224
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;somesubdomain.somedomain.com. IN A
;; ANSWER SECTION:
somesubdomain.somedomain.com. 67 IN CNAME xxx.xxx.xxx.xx1.
;; AUTHORITY SECTION:
. 1800 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2012040901 1800 900 604800 86400
;; Query time: 72 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Apr 10 00:11:01 2012
;; MSG SIZE rcvd: 136
The data on a
CNAME
record must always be another DNS name - that's the whole point of aCNAME
.As put succinctly by RFC 1034, the data in a
CNAME
should be:While, if you're looking to point to an IP address, then your ticket is:
CNAME
is designed and implemented to be a DNS alias; it has no conception of having an IP address in that data field. As such, it's interpreted as an alias to another DNS name, as designed; after all, an IP address fits the syntax of a DNS name.So, for example's sake, let's say your DNS data is:
The recursive DNS server that you're querying sees that the record is a
CNAME
, and figures that you'll want the actual data that it contains. No record other than theCNAME
has been found, so there's no answer to give to the client.It tries to query a record for a hostname
192
, within the domain0.2.1
. It doesn't have anything cached for that name, so it asks the root servers. They serve requests for TLDs like.com
and.net
, but this request is a request for.1
. They promptly respond that there is no such, and that's what the recurser sends on to you.The response that you're seeing in
dig
is your recursive name server saying, "well, the name you looked for pointed somewhere else, and that somewhere didn't exist - ask the root server if you don't believe me".So, yes, putting an IP address in a
CNAME
record is never valid, and I suspect that the systems that are working are functioning correctly through some other mechanism, like a hosts file or local name resolution - investigate their name resolution behavior.cname is canonical name, which is just an alias of another name, which is usually the A record or another cname, etc. If you set up cname to point to an IP, then it is just an alias of that IP. I don't think your DNS server checks whether the target is legitimate or not, because the standard RFC does not really say what is the data format/validation for the target of cname is. This is not a usual usage, but if it is working for you then it is working. The fact that it is not working sometimes should be enough for you to use what it is conventionally used, I think.
You can have:
where 1.2.3.4 is a working IP address. Notice the trailing dot in the CNAME though. The fact that some machines in your office do work with this, while others do not leads me to believe that the ones that do have the subdomain set in the
lmhosts
or/etc/hosts
file.