On 10/13/10 03:24, Andrey G. Sergeev wrote:
Hello David,
Mon, 11 Oct 2010 18:38:24 -0400 David Miller wrote:
On 10/11/2010 3:26 PM, Andrey G. Sergeev (AKA Andris) wrote:
Hello Alans,
Mon, 11 Oct 2010 20:07:40 +0300 Alans wrote:
Why not? OpenDNS is a good example i think.
Good example? Was it a joke? Do the traceroute on IP addresses of
the two OpenDNS resolvers and you'll find that they both are behind
the same router. Do you still trust the OpenDNS people who advertise
their service as reliable?
You are kidding right? ...or was this post a joke?
Not at all.
OpenDNS is Anycast - http://en.wikipedia.org/wiki/Anycast
Thanks, I know what anycast is and about the fact that OpenDNS uses it.
Besides of all that it still seems strange that *both* of their public
resolvers are behind the *same* router (peer1.rtr1.ams.opendns.com
[195.69.144.88] for me).
It doesn't seem strange when you think about it. Because anycast
already deals with the routing issue, your claim that having two systems
behind the same router leads to unreliability is effectively countered.
Moreover, for global anycast services (such as OpenDNS), you need a
larger covering prefix to carry the routes in BGP. In the case of
OpenDNS, it is 208.67.222.0/24. To place the two instances at different
PoPs, you would need two covering prefixes, which is a waste. For what
you appear to be concerned about, OpenDNS could simply use one address
for its service.
The reason to include a second address within the same prefix is for
non-routing issues, such as a hardware failure on the nameserver itself
where, for some reason, that anycast instance doesn't get taken out of
routing. The second address could be placed on a separate cluster in
the same PoP, so that the normal resolver failover could work properly
until the problem is corrected. Having a second address within the same
PoP is an additional layer of protection, especially if it's running on
different hardware.
See, for example:
http://www.pch.net/resources/papers/ipv4-anycast/ipv4-anycast.pdf
http://www.pch.net/resources/papers/dns-service-architecture/dns-service-architecture-v11.pdf
http://ftp.isc.org/isc/pubs/tn/isc-tn-2003-1.html (especially section 5)
As to the question of whether it is a good idea to do this type of
blacklisting in the DNS, that train has left the station already. This
sort of thing is already being implemented in an ad-hoc way in a lot of
organizations. Better to have a standard method for doing it (RPZ) than
ad-hoc, as you're less likely to run into the kinds of unpredictable
glitches that you are concerned about.
michael
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
