Add "Policy imposed by the operator of the DNS server" suberror

[boucadair]

as per the discussion with Neil

[danwing]

Ok. I can add. As this code point, and the previous one (network policy) are defined by our own document we need some explanatory text. The only thing I had to say about 'network policy' is that it's a codepoint used if the network operator providing IP service wanted the filtering.

`7. New Sub-Error Codes Definition

This document defines new IANA-registered Sub-Error codes, below.

7.1. Network Operator Policy

• Number: 5

• Meaning: Network Operator Policy

• Applicability: Blocked, Forged

• Reference: the operator providing IP connectivity filtered the response

• Change Controller: IETF

7.2. DNS Operator Policy

• Number: 6

• Meaning: DNS Operator Policy

• Applicability: Blocked, Forged

• Reference: the operator of the DNS server filtered the response

• Change Controller: IETF `

It feels thin.

[danwing]

Need to strengthen the text, else folks will righteously ask,

"aren't all the RFC8914 errors 'by the DNS operator', thus all of them should use sub-error=6".

Is sub-error=6 (DNS operator) intended to be a catch-all? Do we want to just say 'catch-all' (or similar?) or perhaps allow the sub-error number to be omitted from the JSON?

I sort of consider "network operator" (sub-error=5) to be restrictions based on IP address or ASN or some-such, where the network operator sends a list of IP addresses (or perhaps subscriber ID's, if there is some secret decoration of the DNS query as done by Cisco's Umbrella and by some other DNS operators to differentiate "kid's computer" from "parent's computer" because obviously IP address is inadequate. I did not yet add text explaining that to the pull-request I have on the table right now.

[danwing]

Stepping back a bit:

Many DNS servers will forge their answer, in an (old-school) attempt to point the browser at an error page explaining the reason for the block. This was useful in the days of HTTP and in the days of non-REST APIs. However now with HTTPS and applications using HTTPS APIs ("REST APIs"), such forging won't cause the web page to be displayed to the user. The user running a browser will see an invalid certificate warning or the user will need to a priori install an additional trusted CA; both of those are bad. The user running an application will see who-knows-what error from the application; likely some message indicating failure to establish a secure connection.

We can expect such DNS servers to continue their behavior. If they add support for EDE and also for Structured DNS error, they may (or may not) use "Forged Answer" in their EDE response. Afterall, "forgery" sounds bad, right? Although the RFC8914 error codes Blocked, Filtered, and Censored make it clear which entity caused the filtering, the RFC8914 "Forged Answer" does not. Thus, it becomes the responsibility of the sub-error code to explain why a Forged Answer occurred.

I propose that we define 3 sub-error codes, to be used only when the RFC8914 error is "Forged Answer", and those three sub-errors mimic the RFC8914 answers, with identical meaning:

Blocked Filtered Censored

Thoughts?