hi,
can you resolve ftp.cisco.com?
[root@localhost /]# ping ftp.cisco.com
ping: unknown host ftp.cisco.com
[root@localhost /]#
something is wrong here....
ezequiel.
hi,
can you resolve ftp.cisco.com?
[root@localhost /]# ping ftp.cisco.com
ping: unknown host ftp.cisco.com
[root@localhost /]#
something is wrong here....
ezequiel.
Probably something to do with the DDoS they said they were under
yesterday.
Non-authoritative answer:
Name: ftp.cisco.com
Address: 64.102.255.95
works here
Mehmet Akcin
Works from here:
[root@flows james]# tcptraceroute ftp.cisco.com 21
Selected device eth0, address 65.19.4.24 for outgoing packets
Tracing the path to ftp.cisco.com (198.133.219.27) on TCP port 21, 30 hops max
1 alb-router.cybermesa.com (65.19.1.2) 19.750 ms 0.234 ms 0.261 ms
2 albuqu-nm-1-a12-0.200.espire.net (206.222.101.109) 4.685 ms 2.486 ms 2.082 ms
3 206.222.118.53 (206.222.118.53) 14.189 ms 14.065 ms 14.016 ms
4 fortwo2-a3-0-0-2.rt.espire.net (206.222.126.98) 37.954 ms 35.875 ms 36.636 ms
5 sl-gw34-fw-7-0-TS2.sprintlink.net (144.228.203.29) 29.088 ms 30.156 ms 34.366 ms
6 sl-bb22-fw-4-1.sprintlink.net (144.232.11.2) 29.425 ms 31.951 ms 40.768 ms
7 sl-bb23-fw-15-0.sprintlink.net (144.232.11.242) 31.604 ms 31.317 ms 29.907 ms
8 sl-bb23-ana-11-2.sprintlink.net (144.232.8.77) 62.536 ms 62.273 ms 61.263 ms
9 sl-bb25-sj-9-0.sprintlink.net (144.232.20.159) 65.811 ms 65.540 ms 67.372 ms
10 sl-gw11-sj-10-0.sprintlink.net (144.232.3.134) 65.734 ms 66.418 ms 68.074 ms
11 sl-ciscopsn2-11-0-0.sprintlink.net (144.228.44.14) 65.613 ms 67.989 ms 70.221 ms
12 sjck-dirty-gw1.cisco.com (128.107.239.5) 76.115 ms 70.891 ms 69.920 ms
13 sjck-sdf-ciod-gw1.cisco.com (128.107.239.106) 78.434 ms 76.702 ms 79.843 ms
14 ftp-sj.cisco.com (198.133.219.27) [open] 64.979 ms 66.218 ms 67.454 ms
[root@flows james]#
Ezequiel Carson wrote:
hi,
can you resolve ftp.cisco.com?
[root@localhost /]# ping ftp.cisco.com
ping: unknown host ftp.cisco.com
[root@localhost /]#something is wrong here....
Their DNS is a little strange and slow, but it resolves for me,
[521:~] host -t ns cisco.com g.gtld-servers.net
Using domain server:
Name: g.gtld-servers.net
Addresses: 192.42.93.30
cisco.com name server ns1.cisco.com
cisco.com name server ns2.cisco.com
[522:~] host -t ns ftp.cisco.com ns1.cisco.com
Using domain server:
Name: ns1.cisco.com
Addresses: 128.107.241.185
ftp.cisco.com name server rtp5-dirty-ddir.cisco.com
ftp.cisco.com name server sjce-dirty-ddir.cisco.com
[523:~] dig @rtp5-dirty-ddir.cisco.com ftp.cisco.com
; <<>> DiG 8.3 <<>> @rtp5-dirty-ddir.cisco.com ftp.cisco.com
; (1 server found)
;; 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: 0, ADDITIONAL: 0
;; QUERY SECTION:
;; ftp.cisco.com, type = A, class = IN
;; ANSWER SECTION:
ftp.cisco.com. 1M IN A 198.133.219.27
;; Total query time: 4428 msec
;; FROM: sec-tools.corp.globalstar.com to SERVER: rtp5-dirty-ddir.cisco.com 64.102.255.39
;; WHEN: Tue Oct 7 10:47:06 2003
;; MSG SIZE sent: 31 rcvd: 47
Look at the query time. The other NS for ftp.cisco.com has a similar
time for me. I didn't show it here, but the NS records for ftp.cisco.com
have a 10s TTL too. And look at the name of the servers. Odd. Not exactly
sure what's going on down the street with them.
I can both resolve and reach it from opposite ends of the planet ...
Trace ftp.cisco.com (198.133.219.27) ...
1 192.168.34.2 1ms FastEth8-1-0.sb1.optus.net.au
2 61.88.178.8 1ms gi3-0.ig6.optus.net.au
3 203.208.148.101 232ms
4 203.208.172.45 220ms p6-1.plapx-cr1.ix.singtel.com
5 203.208.168.225 231ms
6 203.208.168.218 231ms
7 63.169.235.133 164ms leg-63-169-235-133-CHI.sprinthome.com
8 144.232.20.125 213ms sl-bb20-ana-4-3.sprintlink.net
9 144.232.1.134 165ms sl-bb23-ana-9-0.sprintlink.net
10 144.232.20.159 166ms sl-bb25-sj-9-0.sprintlink.net
11 144.232.3.134 166ms sl-gw11-sj-10-0.sprintlink.net
12 144.228.44.14 167ms sl-ciscopsn2-11-0-0.sprintlink.net
13 128.107.239.89 175ms sjce-dirty-gw1.cisco.com
14 128.107.239.102 175ms sjck-sdf-ciod-gw2.cisco.com
15 198.133.219.27 175ms ftp-sj.cisco.com
Trace ftp.cisco.com (64.102.255.95) ...
1 217.146.111.97 0ms gateway.mandarin.com
2 213.123.101.89 20ms
3 217.146.102.237 20ms
4 213.200.77.93 50ms
5 213.200.81.74 30ms
6 213.206.159.5 40ms sl-gw10-lon-5-1.sprintlink.net
7 213.206.128.45 30ms sl-bb21-lon-8-0.sprintlink.net
8 144.232.19.69 150ms sl-bb21-tuk-10-0.sprintlink.net
9 144.232.20.132 90ms sl-bb20-tuk-15-0.sprintlink.net
10 144.232.20.122 120ms sl-bb21-rly-14-3.sprintlink.net
11 144.232.14.134 160ms sl-bb23-rly-11-0.sprintlink.net
12 144.232.14.46 130ms sl-gw20-rly-10-0.sprintlink.net
13 144.232.244.210 130ms sl-ciscopsn2-12-0.sprintlink.net
14 64.102.254.194 100ms rtp7-dirty-gw1.cisco.com
15 64.102.254.205 120ms rtp5-ciod-gw2.cisco.com
16 64.102.255.95 110ms ftp-rtp.cisco.com
They've had this broken for weeks now.
You'll also see (depending on nameserver)
this in your logs:
Oct 7 14:10:36 unix named[3502]: lame server resolving 'ftp.cisco.com' (in 'ftp.cisco.com'?): 64.102.255.39#53
Oct 7 14:10:36 unix named[3502]: lame server resolving 'ftp.cisco.com' (in 'ftp.cisco.com'?): 128.107.240.86#53
Oct 7 14:10:38 unix named[3502]: lame server resolving 'ftp.cisco.com' (in 'ftp.cisco.com'?): 64.102.255.39#53
Oct 7 14:10:38 unix named[3502]: lame server resolving 'ftp.cisco.com' (in 'ftp.cisco.com'?): 128.107.240.86#53
Depends on resolver libs, etc..
I've reported it to them in the past and their IT
folks can't seem to get it fixed
- Jared
Crist Clark [07/10/03 10:51 -0700]:
ftp.cisco.com name server rtp5-dirty-ddir.cisco.com
ftp.cisco.com name server sjce-dirty-ddir.cisco.comLook at the query time. The other NS for ftp.cisco.com has a similar
time for me. I didn't show it here, but the NS records for ftp.cisco.com
have a 10s TTL too. And look at the name of the servers. Odd. Not exactly
sure what's going on down the street with them.
Load balanced nameservers. I assume these are all being DDoS'd as well, so
that the actual nameservers behind the hardware (cisco?) load balancer are
overloaded.
Jared Mauch wrote:
They've had this broken for weeks now.
You'll also see (depending on nameserver)
this in your logs:
Oct 7 14:10:36 unix named[3502]: lame server resolving 'ftp.cisco.com' (in 'ftp.cisco.com'?): 64.102.255.39#53
Oct 7 14:10:36 unix named[3502]: lame server resolving 'ftp.cisco.com' (in 'ftp.cisco.com'?): 128.107.240.86#53
Oct 7 14:10:38 unix named[3502]: lame server resolving 'ftp.cisco.com' (in 'ftp.cisco.com'?): 64.102.255.39#53
Oct 7 14:10:38 unix named[3502]: lame server resolving 'ftp.cisco.com' (in 'ftp.cisco.com'?): 128.107.240.86#53Depends on resolver libs, etc..
I've reported it to them in the past and their IT
folks can't seem to get it fixed
Weird. I have,
Oct 7 10:42:44 ns1 named[164]: [ID 866145 daemon.info] lame server resolving 'ftp.cisco.com' (in 'ftp.cisco.com'?): 64.102.255.39#53
Oct 7 10:42:44 ns1 named[164]: [ID 866145 daemon.info] lame server resolving 'ftp.cisco.com' (in 'ftp.cisco.com'?): 128.107.240.86#53
Oct 7 10:42:46 ns1 named[164]: [ID 866145 daemon.info] lame server resolving 'ftp.cisco.com' (in 'ftp.cisco.com'?): 64.102.255.39#53
In BIND logs too, but if I do the check now, they both seem to be returning
authoritive records. But also note,
$ host sjce-dirty-ddir.cisco.com
sjce-dirty-ddir.cisco.com has address 128.107.240.86
sjce-dirty-ddir.cisco.com has address 172.17.153.22
Uhhh... Hello? 172.17.153.22? 172.16.0.0/12, RFC1918?
What _is_ going on down on Tasman?
==>Jared Mauch wrote:
==>>
==>> I've reported it to them in the past and their IT
==>> folks can't seem to get it fixed
==>
==>In BIND logs too, but if I do the check now, they both seem to be returning
==>authoritive records. But also note,
==>
==> $ host sjce-dirty-ddir.cisco.com
==> sjce-dirty-ddir.cisco.com has address 128.107.240.86
==> sjce-dirty-ddir.cisco.com has address 172.17.153.22
==>
==>Uhhh... Hello? 172.17.153.22? 172.16.0.0/12, RFC1918?
We fixed most of this problem when Jared reported it, but it appears
all hasn't been changed. Some configuration entries were missed in
the distributed directors.
ns1.cisco.com/ns2.cisco.com have the correct nameservers but the
distributed director has the old values. I've forwarded the info
and it will be fixed accordingly.
/cah