I really do think it could be. Try this for yourself.
Open a DOS window (type cmd into the run command or command for 98 users) and
then type in
tracert www.minitokyo.net
It will trace the route to the dns of the website.
Now if you ping the last IP address it picks up you will see its a DNS server.
When ever I ping that server I loose packets all the time. Here are my
results
Tracing route to minitokyo.net [65.125.227.138]
over a maximum of 30 hops:
1 1 ms <1 ms <1 ms linksys.linksys [192.168.1.198]
2 6 ms 10 ms 5 ms 10.30.64.1
3 14 ms 8 ms 6 ms dstswr2-vl2.rh.cormny.cv.net [167.206.36.34]
4 9 ms 7 ms 7 ms r2-ge0-1-1.mhe.hcvlny.cv.net [167.206.36.5]
5 9 ms 8 ms 12 ms r1-srp9-0.wan.hcvlny.cv.net [65.19.104.209]
6 14 ms 10 ms 9 ms r2-srp5-0.in.nycmnyzr.cv.net [65.19.96.56]
7 * * * Request timed out.
8 9 ms 9 ms 9 ms ezzi.customer.tlw.nac.net [207.99.110.174]
9 11 ms 12 ms 13 ms LI-6509-GE-2-2.ezzi.net [65.125.239.146]
10 17 ms 13 ms 12 ms rvdns.genxnetworks.biz [65.125.227.138]
Ping statistics for 65.125.227.138:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
Approximate round trip times in milli-seconds:
Minimum = 13ms, Maximum = 13ms, Average = 13ms
Maybe you guys should register with someone else? Who is your current DNS
server?
EDIT: Off to work for the day, I wont be back till late.
If you ever try pinging a government site, or many sites in general, You will
get close to 100% packet loss, because the server is secure enough. I don't
think it is a bad DNS server. Also it has been stated that this site is being
run on a 10MB server, versus a common 100mb server. So that will probably be the
reason of the slowness.
DNS doesn't have ANY effect on speed. All DNS does is give an address to the
name. minitokyo.net gets requested from the DNS server, it returns an IP and
never talks to the DNS again. Your traceroute returns that genxnetworks address
because ezzi.net has set up their DNS servers wrong. The ping actually gets to
minitokyo.net, but when it asks the DNS server what the hostname for that
address is, we get rvdns.genxnetworks.biz ie. reverse DNS for genxnetworks ie.
"We don't know how to run a network to save our asses."
DNS stands for Domain Name Service. When you request google.com, your DNS client
talks to your DNS server and basically asks it, "which address should I
contact to talk to google.com?" After that, DNS isn't used at all.
Furthermore, you're wasting your time trying to investigate the speed problems.
I know what the problem is exactly, it's
just going to take time and probably some money to fix.
**Edit**
We are not pushing 10mbit/sec. This means that even IF WE WERE ON 10MBIT, it
would not be slow! Of course, we're on a 100mbit network drop. This is the last
time I'm going to tell someone that we're not on a 10mbit server.
I really do think it could be. Try this for yourself.
Open a DOS window (type cmd into the run command or command for 98 users) and then type in
tracert www.minitokyo.net
It will trace the route to the dns of the website.
Now if you ping the last IP address it picks up you will see its a DNS server. When ever I ping that server I loose packets all the time. Here are my results
Microsoft Windows XP [Version 5.1.2600]
tracert www.minitokyo.net
Tracing route to minitokyo.net [65.125.227.138]
over a maximum of 30 hops:
1 1 ms <1 ms <1 ms linksys.linksys [192.168.1.198]
2 6 ms 10 ms 5 ms 10.30.64.1
3 14 ms 8 ms 6 ms dstswr2-vl2.rh.cormny.cv.net [167.206.36.34]
4 9 ms 7 ms 7 ms r2-ge0-1-1.mhe.hcvlny.cv.net [167.206.36.5]
5 9 ms 8 ms 12 ms r1-srp9-0.wan.hcvlny.cv.net [65.19.104.209]
6 14 ms 10 ms 9 ms r2-srp5-0.in.nycmnyzr.cv.net [65.19.96.56]
7 * * * Request timed out.
8 9 ms 9 ms 9 ms ezzi.customer.tlw.nac.net [207.99.110.174]
9 11 ms 12 ms 13 ms LI-6509-GE-2-2.ezzi.net [65.125.239.146]
10 17 ms 13 ms 12 ms rvdns.genxnetworks.biz [65.125.227.138]
Trace complete.
C:ping 65.125.227.138
Pinging 65.125.227.138 with 32 bytes of data:
Request timed out.
Request timed out.
Reply from 65.125.227.138: bytes=32 time=13ms TTL=55
Request timed out.
Ping statistics for 65.125.227.138:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
Approximate round trip times in milli-seconds:
Minimum = 13ms, Maximum = 13ms, Average = 13ms
Maybe you guys should register with someone else? Who is your current DNS server?
EDIT: Off to work for the day, I wont be back till late.
If you ever try pinging a government site, or many sites in general, You will get close to 100% packet loss, because the server is secure enough. I don't think it is a bad DNS server. Also it has been stated that this site is being run on a 10MB server, versus a common 100mb server. So that will probably be the reason of the slowness.
Internet networking is not my stong point - what exactly does a DNS do?
LMAO - look what happens to the X P... must be a sign.
No, no, no, no!
DNS doesn't have ANY effect on speed. All DNS does is give an address to the name. minitokyo.net gets requested from the DNS server, it returns an IP and never talks to the DNS again. Your traceroute returns that genxnetworks address because ezzi.net has set up their DNS servers wrong. The ping actually gets to minitokyo.net, but when it asks the DNS server what the hostname for that address is, we get rvdns.genxnetworks.biz ie. reverse DNS for genxnetworks ie. "We don't know how to run a network to save our asses."
DNS stands for Domain Name Service. When you request google.com, your DNS client talks to your DNS server and basically asks it, "which address should I contact to talk to google.com?" After that, DNS isn't used at all.
Furthermore, you're wasting your time trying to investigate the speed problems. I know what the problem is exactly, it's just going to take time and probably some money to fix.
**Edit**
We are not pushing 10mbit/sec. This means that even IF WE WERE ON 10MBIT, it would not be slow! Of course, we're on a 100mbit network drop. This is the last time I'm going to tell someone that we're not on a 10mbit server.
U meant "dns does *not* have ANY effect on speed." I think. hehe but i agree pretty much with what you said other than that basically.
Hah. Oops!