3

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

2
  • The authoritative nameservers for the CNAMEs find.aspenfasteners.com and search.aspenfasteners.com, the CNAME for www.picosearch.com and the final A record are correctly set up. The problem likely lies on your end. More info is required to give you an exact diagnosis. The best troubleshooting step would be to take a packet capture on your DNS server when these failures occur. A packet capture will show the relevant recursive query from the client, any resulting iterative query/queries from the server, and the responses to those iterative queries. Or maybe something surprising.
    – Binky
    Dec 6, 2018 at 3:32
  • Alternatively, using dig rather than nslookup would show better info. The command: dig @mtl-srm-dbsv-01.fastenerwholesale.com find.aspenfasteners.com will display either the two CNAME records and the final A record, or show which of those three records could not be obtained. Instructions for installing under Windows 10 (also has link to Win7 instructions): nil.uniza.sk/en/how-install-dig-dns-tool-windows-10
    – Binky
    Dec 6, 2018 at 5:22

1 Answer 1

2

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.

4
  • 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, 2010 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. Apr 23, 2010 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, 2010 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. Apr 25, 2010 at 18:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .