Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-08.txt

From: Vittorio Bertola <[email-masked]>
Date: Wed, 4 Sep 2019 14:31:09 +0200 (CEST)

> Il 10 agosto 2019 20:57 Wes Hardaker <[email-masked]> ha scritto:
> 
> 4) Now that this has had multiple implementations (though they'll need
> to change after the packet format and code changes [that they
> requested]), this is likely ready for last call after passing through
> the document for nits and addressing any last comments raised. 

Given some recent discussions on the ADD list, I think that it could make sense to add a third error code for DNS filtering. Currently, the draft has these two:

4.16.  Extended DNS Error Code 15 - Blocked

   The resolver attempted to perfom a DNS query but the domain is
   blacklisted due to a security policy implemented on the server being
   directly talked to.

4.17.  Extended DNS Error Code 16 - Censored

   The resolver attempted to perfom a DNS query but the domain was
   blacklisted by a security policy imposed upon the server being talked
   to.  Note that how the imposed policy is applied is irrelevant (in-
   band DNS somehow, court order, etc).

There is however a third case, which is "blocked by user request". The three cases differ on who made the decision to filter, i.e.:
- code 15 is for when the recursor blocks stuff that its own operator dislikes;
- code 16 is for when the recursor blocks stuff that public authorities dislike;
- the third code would be for when the recursor blocks stuff that the user (the entity that acquired the service) dislikes, e.g. for parental control, destinations not suitable for work, etc.

There was also some discussion on whether these error codes could be accompanied by a URL that the client device can use to display a human-readable explanation to the user, which would be a cleaner solution than the current practice of giving to the client a positive response, but with the IP address of a local web server instead of the original one (a practice that doesn't work well with HTTPS anyway). 

This has many security caveats, and could only work with an authenticated, trusted resolver (which is anyway true of the above error codes in themselves, since an adversarial recursor could just lie on the reason for blocking or even on the fact that it is actually blocking something). It is really too early to say whether this could work or whether it would actually be implemented, and also, on transports other than DoH, I'm not sure if applications could ever access this information. Still, perhaps a note on whether EXTRA-TEXT could bear structured information for certain error codes, and how this mechanism could be later defined, could be useful. 

(Happy to propose text if this makes sense.)

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Vladimír Čunát <[email-masked]>
Date: Wed, 4 Sep 2019 17:37:26 +0200

Hello,
authentication of blocking decisions is an interesting idea to consider,
though it's probably beyond the scope of this RFC draft.  Most
interesting cases can be already covered by securing the channels
between the first resolver that does blocking and the final stub.

> There was also some discussion on whether these error codes could be accompanied by a URL that the client device can use to display a human-readable explanation to the user, which would be a cleane…

In Knot Resolver we've developed a habit of using additional TXT records
(independently of EDNS), e.g.

; <<>> DiG 9.10.3-P4 <<>> -x 10.1.2.3
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16584
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;3.2.1.10.in-addr.arpa.         IN      PTR

;; AUTHORITY SECTION:
3.2.1.10.in-addr.arpa.  10800   IN      SOA     3.2.1.10.in-addr.arpa. nobody.invalid. 1 3600 1200 604800 10800

;; ADDITIONAL SECTION:
explanation.invalid.    10800   IN      TXT     "Blocking is mandated by standards, see references on https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml"

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 09 Sep 2019 20:44:46 -0700

Vittorio Bertola <[email-masked]> writes:

> Given some recent discussions on the ADD list, I think that it could
> make sense to add a third error code for DNS filtering. Currently, the
> draft has these two:

Hi Vittorio,

I've included responses and actions to your suggestions below.

10 Sep 4 Vittorio Bertola
=========================

10.1 DONE Add another blocked error
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  Given some recent discussions on the ADD list, I think that it could
  make sense to add a third error code for DNS filtering. Currently, the
  draft has these two:

  There is however a third case, which is "blocked by user request". The
  three cases differ on who made the decision to filter, i.e.:
  - code 15 is for when the recursor blocks stuff that its own operator
    dislikes;
  - code 16 is for when the recursor blocks stuff that public
    authorities dislike;
  - the third code would be for when the recursor blocks stuff that the
  user (the entity that acquired the service) dislikes, e.g. for
  parental control, destinations not suitable for work, etc.

  + Response: I think the idea of a "you requested we block this" makes
    sense, so I'll add that one

10.2 WONTDO you requested blocking
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  There was also some discussion on whether these error codes could be
  accompanied by a URL that the client device can use to display a
  human-readable explanation to the user, which would be a cleaner
  solution than the current practice of giving to the client a positive
  response, but with the IP address of a local web server instead of the
  original one (a practice that doesn't work well with HTTPS anyway).

  This has many security caveats, and could only work with an
  authenticated, trusted resolver (which is anyway true of the above
  error codes in themselves, since an adversarial recursor could just
  lie on the reason for blocking or even on the fact that it is actually
  blocking something). It is really too early to say whether this could
  work or whether it would actually be implemented, and also, on
  transports other than DoH, I'm not sure if applications could ever
  access this information. Still, perhaps a note on whether EXTRA-TEXT
  could bear structured information for certain error codes, and how
  this mechanism could be later defined, could be useful.

  + Response: I don't think we want to get into how log messages should
    be delivered.  If an implementation wants to put a URL in the
    additional information, that certainly would make sense.  But the
    Web does not equal the internet, and figuring out how to do it for
    everything is not easily possible.

-- 
Wes Hardaker
USC/ISI

---

From: Petr Špaček <[email-masked]>
Date: Tue, 24 Sep 2019 09:47:06 +0200

On 31. 08. 19 1:27, Wes Hardaker wrote:
> Shane Kerr <[email-masked]> writes:
> 
>> While I thought the RCODE linkage was a bit clunky, the idea of having
>> some structure to the response codes was actually kind of nice, for
>> the same reason that the 1xx, 2xx, 3xx, 4xx, 5xx status codes were
>> nice. I think the draft is better without using RCODE, but maybe we
>> can pick numbers for EDE that are grouped in a similar way?
> 
> So, assuming we *can't* easily group them by rcode.  Well, we can, but
> the results may not match given discussions with implementers.
> 
> If you want to take a whack at suggesting appropriate ranges I'd love to
> see what you come up with.  As with all loaves of bread, do you slice
> them cross-wise, length-wise or diagonally?

Main question is not "what categories we need" but "what is the purpose/who is consumer of the information"? Once we have answer to this it will be easier to establish a categorization.

IMHO the most useful information is dichotomy:
a) the problem is local (= call network admin/ISP/telco)
b) the problem is remote (= call your bank because their internetbanking broke and _do not your bother ISP_).

Such simple distinction would allow client apps way more informative message than "We’re having trouble finding that site" + would make life easier for support people.

This distinction is especially important for DNSSEC validation failures - e.g. if RRSIGs are expired your ISP/resolver operator _should not_ take any action so it is desirable to "assign blame" to web site owner. 

Shane, what do you think about proposal at the end of message
https://mailarchive.ietf.org/arch/msg/dnsop/JHYQunp0L7C_vUcBb9fOi22QfpI
- specifically Near and Far bits?

Also we need to ask stub resolver developers what would be useful for them. Bernardo, what information would make life easier for stub/app developers?

-- 
Petr Špaček  @  CZ.NIC

---

From: Tony Finch <[email-masked]>
Date: Tue, 24 Sep 2019 11:36:01 +0100

> broke and _do not your bother ISP_).

I think that's helpful.

There's an interesting case wrt blocking / censorship, e.g. "near block"
=> ISP is responsible; "far block" => required by force of law.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Portland, Plymouth, Biscay: West or southwest 5 to 7, occasionally gale 8
later except in Biscay. Moderate or rough, becoming rough or very rough,
occasionally high later in northwest Plymouth. Rain or thundery showers. Good,
occasionally poor.

---

From: Vladimír Čunát <[email-masked]>
Date: Tue, 24 Sep 2019 17:09:33 +0200

> => ISP is responsible; "far block" => required by force of law.

And when *forwarder* returns that the domain was blocked (via this RFC)?

If we go this near/far way (and I would like that), I'd suggest that we
additionally try to polish the semantics for forwarding and caching,
i.e. how the errors might best bubble through these layers.  When a
resolver only talks to other resolvers, it currently can't often
determine whether the problem is in them or in authoritative servers -
it gets the same SERVFAIL, but perhaps if all layers support extended
codes and we design them well, it might be possible to "reliably" assign
blame to authoritative side in more cases.

Example: the authoritative servers don't reply at all (to the
forwarder), so possibly after trying a second forwarder with the same
result, we probably want to assign blame to the authoritative servers
and not to the forwarder.  Well, I'm a little sorry for suggesting such
a scope creep, but still...

--Vladimir