[DNSOP] [e-mail]

[Vernon Schryver <[e-mail]>]

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

> there will in my model be only one resolver, and while it may or may not
> be trusted to tell the truth, it may or may not also be trusted to tell
> a useful lie. that is, truth has value, and some lies also have value,
> for example an RPZ answer of NXDOMAIN when the qname is a DGA. but right
> now we have no authentication of the lies, while we do have it for the
> truth (if DNSSEC is used). so, i am conflating two issues in my
> stick-figure of the moment: authentication of lie source and content,
> and, the ability of an end-user via resolv.conf or API to tell her local
> applications what lie-source to believe, if any.

I separate those issues into

  1. authenticating (signing) AD=1 in responses from resolvers to
    stubs.  This is needed wherever the resolver is not reached by
    "localhost" and in some cases even where "localhost" is used.

    Most stubs do not reach their resolvers via localhost and either
    trust unsigned AD bits or ignore them.  Either case makes DNSSEC
    almost a sham.

    This needs protocol work or the routine use of TSIG on requests and
    something for key distribution or public keys with TSIG or something
    else, new or old.

    This is not an RPZ issue.

  2. applications that demand truth getting it instead of RPZ lies
    from resolvers that do RPZ filtering.

 
> i'm on a different trail entirely. we have to include the truth if it's
> dnssec signed, since the client will know we're lying if we do
> otherwise. ...

How does a stub know that the resolver gave an RPZ lie via DNSSEC?
RPZ lies don't include RRSIGs.  Would the stub interate to get NS, A,
AAAA, and RRSIG rrsets starting with the root and then either fail to
get RRSIGs somewhere in the chain and stop with "oh, never mind", or
check that signature chain against the rrset it got a long time ago
from the resolver?  The stub probably needs a cache for all of those
rrsets, including caching the absense of RRSIG rrsets.  It must pay
attention to authority sections and the right rrsets in additional
sections.  It would need to resolve CNAME (and DNAME?) chains.  And
so forth for a lot of what makes a recursive resolver.

On the other hand, a stub could not worry about DNSSEC and watch
for the special RPZ SOA in the additional sections of RPZ lies,
and when it sees one, ask again for truth.

On the third hand, a stub working for an application that wants truth
could always ask for truth instead of RPZ filtering.  As I keep saying
only debugging applications want both truth and lies, and they don't
need both at once (and couldn't receive both through current APIs).
They could make two requests of the stub, one for truth and one for
lies.

I think the second hand is much better that the first and the third
is best.  Not only do they not force stubs to become resolvers, they
give truth to applications that want it even when DNSSEC is not involved
(as it won't be if ever in almost all of com and net).  Applications
that want truth instead of RPZ lies don't care whether DNSSEC was
involved; they just want the resolver's best shot at the truth.

They might separately want to tell the stub to discard anything from the
resolver that lacks a (signed) AD=1.

Note that RPZ lies are distinguished by the following and only the 3rd is
dispositive:
   - no RRSIG rrsets
   - AD=0
   - that bogus additional section SOA 


Vernon Schryver    [e-mail]