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

[Vernon Schryver <[e-mail]>]

> From: Paul Vixie <[e-mail]>
 
> some time before bad people get around to using dnssec to bypass rpz,
> the spec will have to evolve to allow new signalling ("i want to hear
> both the truth and the lie, and please sign the lie with our shared key
> so i'll know it's from you"). 

I disagree.  The last year has shown there there is limited appetite
in the IETF for RPZ work

A second issue concerns the use and purpose of the DNS.  No applications
that are not DNS debugging or forensic tools want both DNS truth and
lies.  All ordinary applications want an IP address and sometimes
application protocol data such as in SRV, MX, TLSA, and TXT.  They
don't want and generally can't deal with multiple answers, as demonstrated
by the very few applications that look past the first IP address from
gethostbyname() (or modern replacements) even when the first IP address
fails.  Except for debugging or forensic tools, the application code
itself should not and even if the IETF says it should, will not care
about more than the first usable DNS result.

Users of applications might want either truth or RPZ lies, but not both
except for debugging and forensics.  Those user preferences can vary
depending on the application.  A user of ssh might want the truth,
because ssh has its own authentication system that is more secure than
DNSSEC.  The same user might choose RPZ filtering for smtp and http.
To facilitate such user choices, it would be good if applications could
tell stubs to use an alternate /etc/resolv.conf.

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.  (Note that a single system can host both
honest and RPZ resolvers.  BIND with views can distiguish requests for
truth from requests for lies with TSIG keys and answer appropriately.
You can include TSIG keys in dig commands.)

That kludge, dual-dig "signalling" would work with future RPZ installations
with real "give me both" signaling, old RPZ installations, and covert
DNS liars.  Even if a future version of RPZ has real "give me both"
signaling, you will always need and will reach first for dual digs.


The SOA added by RPZ to the additional section is perfectly sufficient
to signal the honest presence of an RPZ lie.


Vernon Schryver    [e-mail]