Selective resolution in a corporate environment

[Vernon Schryver]

> From: Evan Hunt <each at isc.org>

> > IMHO (and I am really nobody) THIS IS WRONG! BAD BAD BAD! Your giving compa=
> > nies the ability to selective lie about DNS without the end user knowing it=
>
> Unless DNSSEC is in use, in which case the end user can figure it out,
> so RPZ doesn't bother lying.

Unless the "response-policy" statement says "break-dnssec".
In that case, the lie is sent as if the request had not asked for
DNSSEC.  The DNS client can still notice change even if it doesn't do
its own RRSIG verification.


> (I've wished before that there were some EDNS(0) options that could
> indicate "this answer has been changed due to local resolver policy" in a
> response, or "seriously: do not lie to me" in a request, but it's hard to
> see how there'd be any enforcement or verification mechanism for these,
> whereas DNSSEC already has all the crypto needed to get the job done.)

Yes, the only sane strategy is to assume that your adversaries can
block whatever they want and introduce any lies they like into any
wires you don't control.  In other words, a "changed by policy" flag
in responses would be as useful as the Evil Bit defined in RFC 3514.
A "don't lie" flag in requests might be useful when applications that
don't want lies and others that need lies (e.g. browsers using RPZ for
malware protection) share a resolver.  However, the same effect can
be had by with separate resolvers or a resolver that lies only when
asked on some ports or IP addresses.

BIND views are just as much about lying as RPZ.

I've long wanted better ways for application code I've written to
adjust resolver choices than whacking /etc/resolv.conf.  You can pervert
the _res interface, but it's worse than ugly.


Vernon Schryver    vjs at rhyolite.com