IPv6 Records on an IPv4 Network

[Rock July]

Windows Vista and 7 clients will query both type A and AAAA query even only IPv4 
interface is enabled. If I put the option "filter-aaaa-on-v4 {yes;};", will my 
DNS reject the AAAA queries?

Thanks
Rock




________________________________
From: Phil Mayers <p.mayers at imperial.ac.uk>
To: bind-users at lists.isc.org
Sent: Thu, July 22, 2010 3:45:29 PM
Subject: Re: IPv6 Records on an IPv4 Network

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
_______________________________________________
bind-users mailing list
bind-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20100722/20d33bf9/attachment.html>