[prev in list] [next in list] [prev in thread] [next in thread] 

List:       djbdns
Subject:    Re: problem w/ www.macys.com and www.jcrew.com..
From:       Rob <djbstuff () itsbeen ! sent ! com>
Date:       2006-11-15 0:19:31
Message-ID: 455A5D13.1020708 () itsbeen ! sent ! com
[Download RAW message or body]

B. Cook wrote:
> Hello all,
> 
> I'm having users complain that they can't open certain web pages.. and 
> after checking into things.. it seems the authoritative are doing 
> something w/ dns that dnscache doesn't like or understand.
> 
> host www.macys.com
> ;; connection timed out; no servers could be reached
> 
> (I set up a maradns server on the loopback using the icann roots; same 
> as dnscache)
> 
> host www.macys.com 127.0.0.1
> Using domain server:
> Name: 127.0.0.1
> Address: 127.0.0.1#53
> Aliases:
> 
> www.macys.com is an alias for www.macys.com.edgekey.net.
> www.macys.com.edgekey.net has address 72.246.68.134
> Using domain server:
> Name: 127.0.0.1
> Address: 127.0.0.1#53
> Aliases:
> 
> www.macys.com is an alias for www.macys.com.edgekey.net.
> Using domain server:
> Name: 127.0.0.1
> Address: 127.0.0.1#53
> Aliases:
> 
> www.macys.com is an alias for www.macys.com.edgekey.net.
> 
> host www.jcrew.com
> ;; connection timed out; no servers could be reached
> 
> 
> host www.jcrew.com 127.0.0.1
> Using domain server:
> Name: 127.0.0.1
> Address: 127.0.0.1#53
> Aliases:
> 
> www.jcrew.com is an alias for www.jcrew.com.edgesuite.net.
> www.jcrew.com.edgesuite.net has address 64.72.65.215
> Using domain server:
> Name: 127.0.0.1
> Address: 127.0.0.1#53
> Aliases:
> 
> www.jcrew.com is an alias for www.jcrew.com.edgesuite.net.
> Using domain server:
> Name: 127.0.0.1
> Address: 127.0.0.1#53
> Aliases:
> 
> www.jcrew.com is an alias for www.jcrew.com.edgesuite.net.
> 
> 
> host macys.com
> macys.com has address 63.73.131.68
> macys.com mail is handled by 10 mail4.mayco.com.
> macys.com mail is handled by 5 fdsmail01.fds.com.
> macys.com mail is handled by 5 fdsmail02.fds.com.
> macys.com mail is handled by 5 fdsmail03.fds.com.
> 
> host jcrew.com
> jcrew.com has address 164.109.32.247
> jcrew.com mail is handled by 20 emailscan8a.mci.com.
> jcrew.com mail is handled by 10 emailscan8.mci.com.
> 
> 
> This is on a FreeBSD box with the jumbo patch installed for what it's 
> worth.  Running from Daemontools
> 
> Any help is appreciated.

Hi,

Despite the previously mentioned issues with djb/Akamai and the exceptional dns \
server mess for these domains, I found that the ibm NS servers refused the query \
directly from dig but dnscache easily resolved www.macys.com. It did take 700+ msecs \
and it expended 93 work units (loops). The only difference I found was that dnscache \
didn't set the rd bit (and dig did by default).

Is it possible that you have a FORWARDONLY file in the env directory of one of your \
caches?

A) response from my copy of dnscache:
10:26:13.713173 IP 170.224.33.5.53 > 10.20.10.90.4377:  3120*- 1/0/0 CNAME \
                www.macys.com.edgekey.net. (70)
         0x0000:  4500 0062 5ded 0000 0e11 6e4b aae0 2105  E..b].....nK..!.
         0x0010:  0a14 0a5a 0035 1119 004e d93f 0c30 8400  ...Z.5...N.?.0..
         0x0020:  0001 0001 0000 0000 0377 7777 056d 6163  .........www.mac
         0x0030:  7973 0363 6f6d 0000 0100 01c0 0c00 0500  ys.com..........
         0x0040:  0100 000e 1000 1b03 7777 7705 6d61 6379  ........www.macy
         0x0050:  7303 636f 6d07 6564 6765 6b65 7903 6e65  s.com.edgekey.ne
         0x0060:  7400                                     t.

B) response from dig directly to the same IBM dns server (ns2.raleigh.usf.ibm.com.):
10:27:54.055365 IP 170.224.33.5.53 > 10.20.10.90.33874:  3205 Refused- 0/0/0 (31)
         0x0000:  4500 003b 827d 0000 0e11 49e2 aae0 2105  E..;.}....I...!.
         0x0010:  0a14 0a5a 0035 8452 0027 3d37 0c85 8105  ...Z.5.R.'=7....
         0x0020:  0001 0000 0000 0000 0377 7777 056d 6163  .........www.mac
         0x0030:  7973 0363 6f6d 0000 0100 01              ys.com.....

Line by line query comparison:

A 10:26:13.630228 IP 10.20.10.90.4377 > 170.224.33.5.53:  3120 A? www.macys.com. (31)
B 10:27:53.974153 IP 10.20.10.90.33874 > 170.224.33.5.53:  3205+ A? www.macys.com. \
(31)  Ver  Len  ID   Flag TTL  CKSUM
                    TOS                 UDP     Src  IP
A       0x0000:  4500 003b eb66 4000 4011 6ef8 0a14 0a5a  E..;.f@.@.n....Z
B       0x0000:  4500 003b 0000 4000 4011 5a5f 0a14 0a5a  E..;..@.@.Z_...Z
                  Dest IP   SPortDPortLen  CKSUM     Param
                                                DNSID
A       0x0010:  aae0 2105 1119 0035 0027 31cb 0c30 0000  ..!....5.'1..0..
B       0x0010:  aae0 2105 8452 0035 0027 bd3c 0c85 0100  ..!..R.5.'.<....
                  Qcnt Acnt AuthsAdds Ln## #### Ln## ####
A       0x0020:  0001 0000 0000 0000 0377 7777 056d 6163  .........www.mac
B       0x0020:  0001 0000 0000 0000 0377 7777 056d 6163  .........www.mac
                  #### Ln## #### \0TYPE CLASS
A       0x0030:  7973 0363 6f6d 0000 0100 01              ys.com.....
B       0x0030:  7973 0363 6f6d 0000 0100 01              ys.com.....

I find that running the following before testing helps tracking down where problems \
are occurring: # tail -fF /etc/dnscache/log/main/current &
# tcpdump -X -s 65535 -nnvvvi eth0 port 53 &
# svc -t /service/dnscache

Perhaps the packet trace and dnscache logs can pinpoint where the breakdown is \
happening for you, if you have access to the dnscache machine.

fpdns reports: fingerprint (ns2.raleigh.usf.ibm.com., 170.224.33.5): BIND 9.2.3rc1 -- \
9.4.0a0


[prev in list] [next in list] [prev in thread] [next in thread]