dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
975

cchhat01
Dr. Zoidberg
join:2001-05-01
Elmhurst, NY

cchhat01

Member

DNS Servers

Hello,

I'm on Verizon FiOS. I've stopped using fios dns servers since day 1 because of domain hijacking. Up until now, I was using opendns because it seemed to be consistently fast in namebench and dnsbench tests.
However, recently I discovered a couple of interesting things and I wanted some clarification.

When I run a traceroute or ping, i can tell which ip ranges are in my vicinity in terms of CDNs for big ticket providers such as google, youtube, etc.
However i found that traceroute to google.com (which is about 9 hops and about 4-6ms away) is very different to www.google.com (which is about 14-15 hops away and about 40ms away in washington or elsewhere...)
I gather that when a traceroute results in a non-lga server, it is heading outside of new york.
I noted many providers screw this up. opendns, level3 and uunet. What is the problem here? Is there a preference issue ?
I'm just trying to understand peering and CDNs and their connection to dns servers (who's at fault here, the dns servers or the CDNs).
google.com is alway close by, however www.google.com is always something random and remote (aka not in new york).

here's a traceroute to google.com
root@cchhat01:~# traceroute google.com
traceroute to google.com (74.125.226.166), 30 hops max, 38 byte packets
 1  LXXX.NYCMNY-VXXXXXX.verizon-gni.net (98.x.x.x)  1.743 ms  7.008 ms  3.371 ms
 2  G0-1-2-3.NYCMNY-LCR-21.verizon-gni.net (130.81.177.88)  8.049 ms  5.386 ms  7.423 ms
 3  ae5-0.NY325-BB-RTR1.verizon-gni.net (130.81.163.208)  5.704 ms  ae5-0.NY325-BB-RTR2.verizon-gni.net (130.81.163.216)  6.597 ms  130.81.151.228 (130.81.151.228)  4.938 ms
 4  0.xe-2-0-3.XT1.NYC4.ALTER.NET (152.63.10.17)  8.572 ms  0.xe-2-0-8.XT2.NYC4.ALTER.NET (152.63.6.253)  3.916 ms  3.733 ms
 5  TenGigE0-5-1-0.GW8.NYC4.ALTER.NET (152.63.21.73)  11.468 ms  TenGigE0-6-4-0.GW8.NYC4.ALTER.NET (152.63.21.121)  11.300 ms  TenGigE0-5-1-0.GW8.NYC4.ALTER.NET (152.63.21.73)  24.463 ms
 6  google-gw.customer.alter.net (152.179.72.62)  6.062 ms  7.720 ms  6.193 ms
 7  72.14.238.232 (72.14.238.232)  4.443 ms  9.928 ms  4.813 ms
 8  209.85.245.183 (209.85.245.183)  6.449 ms  6.800 ms  6.264 ms
 9  lga15s45-in-f6.1e100.net (74.125.226.166)  5.698 ms  5.982 ms  6.494 ms
 
here's a traceroute to www.google.com
root@cchhat01:~# traceroute www.google.com
traceroute to www.google.com (74.125.227.208), 30 hops max, 38 byte packets
 1  LXXX.NYCMNY-VXXXXXX.verizon-gni.net (98.x.x.x)  3.383 ms  2.046 ms  3.130 ms
 2  G1-15-0-5.NYCMNY-LCR-21.verizon-gni.net (130.81.223.32)  7.889 ms  6.874 ms  3.992 ms
 3  ae0-0.NY325-BB-RTR2.verizon-gni.net (130.81.209.110)  10.446 ms  so-5-0-0-0.NY325-BB-RTR2.verizon-gni.net (130.81.22.16)  6.760 ms  ae5-0.NY325-BB-RTR2.verizon-gni.net (130.81.163.216)  5.394 ms
 4  0.so-0-0-0.XT1.NYC4.ALTER.NET (152.63.1.41)  5.646 ms  0.xe-2-0-8.XT2.NYC4.ALTER.NET (152.63.6.253)  81.072 ms  0.xe-2-0-3.XT1.NYC4.ALTER.NET (152.63.10.17)  5.725 ms
 5  TenGigE0-5-0-0.GW8.NYC4.ALTER.NET (152.63.21.65)  7.635 ms  7.383 ms  TenGigE0-6-1-0.GW8.NYC4.ALTER.NET (152.63.21.113)  7.046 ms
 6  google-gw.customer.alter.net (152.179.72.62)  4.945 ms  5.805 ms  7.510 ms
 7  209.85.255.68 (209.85.255.68)  34.947 ms  4.969 ms  3.099 ms
 8  72.14.236.208 (72.14.236.208)  4.895 ms  209.85.252.250 (209.85.252.250)  4.102 ms  5.722 ms
 9  72.14.239.93 (72.14.239.93)  26.068 ms  14.977 ms  13.292 ms
10  72.14.235.12 (72.14.235.12)  17.936 ms  20.102 ms  46.701 ms
11  72.14.238.88 (72.14.238.88)  28.202 ms  72.14.239.66 (72.14.239.66)  27.525 ms  72.14.238.88 (72.14.238.88)  26.461 ms
12  209.85.240.82 (209.85.240.82)  43.321 ms  42.205 ms  40.098 ms
13  72.14.237.220 (72.14.237.220)  39.889 ms  42.584 ms  39.930 ms
14  64.233.174.139 (64.233.174.139)  41.275 ms  41.899 ms  43.197 ms
15  dfw06s33-in-f16.1e100.net (74.125.227.208)  41.615 ms  41.224 ms  42.971 ms
 

thanks,
cchhat01

timcuth
Braves Fan
Premium Member
join:2000-09-18
Pelham, AL

timcuth

Premium Member

There is a tool on grc.com that will test many DNS's and tell you which ones perform the best from your connection.

»www.grc.com/dns/benchmark.htm

Tim

cchhat01
Dr. Zoidberg
join:2001-05-01
Elmhurst, NY

1 recommendation

cchhat01

Member

I'm going to quote myself here
Up until now, I was using opendns because it seemed to be consistently fast in namebench and dnsbench tests.
I've tried that already, but I want to understand why google.com and www.google.com wouldnt point to a CDN in the same region.

You're talking about OVERALL tests based on the response for a few hundred queries (cached/uncached, etc). I say screw that. In fact, DNSBench doesn't even list UUNet servers in its tests and they appear to be the best for me.

So my question still remains: WHY? why take me to dulles washington (iad server) when I type www.google.com and take me to lga (laguardia) when I type google.com (its obvious that lga is better for me).

timcuth
Braves Fan
Premium Member
join:2000-09-18
Pelham, AL
Technicolor ET2251

timcuth to cchhat01

Premium Member

to cchhat01
Sorry I missed that part.

But, a few weeks ago I also had a lot of trouble with OpenDNS, which had been working very well for me for several years. I ran DNSBench, and it identified servers that I switched to, and performance has greatly improved since I changed.

I am not an expert, so I can't help with the Why.

Tim

Kilroy
MVM
join:2002-11-21
Saint Paul, MN

Kilroy to cchhat01

MVM

to cchhat01
Probably because they are different servers. WWW.GOOGLE.COM is the World Wide Web server for Google. I don't have any idea what GOOGLE.COM is, but you can see from the IP addresses that they resolve to different IP addresses. Only Google can tell you why they aren't located in the same place.

tschmidt
MVM
join:2000-11-12
Milford, NH
·Consolidated Com..
·Republic Wireless
·Hollis Hosting

tschmidt to cchhat01

MVM

to cchhat01
I'm by no means a DNS guru but this is my understanding.

CDN's typically terminate near or within the ISP. The whole idea of CDN's is to cache content as near the customer as possible. I assume the ISP tweaks their DNS resolver to point to the CDN termination within the ISP. Generic DNS resolvers would have to guess the best route to the end user.

/tom
LittleBill
join:2013-05-24

LittleBill

Member

be careful anycast is used as well, which can screw with testing, if doing so from different parts of the world

rchandra
Stargate Universe fan
Premium Member
join:2000-11-09
14225-2105
ARRIS ONT1000GJ4
EnGenius EAP1250

rchandra to cchhat01

Premium Member

to cchhat01
google.com is at the apex of the domain, and as such, must be AAAA and A records (it cannot be "CNAMEd"). WWW on the other hand is distinct from the domain apex, and may be a CNAME instead, which could point to a different set of records. There is nothing that stipulates that the eventual resulting address(es) for the apex and the www have to be the same. In fact, it's possible the sole purpose of the servers at google.com is to serve up a 30x redirect to www.

As others have pointed out, unless you want to collaborate with several engineers, due to mechanisms such as anycasting, you cannot be sure of where any particular address exists for the time you connect with it. You also cannot make any lasting conclusions simply from names or reverse names, as routing may be updated at any time, or a different anycast server may be chosen. The best you can hope to meter is at some particular span of a few minutes (possibly less) you're getting some particular reading on your diagnostic tools such as ping or traceroute/path. I think the best you can honestly do is some trial and error, and see if there is any correlation between the recursive resolvers you use and better/worse perceived performance over long-ish spans of time (say a week). If possible, you would need to test them approximately in parallel, such as one computer resolving with OpenDNS, another with Google Public DNS, another with Dyn Internet Guide, etc.

Heck, I know it's not for everybody, but I run my own copy of BIND on my router.

Hayward0
K A R - 1 2 0 C
Premium Member
join:2000-07-13
Key West, FL

Hayward0 to cchhat01

Premium Member

to cchhat01
Every once in a while I run into a site (mostly OLD) that only work with the www prefix. Could be the routing for those is more fixed than dynamic??

Wily_One
Premium Member
join:2002-11-24
San Jose, CA

2 edits

Wily_One

Premium Member

There is no requirement that sites must have an A record (or AAAA) for the root of the domain, or "apex" as rchandra See Profile calls it. You can have www.xyz.com resolve to your web portal and not have xyz.com resolve to any IP at all; that's perfectly legal. (Of course they need an MX record if they want to receive mail user@xyz.com, but that's unrelated to web content.)

It's only a convention that many sites do that now, often with the root record identical to the www record anyway. In fact because of the technical limitations it's actually bad practice to put any content on the root of the domain since you'll never be able to CNAME it later if needed.

Hayward0
K A R - 1 2 0 C
Premium Member
join:2000-07-13
Key West, FL

1 edit

Hayward0

Premium Member

said by Wily_One:

There is no requirement that sites must have an A record (or AAAA) for the root of the domain, or "apex" as rchandra See Profile calls it. You can have www.xyz.com resolve to your web portal and not have xyz.com resolve to any IP at all; that's perfectly legal. (Of course they need an MX record if they want to receive mail user@xyz.com, but that's unrelated to web content.)

It's only a convention that many sites do that now, often with the root record identical to the www record anyway. In fact because of the technical limitations it's actually bad practice to put any content on the root of the domain since you'll never be able to CNAME it later if needed.

No that would be odd to have WWW and root be separate content, but there are stil sites (again mostly old) that only work with the WWW prefix and come up blank with just name.xxx

rchandra
Stargate Universe fan
Premium Member
join:2000-11-09
14225-2105
ARRIS ONT1000GJ4
EnGenius EAP1250

1 edit

1 recommendation

rchandra to Wily_One

Premium Member

to Wily_One
"There is no requirement that sites must have an A record (or AAAA) for the root of the domain, or "apex" as rchandra calls it."

If you want it to actually serve pages, or as the poster asked about, respond to pings and traceroutes, yeah, you do. The point is there is no lookup magic which turns google.com into www.google.com, and something like a CNAME or DNAME is not possible. If your browser gets the SOA referral while looking up google.com (indicating the requested name is valid but the requested record type is not present), then chooses to prepend a "www.", that's the browser doing extracurricular work. You are right though that there isn't a requirement in general to place any records other than SOA and NS at the domain apex. All I'm saying is that for the specific question asked, there does indeed need to be (an) address record(s). If the A/AAAA records at the apex have the same content as www, great; but the other point is don't be surprised if they're not.

The reason it's often called "the apex of the domain" is because properly, "the root of the domain" could actually be said to be ".", the root of global DNS. In other words, that terminology is somewhat ambiguous.

Wily_One
Premium Member
join:2002-11-24
San Jose, CA

Wily_One

Premium Member

Actually, I was responding to Hayward.

Thanks for the lecture though.