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.

Our domain "aspenfasteners.com" is hosted by Volusion. We have CNAME records "find" and "search" which point to site indexing accounts on www.picosearch.com.

These addresses fail on SOME private office networks which have their own DNS. We suspect the problem comes from Volusion's own name servers, n2.volusion.com and n3.volusion.com.

Volusion support on problems this technical is non-existant.

We have tried an NSLOOKUP on find.aspenfasteners.com with level 2 debugging info, and we got the results below. Is it possible that the local DNS is recursing to Volusion's name servers, and that while Volusion DOES return the canonical name, they do NOT resolve the address?

Can anybody with expertise in this sort of stuff PLEASE look at the NSLOOKUP below and tell me if we are right, because Volusion is giving me absolutely NO support on this topic. I need proof of where the problem lies.

Thanks VERY much!

Carlo

find.aspenfasteners.com Server: mtl-srm-dbsv-01.fastenerwholesale.com Address: 192.168.0.44


SendRequest(), len 61 HEADER: opcode = QUERY, id = 8, rcode = NOERROR header flags: query, want recursion questions = 1, answers = 0, authority records = 0, additional = 0

QUESTIONS:
    find.aspenfasteners.com.fastenerwholesale.com, type = A, class = IN

------------

Got answer (138 bytes): HEADER: opcode = QUERY, id = 8, rcode = NXDOMAIN header flags: response, auth. answer, want recursion, recursion avail. questions = 1, answers = 0, authority records = 1, additional = 0

QUESTIONS:
    find.aspenfasteners.com.fastenerwholesale.com, type = A, class = IN
AUTHORITY RECORDS:
->  fastenerwholesale.com
    type = SOA, class = IN, dlen = 46
    ttl = 3600 (1 hour)
    primary name server = mtl-srm-dbsv-01.fastenerwholesale.com
    responsible mail addr = admin.fastenerwholesale.com
    serial  = 10219
    refresh = 900 (15 mins)
    retry   = 600 (10 mins)
    expire  = 86400 (1 day)
    default TTL = 3600 (1 hour)

------------

SendRequest(), len 41 HEADER: opcode = QUERY, id = 9, rcode = NOERROR header flags: query, want recursion questions = 1, answers = 0, authority records = 0, additional = 0

QUESTIONS:
    find.aspenfasteners.com, type = A, class = IN

------------

Got answer (141 bytes): HEADER: opcode = QUERY, id = 9, rcode = NXDOMAIN header flags: response, auth. answer questions = 1, answers = 1, authority records = 1, additional = 1

QUESTIONS:
    find.aspenfasteners.com, type = A, class = IN
ANSWERS:
->  find.aspenfasteners.com
    type = CNAME, class = IN, dlen = 17
    canonical name = www.picosearch.com
    ttl = 3600 (1 hour)
AUTHORITY RECORDS:
->  com
    type = SOA, class = IN, dlen = 43
    ttl = 900 (15 mins)
    primary name server = ns3.volusion.com
    responsible mail addr = admin.volusion.com
    serial  = 1
    refresh = 900 (15 mins)
    retry   = 600 (10 mins)
    expire  = 86400 (1 day)
    default TTL = 3600 (1 hour)
ADDITIONAL RECORDS:
->  ns3.volusion.com
    type = A, class = IN, dlen = 4
    internet address = 65.61.137.154
    ttl = 900 (15 mins)

* mtl-srm-dbsv-01.fastenerwholesale.com can't find find.aspenfasteners.com: Non-existent domain

share|improve this question
add comment

1 Answer

Looking at your log, it doesn't seem to be a problem with the Volusion nameservers, it's more likely to be a problems with the caching resolvers used by the misbehaving private office networks.

The first resolution intent is by appending what I suppose is their own domain name, so when you look up find.aspenfasteners.com the resolvers first asks for find.aspenfasteners.com.fastenerwholesale.com. Then the resolver asks for the actual domain without appending anything. It asks for the IP associated with the domain by specifying the resource record type A. The Volusion name server correctly sets the return code to NXDOMAIN (=non-existing domain), because it has no A record for the domain you asked for. However, it does return the CNAME resource record in the aswer section, so it is now the job of the resolver to look up the hostname specified in the CNAME resource record.

I would look for problems on the resolver side.

share|improve this answer
    
Thanks for the very concise answer, prof! This problem shows on two networks where both have client IP configs that append DNS suffixes; I believe this is standard practice on local networks, If this IS standard practise, there are other networks with this problem where I can't fix them. What can I do? BTW - the problem has gone on both networks. I flushed the cache on one, but not the other as I have no admin control there. Was this fixed because two different local DNS's were miraculously flushed at the same time, or was it something Volusion's DNS had done? –  crashalpha Apr 23 '10 at 18:24
    
This is difficult to answer, there not enough data... I'm not sure Volusion did anything, because the trace you provided had a correct answer from them. I would hazard on guessing that the resolvers in question had problems solving www.picosearch.com at the time of the query, or had something incorrect about that domain in their cache. –  Prof. Moriarty Apr 23 '10 at 19:07
    
This is the second time this happened: the same unrelated networks with private DNS could not resolve the CNAME, but a public DNS like Google could. The first time we thought it was a propogation problem. The only thing these netwoirks have in common is they use Windows servers, and at least one is a Windows DNS, so the 2nd is likely to be too. My concern is the 2 networks are tripping over a common problem, and others will too - while flushing our cache worked for us, other DNS of course won't. NSLOOKUP was the best tool I knew of to figure out why this happened and it supplied no clue. –  crashalpha Apr 25 '10 at 15:00
    
Maybe you could give the 'dig' tool a try, on a linux machine. With the '+trace' modifier you can see how that domain would be resolved on the network, if it was a Linux resolver. –  Prof. Moriarty Apr 25 '10 at 18:12
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.