Re: [DNSOP] Fwd: [Add] new draft: draft-grover-add-policy-detection-00

[Paul Vixie <[e-mail]>]

On Monday, 8 July 2019 18:36:07 UTC Andy Grover wrote:
> Hi all,
> 
> FYI from the ADD list, please post there or to the authors with feedback.

andy, thanks for this, it seems well intentioned and well executed. three 
small nits:

> One way to implement content control that does not rely on software
>    or settings on the end-user's computing device is DNS-based content
>    filtering, which examines a client's initial DNS request for the
>    domain providing a resource and then either returns no result or
>    returns an alternate result so that the user is presented with an
>    explanation that filtering has taken place.

dns content filtering can be triggered by response data also, and not just by 
the dns request (which itself might not be the initial request.) in common use 
by dns firewalls, for example those using DNS RPZ, policy might be triggered 
by the iteration through an authoritative name server address, or an 
authoritative name server name, or by the response (answer) address, or even 
by the stub client's IP address.

also: while it is possible to configure a dns firewall to "return no result" 
this is rare. instead, an alternate result is almost always returned, which 
may be a negative signal (no such name, or no records of that type) or a 
positive answer such as a CNAME or actual content which varies by qtype.

finally, you've jumped ahead, from the nature and purpose of the filtering 
process, to the desired new signaling that dns filtering is enabled and may be 
triggered by future requests.

i suggest new text as follows:

"One way to implement content control that does not rely on software or 
settings on the end-user's computing device is DNS-based content filtering, 
which examines various elements of a prospective DNS transaction, such as on 
the question itself, on the true answer to that question, on the authority 
name server identities involved in the iteration process, or on the end user's 
IP address, and may substitute for the true answer a policy-based answer such 
as a name error, CNAME alias, empty record set, or replacement record set."

> URL:
> https://www.ietf.org/internet-drafts/draft-grover-add-policy-detection-00.txt

also note: paul wouters and i have discussed several times the need to signal 
the effect of DNS policy filtering in the answer itself. for example, 
including the true answer and its DNSSEC metadata if any, in the additional 
data section, and using some form of SIG(0) or TSIG to sign the policy-based 
answer, which will otherwise be unverifiable. while our goal is to ensure that 
the DNS client can make its own choice about whether to use the replacement 
(policy-based) answer or the original (true) answer, and to be able to 
determine the authenticity of both, this would also satisfy your problem 
statement in this draft. you may wish to reach out to paul wouters to discuss. 
i think this work is independent of the type of DNS filtering being done -- 
that is, it does not depend on the RPZ draft on the independent submissions 
track. i'd be happy to join any such discussion, but i can't lead it at this 
time.

-- 
Paul