> From: Evan Hunt <e...@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 v...@rhyolite.com _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
