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

From: Andy Grover <[email-masked]>
Date: Mon, 8 Jul 2019 11:36:07 -0700

Hi all,

FYI from the ADD list, please post there or to the authors with feedback.

-------- Forwarded Message --------
Subject: [Add] new draft: draft-grover-add-policy-detection-00
Date: Mon, 8 Jul 2019 11:29:02 -0700
From: Andy Grover <[email-masked]>
To: [email-masked]

Hello all,

We've posted an initial draft of draft-grover-add-policy-detection,
which proposes a method of identifying if content filtering or other
policy is implemented on the local resolver, so applications doing DNS
resolution can adjust their behavior.

Thanks -- Regards -- Andy

-------- Forwarded Message --------
Subject: New Version Notification for
draft-grover-add-policy-detection-00.txt
Date: Mon, 08 Jul 2019 10:46:45 -0700
From: [email-masked]
To: Andy Grover <[email-masked]>, Peter Saint-Andre
<[email-masked]>

A new version of I-D, draft-grover-add-policy-detection-00.txt
has been successfully submitted by Peter Saint-Andre and posted to the
IETF repository.

Name:		draft-grover-add-policy-detection
Revision:	00
Title:		DNS Resolver-Based Policy Detection Domain
Document date:	2019-07-08
Group:		Individual Submission
Pages:		6
URL:
https://www.ietf.org/internet-drafts/draft-grover-add-policy-detection-00.txt
Status:
https://datatracker.ietf.org/doc/draft-grover-add-policy-detection/
Htmlized:
https://tools.ietf.org/html/draft-grover-add-policy-detection-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-grover-add-policy-detection

Abstract:
   This document specifies the behavior that is expected from the Domain
   Name System with regard to DNS queries for the special-use domain
   name 'TBD.arpa' and designates this domain as a special-use domain
   name.

-- 
Add mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/add

---

From: Paul Vixie <[email-masked]>
Date: Fri, 12 Jul 2019 00:46:04 +0000

> 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."

> 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

---

From: Alejandro Acosta <[email-masked]>
Date: Tue, 16 Jul 2019 19:04:31 -0400

<Almost off-topic>

> resolution can adjust their behavior.

I wonder if this technique will also expand to http(s) blocks / policies
/ filtering

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Jul 2019 16:06:02 -0700

> I wonder if this technique will also expand to http(s) blocks / policies

That is not an idea I would be in favor of.

-Ekr

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Rob Sayre <[email-masked]>
Date: Wed, 17 Jul 2019 16:57:00 -0700

On Wed, Jul 17, 2019 at 4:44 PM Paul Hoffman <[email-masked]> wrote:

> On Jul 17, 2019, at 4:33 PM, Tommy Jensen <Jensen.Thomas=
> [email-masked]> wrote:
> >
> > I appreciate the intent behind this draft to allow DNS-capable apps to
> detect if configured DNS resolvers need to be deferred to. However, I agree
> with Ralf that NXDOMAIN is the wrong way to signal that.
> >
> > What about defining a new TXT record format to signal the presence of
> policies? This has the benefits of 1) not overloading the interpretation of
> whether the domain exists or not as well as 2) giving room for future
> flexibility beyond the binary "resolver (does|does not) have DNS policies
> in place you shouldn't bypass" signal.
>
> Please see <
> https://datatracker.ietf.org/doc/draft-sah-resolver-information/> for a
> proposal that is being discussed in the DNSOP WG. It proposes a message
> format (JSON) and two transports (DNS and HTTPS) that can be used by a
> resolver for lots of things, including the policy ideas in the draft that
> this thread is about.

Is there a good definition of the term "policy ideas"?

thanks,
Rob

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 18 Jul 2019 00:08:36 +0000

> Is there a good definition of the term "policy ideas"?

No, but you already knew that. Most specifications of policy ever created in the IETF have been dissatisfying to some people for various (good) reasons. That's one of the reasons why the spec in draft-sah-resolver-information allow anyone to create their own temporary specs before standardization.

--Paul Hoffman

---

From: Rob Sayre <[email-masked]>
Date: Wed, 17 Jul 2019 17:12:09 -0700

On Wed, Jul 17, 2019 at 5:08 PM Paul Hoffman <[email-masked]> wrote:

> No, but you already knew that.

Yes, I did. But you still wrote it.

> Most specifications of policy ever created in the IETF have been
> dissatisfying to some people for various (good) reasons. That's one of the
> reasons why the spec in draft-sah-resolver-information allow anyone to
> create their own temporary specs before standardization.
>

So, the spec allows anyone to create whatever they want? Why would that be
called a standard? Isn't that just writing code?

I might be missing something, but this doesn't seem to make sense.

thanks,
Rob