hope someone knows better than me. I have a internal network with 2 subnets configured. Internally I'm routing ipv4 and ipv6 traffic. Addresses are coming form a Windows Server 2012 DHCP. I'm using DNS on the same server with forwarding requests to the IPS's
I have only ipv4 connectivity to the internet but when I try to browse a e.g. www.google.com from a Win7 machine I can find a cached ipv6 address for google im my DNS and obviously IE tries to connect using ipv6 which does not work in my case.
Is there any way to configure / prevent AAAA lookups for internet addresses?Only way so far I've found is to disable to retrieve an ipv6 DNS server address from DHCP.
Thank for your help. I'm quite new to this ipv6 stuff and still learning to walk :-)
You can't really stop the IPv6 responses to DNS lookups -- the DNS server answers with every record it's got for a given name and leaves it to the redeiver to decide what to do. You shouldn't see your systems trying to establish IPv6 connections with external
hosts, however, unless you are using Global unicast addresses OR you haven't installed the following update (our WSUS server missed it and a whole lot of grief resulted):
What happened is this: DNS is really democratic -- if it has an address registered, it tells you. Whether or not you can actually connect to it is your business. These days a query response usually contains at least 1 v6 address if it's for one of the
big boys' hosts. Since IPv6 is now the default protocol Windows tries to establish TCP sessions over v6 first and if the attempt fails it will try every other v6 address it received before trying to establish a v4 session. The
problem the update addresses is that when the destination address is not routable (like if you're using fc00/16 or fd00/16 scoped addresses). TCP would send a syn to the v6 address and wait to be acked but because the address won't route the ack never
arrives. This would cause TCP to go into the 3-strikes session timeout mode, where it tries 3 successively longer-delayed times before deciding the connection isn't going to work and moving to the next v6 address. Depending on the number of v6 addresses
it has upwards of a 2 - 3 minute delay per address before the protocol rolls to v4 (we measured 6 - 7 minutes trying to connect to Office365). What the update does (and the TechNet article explains it very well) is to assess the IPv6
addresses first and if the connection isn't possible immediately roll to v4. I suspect this may be what is behind your IE failure -- check your installed updates and if this one is missing, install it.
Proposed as answer byOldRobPMonday, March 31, 2014 11:49 PM
Microsoft is conducting an online survey to understand your opinion of the Technet Web site. If you choose to participate, the online survey will be presented to you when you leave the Technet Web site.