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

;somesubdomain.somedomain.com.      IN  A

somesubdomain.somedomain.com.   67  IN  CNAME   xxx.xxx.xxx.xx1.

.           1800    IN  SOA a.root-servers.net. nstld.verisign-grs.com. 2012040901 1800 900 604800 86400

;; Query time: 72 msec
;; WHEN: Tue Apr 10 00:11:01 2012
;; MSG SIZE  rcvd: 136
  • 2
    Are you sure it wasn't something else that made the office machines work? Cached entries? Authoritative server for that domain on the local network overriding the public resolution? Hosts files? – Shane Madden Apr 9 '12 at 21:05
  • To be precise it worked on two machines, both are OSX It didn't work on Ubuntu machine. Since it was working on two machines I ignored "the ubuntu" problem (that was a mistake) since I believed it was dns propagation issue or dns cache. I only checked DNS setup on each client and it was the same (this left some uncertainty regarding DNS propagation theory). One of those machines is my MacBook and I'm currently using it from home and the website that I setup doesn't work correctly on it any more: "The server at somesubdomain.somedomain.com can't be found, because the DNS lookup failed." – Maciek Sawicki Apr 9 '12 at 21:34
  • What's returned when you query for the name using dig? – Shane Madden Apr 9 '12 at 21:59
  • I added dig output, to question. – Maciek Sawicki Apr 9 '12 at 22:14
  • I strongly suspect the OSX computers are using something other than DNS to do the lookup, like mDNS (which isn't the same thing at all). – Chris S Apr 10 '12 at 3:30

The data on a CNAME record must always be another DNS name - that's the whole point of a CNAME.

As put succinctly by RFC 1034, the data in a CNAME should be:

            CNAME           a domain name.

While, if you're looking to point to an IP address, then your ticket is:

            A               For the IN class, a 32 bit IP address

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:

somesubdomain.somedomain.com.   60  IN  CNAME

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 the CNAME 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 domain 0.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:

example IN CNAME

where 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.

  • 1
    While that's valid data for a CNAME, I'm fairly sure that's not going to provoke an additional lookup.. except against the root servers, for a non-existent TLD named 4? – Shane Madden Apr 9 '12 at 21:57
  • An additional lookup will be performed with an ANY (e.g. host -a) query. – adamo Apr 10 '12 at 7:38
  • @ShaneMadden BTW, your comment reminded me of DJB's local TLDs – adamo Apr 10 '12 at 14:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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