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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
