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

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 example.com will work, but going to www.example.com 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 blanchardscoffee.com

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 - blanchardscoffee.com –  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

3 Answers 3

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 www.blanchardscoffee.com A blanchardscoffee.com A
www.blanchardscoffee.com. 3582  IN      CNAME   blanchardscoffee.com.
blanchardscoffee.com.   3574    IN      A       173.201.180.189
blanchardscoffee.com.   3574    IN      NS      ns77.domaincontrol.com.
blanchardscoffee.com.   3574    IN      NS      ns78.domaincontrol.com.
;; Received 124 bytes from 192.168.178.1#53(192.168.178.1) in 38 ms

blanchardscoffee.com.   3574    IN      A       173.201.180.189
blanchardscoffee.com.   3574    IN      NS      ns77.domaincontrol.com.
blanchardscoffee.com.   3574    IN      NS      ns78.domaincontrol.com.
;; Received 106 bytes from 192.168.178.1#53(192.168.178.1) 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 domaincontrol.com 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, DNSStuff.com is reporting that no A or CNAME records exist for www.blanchardscoffee.com. My suggestion would be to specifically create an A record for www or create a CNAME for www aliased to blanchardscoffee.com.

EDIT

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 blanchardscoffee.com and www.blanchardscoffee.com, with the dig for the latter clearly showing a CNAME pointing to the A record for the former:

$ dig www.blanchardscoffee.com

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

;; QUESTION SECTION:
;www.blanchardscoffee.com.      IN      A

;; ANSWER SECTION:
www.blanchardscoffee.com. 3600  IN      CNAME   blanchardscoffee.com.
blanchardscoffee.com.   3600    IN      A       173.201.180.189

;; AUTHORITY SECTION:
blanchardscoffee.com.   3600    IN      NS      ns77.domaincontrol.com.
blanchardscoffee.com.   3600    IN      NS      ns78.domaincontrol.com.

;; Query time: 92 msec
;; SERVER: 10.171.3.56#53(10.171.3.56)
;; 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

 
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.