IPv6 Records on an IPv4 Network

[Phil Mayers]

On 07/21/2010 10:10 PM, Martin McCormick wrote:
> 	This is admittedly not a bind question, but it has
> become a major nag factor and I am not sure what to recommend.
>
> 	We delegate our Microsoft Active Directory zone to
> Microsoft domain controllers and they have stuffed their zone
> with about 750 AAA records and all are publicly visible if one
> does a lookup. even the top level of the AD domain has 10 IPv6

Yes. This is windows' default behaviour.

> responses, one for each controller. The AD admins say that IPv6
> is turned off and that the work stations register IPv6 addresses
> automatically and so forth, but the final truth is that they are

If IPv6 is turned off, the windows machines should not be registering 
IPv6 addresses. Maybe IPv6 was turned on in the past, and they haven't 
been garbage-collected for some reason? (Windows DNS records which were 
inserted by dynamic update are supposed to be garbage collected if left 
untouched after 7 days IIRC)

> there, however they got there, and other systems will get the
> records when they try to resolve the host name.
>
> 	Recently, there was a Microsoft update which appears to
> cause the resolvers on these Windows7 systems to favor
> IPv6 records first and now I am getting reports of timeouts from
> Windows boxes looking up other Windows boxes.

I don't think this is true - I think windows has *always* preferred a 
AAAA lookup under all versions with IPv6 support.

However, windows should only be making AAAA lookups if the client itself 
has an IPv6 address. Clients without IPv6 addresses will only make A 
lookups.

>
> 	What I am asking the list is whether or not anybody
> knows of a way to get the Microsoft controllers to ignore the
> IPv6 registrations. Having 0 IPv6 records would probably solve
> the problem until the day we get a IPv6 allocation and make our
> nework IPv6 capable. As of now, it is a down right nuisance. I
> am running bind in its default mode where it could handle both
> IPv4 and IPv6 addresses, but we have no IPv6 addresses at all in
> the zones that we do not delegate. I believe that if I ran bind
> in IPv4-only mode, it would make no difference because the
> problem zone is delegated. If I am wrong about that, please let
> me know.

Correct, that won't help.

(In fact, even in IPv4 mode, bind supports AAAA records. The content of 
the DNS records is unrelated to the transport)

You have two issues, neither of which are bind-related:

  1. Clients and servers have registered IPv6 addresses via DDNS. They 
*must* have had IPv6 enabled for this to happen. Either they still do 
have IPv6 enabled, or they don't and the records haven't been garbage 
collected.

  2. Some clients are making and using AAAA lookups. Again, the clients 
MUST have an IPv6 address if this is the case.

Basically you have some IPv6 somewhere inside your network. Maybe 
someone has brought up a tunnel and turned on internet connection 
sharing - we've had problems with that.

Also, about turning IPv6 off - don't do that. Microsoft test with it 
turned on, and some windows components expect to be able to talk to 
themselves locally on IPv6 (I think newer versions of IIS do this for 
example). Again, we've had problems with apps when server admins have 
disabled IPv6.

Take a look at one of the clients - I'm fairly sure you'll find they 
have IPv6 somewhere. You might need to investigate blocking it 
internally if someone has "leaked" it in using connection sharing - see:

http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-06

HTH