how-to block ads
|
|
Uniqs:
2047 |
Share Topic
 |
 |
|
|
|
Reviews:
 ·Google Voice
·Junction Networks
·Callcentric
 ·T-Mobile US
 ·AT&T U-Verse
| [IPv6] [6rd] [DNS] Cannot resolve IPv6-only zones.There seems to be a bit of confusion over which DNS servers the IPv6-enabled customers are supposed to be using. I found that using the regular recursive DNS servers (-4 dnsr{1,2}) from the non-IPv6-enabled-2Wire directly on my OS X does work on resolving AAAA records, but ONLY if the auth NS servers for the domain zone in question are available over IPv4.
Please note that in the scope of this discussion, an "IPv6-only domain" is a domain name that can be resolved ONLY via an IPv6 network, since the NS servers of the zone in question are available ONLY via IPv6. A more correct term would probably be a "domain name within an IPv6-only domain zone".
Surprisingly, using dns6rd{1,2} does NOT resolve IPv6-only domains, i.e. those that require IPv6 to access its auth NS servers. Making it pretty obvious that dns6rd{1,2} are NOT dual-stacked. WTF? So useless! What's the purpose of the dns6rd servers if they can't access IPv6-only domain zones, where the regular dnsr{1,2} already work for AAAA as is?
Seems like dns6rd{1,2} are already EOL at this point, as they offer no advantage whatsoever over -4 dnsr{1,2}, and there's not even any -6 dns6rd{1,2}, plus they don't seem to be much of anycast, either.
Using the -6 dnsr{1,2} does resolve IPv6-only domains, but the servers are very far away from me, so they'll be breaking all those unicast DNS-based CDNs in a snap (e.g. Google, Akamai etc).
Is there an ETA on when either my -4 dnsr{1,2} anycast would be dual-stacked, or the -6 dnsr{1,2} would be anycast'ed locally, instead of going back to Texas or whatnot?
Here are my sample traceroute runs from San Jose, CA. (Note that there's no -6 dns6rd{1,2}, as already mentioned above.)
% echo traceroute{\ -IM5,6\ -l}\ -w2\ dns{r,6rd}{1,2}.sbcglobal.net | xargs -n4 | sh
traceroute to dnsr1.sbcglobal.net (68.94.156.1), 64 hops max, 60 byte packets
5 12.83.39.137 (12.83.39.137) 3.464 ms 2.178 ms 1.997 ms
6 151.164.102.35 (151.164.102.35) 3.796 ms 3.268 ms 3.058 ms
7 dnsr1.sbcglobal.net (68.94.156.1) 3.347 ms 2.834 ms 3.005 ms
traceroute to dnsr2.sbcglobal.net (68.94.157.1), 64 hops max, 60 byte packets
5 12.83.39.137 (12.83.39.137) 3.155 ms 1.865 ms 1.857 ms
6 dist1-10g1-2.snfcca.sbcglobal.net (216.102.176.225) 3.463 ms 4.992 ms 3.052 ms
7 dnsr2.sbcglobal.net (68.94.157.1) 3.343 ms 3.147 ms 3.004 ms
traceroute to dns6rd1.sbcglobal.net (99.99.99.53), 64 hops max, 60 byte packets
5 12.83.39.137 (12.83.39.137) 3.051 ms 1.846 ms 1.838 ms
6 12.83.49.11 (12.83.49.11) 44.498 ms 44.029 ms 44.040 ms
7 ppp-151-164-39-47.rcsntx.swbell.net (151.164.39.47) 44.457 ms 43.917 ms 46.538 ms
8 dns6rd1.sbcglobal.net (99.99.99.53) 44.564 ms 44.067 ms 44.076 ms
traceroute to dns6rd2.sbcglobal.net (99.99.99.153), 64 hops max, 60 byte packets
5 12.83.39.137 (12.83.39.137) 3.059 ms 1.907 ms 1.769 ms
6 bb2-p2-0.snantx.sbcglobal.net (151.164.42.128) 44.352 ms 43.849 ms 43.905 ms
7 ppp-151-164-39-47.rcsntx.swbell.net (151.164.39.47) 43.946 ms 43.907 ms 43.753 ms
8 dns6rd2.sbcglobal.net (99.99.99.153) 43.984 ms 43.546 ms 43.679 ms
traceroute6 to dnsr1.sbcglobal.net (2001:1890:fff:840::10) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets
1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 3.121 ms 2.098 ms 1.968 ms
2 2001:1890:ff:ffff:12:122:100:82 (2001:1890:ff:ffff:12:122:100:82) 47.929 ms 47.989 ms 47.585 ms
3 2001:1890:fff:820:12:122:243:1 (2001:1890:fff:820:12:122:243:1) 47.562 ms 47.671 ms 47.714 ms
4 dnsr1.sbcglobal.net (2001:1890:fff:840::10) 47.718 ms 47.714 ms 47.818 ms
traceroute6 to dnsr2.sbcglobal.net (2001:1890:fff:841::10) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets
1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 2.224 ms 1.868 ms 2.016 ms
2 2001:1890:ff:ffff:12:122:100:82 (2001:1890:ff:ffff:12:122:100:82) 47.57 ms 47.429 ms 47.747 ms
3 2001:1890:fff:820:12:122:243:1 (2001:1890:fff:820:12:122:243:1) 47.372 ms 47.382 ms 47.31 ms
4 dnsr2.sbcglobal.net (2001:1890:fff:841::10) 47.834 ms 47.489 ms 47.508 ms
traceroute6: nodename nor servname provided, or not known
traceroute6: nodename nor servname provided, or not known
% traceroute -I 12.83.49.81
traceroute to 12.83.49.81 (12.83.49.81), 32 hops max, 60 byte packets
5 12.83.39.137 (12.83.39.137) 3.015 ms 1.799 ms 1.976 ms
6 12.83.49.81 (12.83.49.81) 1.908 ms 1.682 ms 1.517 ms
| |
cramer
join:2007-04-10
Raleigh, NC
kudos:7 | From a "leaked" ppt I found (some AT&T engineer's presentation from last year), he indicated AT&T would not be doing native DNSv6 during the 6rd phase. DNS resolution will be done entirely within an IPv4 domain. So AAAA NS zones shouldn't work through their DNS servers.
You should be able to use 3rd party DNS servers, like google, without any issues. Google Public DNS does have native v6 resolvers. | | |
|
Reviews:
·Google Voice
·Junction Networks
·Callcentric
·T-Mobile US
·AT&T U-Verse
| Google Public DNS cannot resolve IPv6-only zones at all! You're talking about stuff from »sites.google.com/site/ipv6implem···0/agenda ? First off, that's from 2 years ago, and second, I think you're taking the quote out of context.
As for Google Public DNS: 8.8.8.8 doesn't resolve my IPv6-only domain zone, either. Heh, it looks like even Google's 2001:4860:4860::8888 doesn't resolve my IPv6-only zone! That's apart from being 24ms away, which is unacceptable! Funny how AT&T's IPv6 servers are actually ahead of Google's, after all! (-: | |
cramer
join:2007-04-10
Raleigh, NC
kudos:7 | No, I'm referring to a ppt doc of an AT&T engineer dated Nov 2, 2011. (there's nothing really sensitive in it, but I'd bet AT&T would prefer the internet at large not get to see it.)
Unless you want to share the name of this IPv6-only domain, I cannot help debug any problems. I've not had any problems using IPv6 or IPv4 based DNS. (that I know of, I doubt I've run into a pure IPv6 only domain) | |
| I've just been using the test-ipv6.com name ds.v6ns.test-ipv6.com for DNS testing (the nameserver for v6ns.test-ipv6.com only had a AAAA record).
/M | |
| reply to ConstantineM
said by ConstantineM:As for Google Public DNS: 8.8.8.8 doesn't resolve my IPv6-only domain zone, either. Heh, it looks like even Google's 2001:4860:4860::8888 doesn't resolve my IPv6-only zone! And they state as much if you cared to read the FAQ: »code.google.com/speed/public-dns···tml#ipv6
said by ConstantineM:That's apart from being 24ms away, which is unacceptable! Surely you jest. >200ms would be unacceptable. I'd put 50ms as 'average' and 24 as 'very good'. Heck, the ping to my gateway alone is 10ms...
/M | |
Reviews:
·Google Voice
·Junction Networks
·Callcentric
·T-Mobile US
·AT&T U-Verse
| Google Public DNS slows down even www.google.com. said by mackey:said by ConstantineM:As for Google Public DNS: 8.8.8.8 doesn't resolve my IPv6-only domain zone, either. Heh, it looks like even Google's 2001:4860:4860::8888 doesn't resolve my IPv6-only zone! And they state as much if you cared to read the FAQ: » code.google.com/speed/public-dns···tml#ipv6 Hm, that's true — it does seem to be documented pretty clearly, although the rationale is never explained.
said by mackey:said by ConstantineM:That's apart from being 24ms away, which is unacceptable! Surely you jest. >200ms would be unacceptable. I'd put 50ms as 'average' and 24 as 'very good'. Heck, the ping to my gateway alone is 10ms... /M No, 24ms is absolutely unacceptable here, in this specific situation. Just ask houkouonchi  . :-) AT&T DNS is only 3ms away.
It's not just the DNS that is slow and adds noticeable latency by itself, in addition to the TCP latency of the forthcoming connection, but it also slows down unicast-based CDNs by a whole bloody lot.
E.g. instead of 3ms cached DNS, and then 3.5ms to 6ms to the edge CDN nodes, you'd be getting 24ms DNS + 77ms to the CDN. It'd be horrible. And it is very noticeable.
Yes, I've just tried it right now: Google Public DNS via IPv6 (24ms) gets me the A record for www.google.com that results in 77ms ping times, whereas AT&T dnsr1 (3ms) gives one that only has 6ms latency. The difference simply cannot be more pronounced.
Google Public DNS is known for causing very serious CDN delivery issues with unicast CDNs. Funny how it gives huge slowdowns even for Google services themselves. (-: But really it's the streaming-based CDNs that could especially bite you. Just don't use it.™ | |
cramer
join:2007-04-10
Raleigh, NC
kudos:7 | Ok. For starters, humans cannot tell the difference between 3ms and 24ms. But it does add up. 
What you are seeing in the 24+77 situation is the loss of geolocation dns optimization. When the request is made to a local at&t dns server, google's name server can see that it came from that geographic location and provide a better answer -- i.e. a server on that side of the country. When the request is made to GDNS, the subsequent request to google's name server doesn't pin down any location, so you get a generic (or random) answer.
TL;DR... When you use a generic caching DNS service, other authoritative name servers cannot get any meaningful geolocation information to optimize their answer. They only know who's asking them...
This is why you aren't directed to a more local google datacenter or cache appliance when using google's public dns service.
As for the inability of google to make IPv6 DNS lookups... that's a head-scratcher. They will accept v6 requests, but not originate any. Odd. Only having AAAA NS records should be a sufficient clue to use an IPv6 socket for the request. | |
Reviews:
·Google Voice
·Junction Networks
·Callcentric
·T-Mobile US
·AT&T U-Verse
| reply to ConstantineM
solved: replace SBC resolvers with 74.82.42.42 (ordns.he.net)Whilst hanging out on »tunnelbroker.net/forums/, I found a great anycasted IPv6 open resolver: 74.82.42.42 (ordns.he.net).
Not only does it resolve IPv6-only zones, but it is even whitelisted for Google IPv6 resolution. (SBC-wise, seems like dns6rd{1,2} are NOT actually whitelisted for Google IPv6! Only the -6 dnsr{1,2} are whitelisted.)
% traceroute ordns.he.net ; traceroute6 ordns.he.net
Wed 22 Feb 2012 13:02:24 PST
traceroute to ordns.he.net (74.82.42.42), 32 hops max, 40 byte packets
5 12.83.39.137 (12.83.39.137) 3.000 ms 2.485 ms 12.83.39.145 (12.83.39.145) 2.530 ms
6 12.122.200.9 (12.122.200.9) 3.743 ms 3.789 ms 3.815 ms
7 208.51.134.1 (208.51.134.1) 168.568 ms 208.178.58.185 (208.178.58.185) 259.526 ms dcr2-so-3-0-0.washington.savvis.net (192.205.32.46) 238.399 ms
8 po1-20G.ar3.SJC2.gblx.net (67.16.134.26) 131.115 ms 239.183 ms 219.735 ms
9 Hurrican-Electric-LLC.Port-channel100.ar3.SJC2.gblx.net (64.214.174.246) 6.012 ms 12.047 ms 5.729 ms
10 10gigabitethernet1-2.core1.fmt2.he.net (72.52.92.73) 16.753 ms 6.394 ms 6.713 ms
11 ordns.he.net (74.82.42.42) 5.998 ms 6.065 ms 6.094 ms
traceroute6 to ordns.he.net (2001:470:20::2) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets
1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 1.604 ms 1.188 ms 1.237 ms
2 la2ca02jt.ip.att.net (2001:1890:ff:ffff:12:122:127:43) 13.791 ms 13.758 ms 14.343 ms
3 10gigabitethernet5-2.core1.lax2.he.net (2001:470:0:1e6::1) 23.742 ms 15.238 ms 13.769 ms
4 10gigabitethernet2-1.core1.lax1.he.net (2001:470:0:72::1) 13.703 ms 22.945 ms 13.645 ms
5 ordns.he.net (2001:470:20::2) 13.644 ms 15.278 ms 13.676 ms
% traceroute6 www.google.com
Wed 22 Feb 2012 13:04:09 PST
traceroute6 to www.l.google.com (2001:4860:4001:801::1010) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets
1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 1.6 ms 1.155 ms 1.222 ms
2 sj2ca404me3.ip.att.net (2001:1890:ff:ffff:12:122:119:192) 4.025 ms 3.954 ms 4.019 ms
3 2001:1890:c00:8c02::1116:e9cb (2001:1890:c00:8c02::1116:e9cb) 4.459 ms 4.44 ms 4.448 ms
4 2001:4860::1:0:21 (2001:4860::1:0:21) 5.705 ms 5.472 ms 5.04 ms
5 2001:4860:0:1::1af (2001:4860:0:1::1af) 5.443 ms 5.536 ms 5.307 ms
6 2001:4860:8000:e::b (2001:4860:8000:e::b) 5.035 ms 5.087 ms 5.122 ms
74.82.42.42 works great with DNS-based CDNs, too: getting all SJC-based resolutions, for Google, Akamai and Limelight, both IPv4 and IPv6.
Note that for DNS-based CDNs it's important to only use local resolvers; so I'll only be using the IPv4 anycast, since it's in Fremont here and gives out SJC-based resolutions, whereas the Los Angeles IPv6 anycast resolver is not only further away in LA (due to AT&T only peering with HE in LA), but also gives out Los Angeles-based resolutions, including those that concern only IPv4. | |
|
