BIND chroot environment in 10-RELEASE...gone?

Michael Sinatra michael at rancid.berkeley.edu
Sat Dec 7 02:19:08 UTC 2013


On 12/06/13 15:01, Mark Felder wrote:
> On Fri, Dec 6, 2013, at 16:33, Mark Andrews wrote:
>>
>> In message
>> <1386367748.17212.56515229.7C50AFEB at webmail.messagingengine.com>, Ma
>> rk Felder writes:
>>> On Fri, Dec 6, 2013, at 16:00, Mark Andrews wrote:
>>>>
>>>> But they should all be running a resursive validating resolver on
>>>> every box.
>>>>
>>>
>>> Are you *really* suggesting that I should run a recursive validating
>>> server on every single server I admin?
>>
>> I'm suggesting that it should be run on *every* machine in the
>> world, until all the applications that use data from the DNS have
>> been upgraded to validate the data they get from the DNS, need to
>> be be running a validating resolver.
>>
>> MiTM attacks happen all the time in the DNS.
>>
>> For mobile devices I would say "Don't leave home without one" to
>> use a well know slogan.
>>
> 
> In a world where every zone is signed (DNSSEC) I might agree, but what's
> preventing your traffic from being a victim of a MITM attack when 99% of
> the internet doesn't have DNSSEC deployed? Having a local resolver
> doesn't improve your security in a statistically significant way.

Actually, you have it backwards.  Think of it this way:

Not every website uses https, but it is VERY useful and important that
100% of the browsers out there support https.  That way, the
client/server interactions that need https can get https.  If I want
clients to access my site over https, I simply have to put a cert on my
website and configure it to force the clients to do the right thing.

What we need is 100% adoption of validation, regardless of the
percentage of zones actually signed.  That way, if I choose to sign my
zone, I know that everyone will actually be validating it.  Until we
have validating stub resolvers (and Casper seems like a promising way to
do that), having validating daemons does provide that blanket client
support that we need.

michael


More information about the freebsd-stable mailing list