Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Vernon Schryver <[e-mail]>]

> From: Paul Vixie <[e-mail]>

> well, yes, but a directive in /etc/resolv.conf saying what lies to 
> trust, or whether to trust all of them, or whether to trust none of 
> them, would be a way for a system operator or owner to set response 
> policy for all applications.

> if an application wants a different kind of lies than is the default in 
> /etc/resolv.conf, it will need API hooks to say so.

That's what I meant.
It could be done today with small, upward compatible changes to
libresolv to allow the application to specify resolver IP addresses,
port numbers, and TSIG keys.  (and equivalently in Windows)

(Note that TSIG keys in resolv.conf would help provide a trustworthy
path to your trusted resolver for reasons unrelated to RPZ.)
(well, getting libresolv to sign and check TSIG might not be that small.)


> > On the other hand, there is already signaling that provides both DNS
> > truth and lies.  A UNIX shell command like `alias honest "dig @8.8.8.8"`
> > implements kludge "signaling" to get the DNS truth, while straight
> > `dig` gets the possible lie.
>
> alas, this is unreliable. 

A network that routes requests to 8.8.8.8 to inject DNS lies will also
arrange to ignore or pervert any DNS-in-band tell-the-truth signaling.
Without access to a trustworthy resolver, tell-the-truth signaling is
useless because you can't trust it.

If you have a trustworthy path to a trustworthy verifying resolver,
then by definition you trust that resolver to do the things you
want with RPZ and everything else, and so none of your applications
need both answers.
With a trustworthy resolver, you don't need in-band trugh signaling
except for debugging, and all of the many people who have debugged RPZ
installations have not needed more than log files and `dig` to different
resolvers and resolver views so far.


> > The SOA added by RPZ to the additional section is perfectly sufficient
> > to signal the honest presence of an RPZ lie.
>
> well, yes. but it may be the law of the land in some countries that 
> citizens accept DNS lies, whereas foreign visitors can accept DNS truth. 
> so i'd like the protocol to carry both (lies and truth), with 
> policy-level digital signatures on the lies, to be sure they are coming 
> from the place we're expecting our lies to come from.

No jurisdiction will allow foreign visitors to bypass local filters
forever, because foreign visitors blab both the banned data and the
banned tools.  We've a very long history of this in print media.  Recall
that the Iron Curtain borders took an extremely dim view of smuggling
subversive literature.  And didn't Tailand recently sanction some
foreigners for lese magesty in forgien on-line media?  Isn't there
talk about China blocking all tunnels including those of foreigners?

Even with the acquiescence of regimes, there are insurmountable practical
technical and non-technical issues in providing both RPZ filtered and
raw DNS answers, configuring applications, and ensuring that citizens
don't get foreign, uncensored versions of applications.  It's one thing
for a regime to allow foreigners to use foreign services (which I claim
never lasts), and quite another thing for in-country operators to
expect government censors to understand and believe that citizens can't
use the truthful results in DNS responses.  If you were a DNS operator
in China, would you ever allow your resolver to give truthful answers
about some domains in any form or in response to any signaling?--of course
not!

We're seeing something like this happen with the European demands that
the "rights to be forgotten" apply accross borders.


Vernon Schryver    [e-mail]