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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
