Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

i've recently changed the few sites I manage to reside on one vps, instead of multiple hosting accounts. All of them successfully transferred except one, which is giving me issues, and I'm unsure why.

Currently, going to will work, but going to will not, even though there's a CNAME entry in the zone file for www : @

I have other sites set up the same way and they are not having any issues whatsoever.

The site in question was transferred over from a different registrar. Is this just a propogation issue?

By request: domain name is

share|improve this question
DNS doesn't propagate, so this may be a caching issue. Can you give us the actual domain name so we can help you figure out what's wrong? – joeqwerty Jun 14 '11 at 17:01
Added - – Tom Thorogood Jun 14 '11 at 17:03
@Tom: Thanks much. – joeqwerty Jun 14 '11 at 17:04
Can you give us the lines from your zone file? I'm just get NXDomain when I query www so maybe there is a typo of some sort? – Chris Jun 14 '11 at 17:09
Unfortunately I don't have access to the full file for the verbatim entry - it's GoDaddy's easy-edit thing. [/eyeroll] – Tom Thorogood Jun 14 '11 at 17:12
up vote 1 down vote accepted

There's a thing called negative cache. I guess it hit you...

To quote the wikipedia article:

Some resolvers may override TTL values, as the protocol supports caching for up to 68 years or no caching at all. Negative caching, i.e. the caching of the fact of non-existence of a record, is determined by name servers authoritative for a zone which must include the Start of Authority (SOA) record when reporting no data of the requested type exists. The value of the MINIMUM field of the SOA record and the TTL of the SOA itself is used to establish the TTL for the negative answer.

This is what it looks like here:

$ dig A A 3582  IN      CNAME   3574    IN      A   3574    IN      NS   3574    IN      NS
;; Received 124 bytes from in 38 ms   3574    IN      A   3574    IN      NS   3574    IN      NS
;; Received 106 bytes from in 2 ms
share|improve this answer
Thanks for this. Also curious, though: when I try the same dig command, i get different results for the www. entry. So is this just something I have to wait to correct iself, then, I guess? – Tom Thorogood Jun 14 '11 at 17:32
The results will be different for the TTL column (second). All others hould be the same -- usually. Could be that the presents differents NS answers to diffrent clients. But if the NS servers aren't under your control there's nothing you can do, except open a support ticket and ask why that is the case... – Server Horror Jun 14 '11 at 17:36
Will do. Thanks again! – Tom Thorogood Jun 14 '11 at 17:40

OK, is reporting that no A or CNAME records exist for My suggestion would be to specifically create an A record for www or create a CNAME for www aliased to


I missed the part where you already had a CNAME. Disregard my answer.

share|improve this answer
No problem at all. – Tom Thorogood Jun 14 '11 at 17:35

I think this is/was a caching issue of intermediate name servers. I currently get proper resolution on both and, with the dig for the latter clearly showing a CNAME pointing to the A record for the former:

$ dig

; <<>> DiG 9.7.3 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13875
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0

;      IN      A

;; ANSWER SECTION: 3600  IN      CNAME   3600    IN      A

;; AUTHORITY SECTION:   3600    IN      NS   3600    IN      NS

;; Query time: 92 msec
;; WHEN: Tue Jun 14 18:19:54 2011
;; MSG SIZE  rcvd: 124

unless, of course, this is your old DNS configuration. But you should be able to verify this.

share|improve this answer
That's good to see, and I didn't know about the dig tool! Great info to have. – Tom Thorogood Jun 14 '11 at 17:24
You might want to get it. That's your DNS swiss army knife. – wolfgangsz Jun 14 '11 at 17:25
I had it installed already. I got different output when I tried this, however. What you have is right; ns77 and ns78 are correct nameservers. – Tom Thorogood Jun 14 '11 at 17:28
As I said, a caching issue. Give it some time, and it will come right. – wolfgangsz Jun 14 '11 at 17:53

Your Answer


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.