Broken DNS client resolvers (Was: Dealing with filtered 6to4 clients)
Tore Anderson
tore at linpro.no
Tue Oct 27 14:58:09 CET 2009
* Jeroen Massar
> try googling for "ubuntu ipv6 disable", you'll get an idea :)
Oh, by the way, googling for "Tore Anderson" returns 11.400 results.
I'm pretty sure that does _not_ give me an idea of how many name
brothers I have.... ;-) (Sorry, couldn't resist.)
> Nope, that won't help. It does not matter if there are AAAA records in
> DNS, it is all about having the client query for them and the resolver
> (the one in the CPE) which drops the requests.
In that case no additional breakage is introduced by dualstacking the
sites in question, so it's not really something I (or my customers) care
too much about really. My problem is that if dualstacking www.mycust.no
makes it unavailable for a number of users (who will still be able
access the singlestacked www.competitor-of-mycust.no just fine), then my
customer is not likely to want any quad-A records anywhere near his
site. Depending on how many users gets problems, of course.
> In that case not returning AAAA records for those would work and should
> not be too much overhead. Best solution in this case though is to
> convince the networks to fix their filtering issue, that is that they
> don't filter.
Yup, blacklisting those operators would be the inverse of the Google
approach, and I think it will work well enough - take out a large chunk
of the brokenness while not being too conservative about it either (like
Google). I think that is probably the best approach for now, at least I
intend to have a chat with our hostmasters about how to go about
implementing it.
Convincing the problematic networks to allow proto-41 is of course a
possibility, but I can understand their reluctance - I mean, they have
probably a valid reason to want to filter inbound connections to, say,
1.2.3.4 port 22, 25, 80, 139, or whatever, but if they allow proto-41
then it will be embarrassingly easy for an external attacker to sidestep
the filter by connecting to 2002:0102:0304::0102:0304 on the given port
instead.
Best regards,
--
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27
More information about the ipv6-ops
mailing list