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
|