Bind and blacklist IP file

[Michael Sinatra]

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