Hi, Anyone knows why coogle.com only have IPv4-adresses on their authoritative DNS? https://ip6.nl/#!google.com Are there any plans to fix this? -- Marco
In message <e7a248b9-61a7-5a8a-4af9-283fb5c29389@forfun.net>, "Marco Davids (Pr ivate)" writes:
Hi,
Anyone knows why coogle.com only have IPv4-adresses on their authoritative DNS?
Are there any plans to fix this?
-- Marco
Lorenzo's reply to this statement Google isn't reachable. There are no IPv6 servers for google.com. was Unfortunately, every time we've looked at the data, the conclusion has been that it would cause unwarranted user impact. IIRC the most recent blocker was a major US ISP whose clients would experience breakage if even just one NS record was dual-stacked. It's not an infrastructure problem: the servers have supported IPv6 for years, and some zones like google.fi do have IPv6 NS records. See Message-ID: <CAKD1Yr2C3E1j9YZ+zsXWF_+A0-6FgckvijgAiJiTnFxUHxDWUQ@mail.gmail.com> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Unfortunately, every time we've looked at the data, the conclusion has been that it would cause unwarranted user impact. IIRC the most recent blocker was a major US ISP whose clients would experience breakage if even just one NS record was dual-stacked.
There are many zones (including your isc.org) that have several name servers dual-stacked, and they didn't notice a problem. Furthermore, since the DNS is a tree, resolution of google.com requires a proper resolution of the root and .com, both having IPv6 name servers. So, this answer is at least insufficient.
In message <20170515124359.a3o7evaostrvm3tk@nic.fr>, Stephane Bortzmeyer writes :
Unfortunately, every time we've looked at the data, the conclusion has been that it would cause unwarranted user impact. IIRC the most recent blocker was a major US ISP whose clients would experience breakage if even just one NS record was dual-stacked.
There are many zones (including your isc.org) that have several name servers dual-stacked, and they didn't notice a problem. Furthermore, since the DNS is a tree, resolution of google.com requires a proper resolution of the root and .com, both having IPv6 name servers.
So, this answer is at least insufficient.
It wouldn't suprise me if the dispute between Google and Cogent was not part of the issue. Pure speculation on my part. I could be completely off base. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
It wouldn't suprise me if the dispute between Google and Cogent was not part of the issue. Pure speculation on my part. I could be completely off base.
here in japan, if you are using ntt bflets layer two, your layer three provider is likely to present you with a dns server which does not return AAAAs because the v6 connectivity over ntt bflets transport sucks caterpillar snot. it's a whacky world. as geoff said long ago, if there ever is real money counting on v6 transport, these messes will straighten out. randy
On Mon, May 15, 2017 at 9:33 AM, Randy Bush <randy@psg.com> wrote:
it's a whacky world. as geoff said long ago, if there ever is real money counting on v6 transport, these messes will straighten out.
totally agree. and i'd like someone else to volunteer the "real money" traffic, please. :-) t
One badly configured mid sized ISP might blow search's entire failure budget. (Read the SRE book.) I have been trying for years to get somebody to do a measurement to show that properly configured dual stack generally has better user QoE than either protocol alone, largely because CGN doesn't scale well enough. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Mon, May 15, 2017 at 6:33 AM, Randy Bush <randy@psg.com> wrote:
It wouldn't suprise me if the dispute between Google and Cogent was not part of the issue. Pure speculation on my part. I could be completely off base.
here in japan, if you are using ntt bflets layer two, your layer three provider is likely to present you with a dns server which does not return AAAAs because the v6 connectivity over ntt bflets transport sucks caterpillar snot.
it's a whacky world. as geoff said long ago, if there ever is real money counting on v6 transport, these messes will straighten out.
randy
On Mon, May 15, 2017 at 8:43 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
There are many zones (including your isc.org) that have several name servers dual-stacked, and they didn't notice a problem. Furthermore, since the DNS is a tree, resolution of google.com requires a proper resolution of the root and .com, both having IPv6 name servers.
"didn't notice a problem" is woefully insufficient here. how carefully was this measured? how was it measured? across what diversity of traffic. what was the threshold for "a problem" here. different use cases have different tolerances for the kinds of bad user experience that google is concerned about here, both in terms of percentage and in amount of impact. please note that google has been super aggressively implementing and promoting IPv6 for years, so implications that this is somehow related to Google dragging their feet are silly. t
So, this answer is at least insufficient.
Todd Underwood <toddunder@gmail.com> writes:
On Mon, May 15, 2017 at 8:43 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
There are many zones (including your isc.org) that have several name servers dual-stacked, and they didn't notice a problem. Furthermore, since the DNS is a tree, resolution of google.com requires a proper resolution of the root and .com, both having IPv6 name servers.
"didn't notice a problem" is woefully insufficient here.
how carefully was this measured? how was it measured? across what diversity of traffic. what was the threshold for "a problem" here.
Agreed. Most domain owners/zone admins probably would not notice this, even if it was a very real problem for one or two ISPs. But given that, I do wonder how such an ISP could provide any service at all. As pointed out by Stephane, there are so many zones having dual stacked DNS servers nowadays that one more or less makes little difference. Even if that zone is google.com. The rest of the world are dual stacked wrt DNS, with very few exceptions. What about the root zone? Or microsoft.com? Or facebook.com? No users interested in either of those? Only google.com? Sorry, I do not buy the excuse. Bjørn
On Mon, May 15, 2017 at 09:20:17AM -0400, Todd Underwood <toddunder@gmail.com> wrote a message of 66 lines which said:
so implications that this is somehow related to Google dragging their feet are silly.
Implying that the root name server operators, or Verisign (manager of the .com name servers) did not test very thoroughly that everything is fine with their DNS service is just as silly.
On Mon, May 15, 2017 at 10:06 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Mon, May 15, 2017 at 09:20:17AM -0400, Todd Underwood <toddunder@gmail.com> wrote a message of 66 lines which said:
so implications that this is somehow related to Google dragging their feet are silly.
Implying that the root name server operators, or Verisign (manager of the .com name servers) did not test very thoroughly that everything is fine with their DNS service is just as silly.
I don't think that was todd's implication. I had thought i saw lorenzo/erik with some presentation materials about how ipv6 (and dns) can go wrong. I know geoff has presentation work on this matter, which he's given at least at IEPG meetings in the past. there is work ongoing though, it seems: ;; ANSWER SECTION: google.fi. 345600 IN NS ns2.google.com. google.fi. 345600 IN NS ns4.google.com. google.fi. 345600 IN NS ns1.google.com. google.fi. 300 IN NS ns3ds.google.com. ;; Query time: 10 msec ;; SERVER: 4.2.2.2#53(4.2.2.2) ;; ANSWER SECTION: ns3ds.google.com. 300 IN AAAA 2001:4860:4802:36::a -chris
On Mon, May 15, 2017 at 7:06 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Mon, May 15, 2017 at 09:20:17AM -0400, Todd Underwood <toddunder@gmail.com> wrote a message of 66 lines which said:
so implications that this is somehow related to Google dragging their feet are silly.
Implying that the root name server operators, or Verisign (manager of the .com name servers) did not test very thoroughly that everything is fine with their DNS service is just as silly.
I guess it's obvious they had different techniques for measuring the impact of their changes.... Can you point to published studies where the root and .com server operators analyzed Todd's questions? """ "didn't notice a problem" is woefully insufficient here. how carefully was this measured? how was it measured? across what diversity of traffic. what was the threshold for "a problem" here. different use cases have different tolerances for the kinds of bad user experience that google is concerned about here, both in terms of percentage and in amount of impact. """ As others have said, things will improve as more sites go dual-stack, and google.com will enable dual-stack as soon as it's viable. In the meantime, we encourage our competitors to try. ;) Damian
On Mon, May 15, 2017 at 07:55:41AM -0700, Damian Menscher <damian@google.com> wrote a message of 82 lines which said:
Can you point to published studies where the root and .com server operators analyzed Todd's questions?
For the root, the most comprehensive one is probably SAC 18 <www.icann.org/committees/security/sac018.pdf> A good summary is <www.icann.org/en/meetings/lisbon/presentation-woolf-ssac-28mar07.pdf>
On Mon, May 15, 2017 at 8:07 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Mon, May 15, 2017 at 07:55:41AM -0700, Damian Menscher <damian@google.com> wrote a message of 82 lines which said:
Can you point to published studies where the root and .com server operators analyzed Todd's questions?
For the root, the most comprehensive one is probably SAC 18 <www.icann.org/committees/security/sac018.pdf> A good summary is <www.icann.org/en/meetings/lisbon/presentation-woolf-ssac-28mar07.pdf>
Thanks for sharing. From my quick read, it looks like this was a careful analysis of the expected impact, not a review of the actual impact. It reminds me of an instructive joke: "In theory, theory and practice are the same. In practice, they are not." Damian
On Mon, May 15, 2017 at 1:25 PM, Damian Menscher via NANOG <nanog@nanog.org> wrote:
On Mon, May 15, 2017 at 8:07 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Mon, May 15, 2017 at 07:55:41AM -0700, Damian Menscher <damian@google.com> wrote a message of 82 lines which said:
Can you point to published studies where the root and .com server operators analyzed Todd's questions?
For the root, the most comprehensive one is probably SAC 18 <www.icann.org/committees/security/sac018.pdf> A good summary is <www.icann.org/en/meetings/lisbon/presentation-woolf-ssac-28mar07.pdf>
Thanks for sharing. From my quick read, it looks like this was a careful analysis of the expected impact, not a review of the actual impact. It reminds me of an instructive joke: "In theory, theory and practice are the same. In practice, they are not."
also, a BUNCH has changed since 2007... with respect to the ipv4/ipv6 landscape.
participants (9)
-
Bjørn Mork -
Christopher Morrow -
Damian Menscher -
Marco Davids (Private) -
Mark Andrews -
Matt Mathis -
Randy Bush -
Stephane Bortzmeyer -
Todd Underwood