 |  |
Re: weird dns error resolving "www"
From: Len Conrad
Date: Monday, September 24, 2001
Time: 3:33:20 am
>>But that's not what was happening...I was seeing an immediate "server could
>>not be found" error when trying to hit the site using "www" through a dialup
>>connection (but "gas2001.com" resolved immediately")...
ah, cool data, because I find a similar discrepancy, querying from my Paris
NS (Paris to East Coast USA adds about 75 ms delay):
mgw1# dig gas2001.com
; <<>> DiG 8.3 <<>> gas2001.com
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUERY SECTION:
;; gas2001.com, type = A, class = IN
;; ANSWER SECTION:
gas2001.com. 1D IN A 206.20.122.72
;; AUTHORITY SECTION:
gas2001.com. 1D IN NS ns.idt.net.
gas2001.com. 1D IN NS ns1.ardentmicro.com.
gas2001.com. 1D IN NS ns2.ardentmicro.com.
;; ADDITIONAL SECTION:
ns.idt.net. 1d6h54m20s IN A 198.4.75.100
ns1.ardentmicro.com. 1D IN A 206.20.122.11
ns2.ardentmicro.com. 1D IN A 206.20.122.12
;; Total query time: 284 msec
;; FROM: mgw1.meiway.com to SERVER: default -- 212.73.210.69
;; WHEN: Mon Sep 24 12:13:00 2001
;; MSG SIZE sent: 29 rcvd: 165
on the above, note the "Total query time: 284 msec". This means the data
did not come from the cache of 212.73.210.69, but from an authoritative NS,
see the 'aa' in the flags, meaning "authoritative answer". An answer from
the cache of 212.73.210.69 would not have 'aa' flag.
also note the
ns.idt.net. 1d6h54m20s IN A 198.4.75.100
the "odd" TTL means that it coming from the cache of 212.73.210.69, but how
could that be if the original TTL is 1d?
now for the www:
mgw1# dig www.gas2001.com
; <<>> DiG 8.3 <<>> www.gas2001.com
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 3
;; QUERY SECTION:
;; www.gas2001.com, type = A, class = IN
;; ANSWER SECTION:
www.gas2001.com. 1D IN CNAME gas2001.com.
gas2001.com. 1D IN A 206.20.122.72
;; AUTHORITY SECTION:
gas2001.com. 1D IN NS ns.idt.net.
gas2001.com. 1D IN NS ns1.ardentmicro.com.
gas2001.com. 1D IN NS ns2.ardentmicro.com.
;; ADDITIONAL SECTION:
ns.idt.net. 1d6h54m7s IN A 198.4.75.100
ns1.ardentmicro.com. 1D IN A 206.20.122.11
ns2.ardentmicro.com. 1D IN A 206.20.122.12
;; Total query time: 3774 msec
;; FROM: mgw1.meiway.com to SERVER: default -- 212.73.210.69
;; WHEN: Mon Sep 24 12:13:13 2001
;; MSG SIZE sent: 33 rcvd: 183
and above note the "Total query time: 3774 msec" and the 'aa' flag. That's
a huge discrepancy in answer time, and 4 secs could cause some resolvers to
time out, giving you a "not found", which was my preceding suspicion.
Note that when I ran the above queries again, the response time was just 9
msec, coming from the cache of 212.73.210.69.
> I'm not associating the "www" with a CNAME because I'm trying to show off
>>how clever I am...
Using CNAME's gratuitously is a sign of counter-cleverness. :))) As Chris
said, you usage here is not the problem.
>> I'm doing it because that's what I've told is the correct
>>structure for the zone. If you're assuring me now that it's better to have
>>multiple A records pointing to the same IP, then I'll do that instead.
I always go with the simplest possible solution (I'm too dumb to manage
when it gets complicated) so for me CNAME's are verboten. There are a
couple of very good reasons for using CNAME's but if you don't know the
reasons, my advice is don't use them.
In your case, there's no NEED for a CNAME, and "what I've told" is not a
good enough reason for me. BUT, it is not your problem today. Your zone
syntax is correct.
>>I don't think that's the problem...I see a straight-through < 40ms response
>>time down to the server when trace routing...and it shouldn't make a
>>difference that one query is for "gas2001.com" or www.gas2001.com. I'm
>>certainly no expert on DNS, but it looks more like something along the way,
>>either a router or DNS, is either caching a defunct route and not finding a
>>DNS there or the domain record is corrupted somewhere.
"something" is needed to explain the huge discrepancy in the www response
above.
Len
_____________________________________________________________________
Men & Mice: QuickDNS - DNS Expert - DNS Training - DNS Consulting
DNS Classes: Newark Sep 27-28, Toronto Oct 18-19, Frankfurt Nov 21-23,
London Nov. 26-28, Maidenhead Oct 31-Nov 2
http://MenAndMice.com/DNS-training
Messages In This Thread:
Return to Digital Point Solutions' Home Page