[DNSOP] Review of draft-ietf-dnsop-structured-dns-error-03

[Mukund Sivaraman <[e-mail]>]

We're implementing RFC 8914 for error reporting from NIOS's DNS
features, and so I read this draft today:

> DNS Operations Working Group                                     D. Wing
> Internet-Draft                                                    Citrix
> Updates: 8914 (if approved)                                     T. Reddy
> Intended status: Standards Track                                   Nokia
> Expires: 28 November 2023                                        N. Cook
>                                                             Open-Xchange
>                                                             M. Boucadair
>                                                                   Orange
>                                                              27 May 2023


>                  Structured Error Data for Filtered DNS
>                 draft-ietf-dnsop-structured-dns-error-03

> Abstract

>    DNS filtering is widely deployed for various reasons, including
>    network security.  However, filtered DNS responses lack information
>    for end users to understand the reason for the filtering.

What is claimed in this introduction does not appear entirely accurate
after RFC 8914.

* RFC 8914 allows filtered DNS responses to contain the EDE EDNS option
  that can contain a populated EXTRA-TEXT field specifically for
  end-users.

* Whether the EXTRA-TEXT field is populated, and what is entered there
  is optional. Several of our customers would not even want to indicate
  that responses have been filtered (we've had trouble with even
  returning an SOA record in RPZ-rewritten answers), so the optional
  nature of this field is fine.

It appears the authors want to structure it so it can be used to display
a generated error-page within a web-browser, to avoid loading an
error-page via HTTPS, which is a fine goal.

> Existing mechanisms to provide explanatory details to end users cause
>    harm especially if the blocked DNS response is to an HTTPS server.

I suggest rewording this sentence as it reads as though the blocked DNS
response is sent to a HTTPS server. Instead, I assume what the authors
are attempting to state is that blocked DNS responses may cause harm if
they contain address records that cause web traffic for a web-domain to
be directed to a different local HTTPS server.


> 1.  Introduction

>    DNS filters are deployed for a variety of reasons, e.g., endpoint
>    security, parental filtering, and filtering required by law
>    enforcement.

I suggest keeping the above part of the paragraph ...

> Network-based security solutions such as firewalls and
>    Intrusion Prevention Systems (IPS) rely upon network traffic
>    inspection to implement perimeter-based security policies and operate
>    by filtering DNS responses.  In a home network, DNS filtering is used
>    for the same reasons as above and additionally for parental control.
>    Internet Service Providers (ISPs) typically block access to some DNS
>    domains due to a requirement imposed by an external entity (e.g., law
>    enforcement agency) also performed using DNS-based content filtering.

... and removing the part above as it's unnecessary extra detail, which
may not age well.

>    Users of DNS services that perform filtering may wish to receive more
>    explanatory information about such a filtering to resolve problems

s/such a filtering/such filtering/

>    with the filter -- for example to contact the administrator to
>    allowlist a DNS domain that was erroneously filtered or to understand

s/allowlist/allow/

>    the reason a particular domain was filtered.  With that information,
>    a user can choose another network, open a trouble ticket with the DNS

s/a user can choose another network/a user can choose to use another network/

>    administrator to resolve erroneous filtering, log the information, or
>    other uses.

s/or other uses/or do something else with it/

>    For the DNS filtering mechanisms described in Section 3 the DNS
>    server can return extended error codes Blocked, Filtered, or Forged
>    Answer defined in Section 4 of [RFC8914].  However, these codes only
>    explain that filtering occurred but lack detail for the user to
>    diagnose erroneous filterings.

>    No matter which type of response is generated (forged IP address(es),
>    NXDOMAIN or empty answer, even with an extended error code), the user
>    who triggered the DNS query has little chance to understand which
>    entity filtered the query, how to report a mistake in the filter, or
>    why the entity filtered it at all.  This document describes a
>    mechanism to provide such detail.

This has to be reworded, because the user can understand what happened
from the EXTRA-TEXT field of RFC 8914 if the information is provided.
This draft's purpose appears to be about structuring such information
for display in a UI, so the authors should describe it so.

>    One of the other benefits of the approach described in this document
>    is to eliminate the need to "spoof" block pages for HTTPS resources.
>    This is achieved since clients implementing this approach would be
>    able to display a meaningful error message, and would not need to
>    connect to such a block page.  This approach thus avoids the need to
>    install a local root certificate authority on those IT-managed
>    devices.

This is a fine goal and I like it, but:

(1) Is the need to spoof a website gone? What about clients that do not
support this draft? They may still receive e.g. address records from a
resolver that performs filtering, and attempt to use those addresses.

(2) Are web-browser developers on board with implementing such a draft?

>    This document describes a format for computer-parsable data in the
>    EXTRA-TEXT field of [RFC8914].  It updates Section 2 of [RFC8914]
>    which says the information in EXTRA-TEXT field is intended for human
>    consumption (not automated parsing).

This is the abstract of the draft that describes its purpose neatly; I
suggest placing this text in the abstract.

>    This document does not recommend DNS filtering but provides a
>    mechanism for better transparency to explain to the users why some
>    DNS queries are filtered.

> 2.  Conventions and Definitions

>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>    "OPTIONAL" in this document are to be interpreted as described in
>    BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
>    capitals, as shown here.

>    This document uses terms defined in DNS Terminology [RFC8499].

>    "Requestor" refers to the side that sends a request.  "Responder"
>    refers to an authoritative, recursive resolver or other DNS component
>    that responds to questions.

>    "Encrypted DNS" refers to any encrypted scheme to convey DNS
>    messages, for example, DNS-over-HTTPS [RFC8484], DNS-over-TLS
>    [RFC7858], or DNS-over-QUIC [RFC9250].

>    The document refers to an Extended DNS Error (EDE) using its purpose,
>    not its INFO-CODE as per Table 3 of [RFC8914].  "Forged Answer",
>    "Blocked", and "Filtered" are thus used to refer to "Forged Answer
>    (4)", "Blocked (15)", and "Filtered (17)".

> 3.  DNS Filtering Techniques and Their Limitations

>    DNS responses can be filtered by sending a bogus (also called
>    "forged") A or AAAA response, NXDOMAIN error or empty answer, or an
>    Extended DNS Error code defined in [RFC8914].

Does this enumerate all the cases? RPZ and some other lying features in
DNS implementations allow returning forged answers for other types
too. I suggest removing the "A or AAAA" part, or starting the paragraph
as "DNS responses to address queries can be filtered...".

I don't understand the last part, i.e., "DNS responses can be filtered
by sending ... an Extended DNS Error code defined in [RFC8914]". How are
responses filtered by sending an EDE EDNS option?

> Each of these methods have advantages and disadvantages that are
>    discussed below:





> Wing, et al.            Expires 28 November 2023                [Page 4]
> 
> Internet-Draft            Structured DNS Error                  May 2023


>    1.  The DNS response is forged to provide a list of IP addresses that
>        points to an HTTP(S) server alerting the end user about the
>        reason for blocking access to the requested domain (e.g.,
>        malware).  When an HTTP(S) enabled domain name is blocked, the
>        network security device (e.g., Customer Premises Equipment (CPE)
>        or firewall) presents a block page instead of the HTTP response
>        from the content provider hosting that domain.  If an HTTP
>        enabled domain name is blocked, the network security device
>        intercepts the HTTP request and returns a block page over HTTP.
>        If an HTTPS enabled domain is blocked, the block page is also
>        served over HTTPS.  In order to return a block page over HTTPS,
>        man in the middle (MITM) is enabled on endpoints by generating a
>        local root certificate and an accompanying (local) public/private
>        key pair.  The local root certificate is installed on the
>        endpoint while the network security device stores a copy of the
>        private key.  During the TLS handshake, the on-path network
>        security device modifies the certificate provided by the server
>        and (re)signs it using the private key from the local root
>        certificate.

>        *  However, configuring the local root certificate on endpoints
>           is not a viable option in several deployments like home
>           networks, schools, Small Office/Home Office (SOHO), or Small/
>           Medium Enterprise (SME).  In these cases, the typical behavior
>           is that the filtered DNS response points to a server that will
>           display the block page.  If the client is using HTTPS (via a
>           web browser or another application) this results in a
>           certificate validation error which gives no information to the
>           end-user about the reason for the DNS filtering.

>        *  Enterprise networks do not assume that all the connected
>           devices are managed by the IT team or Mobile Device Management
>           (MDM) devices, especially in the quite common Bring Your Own
>           Device (BYOD) scenario.  In addition, the local root
>           certificate cannot be installed on IoT devices without a
>           device management tool.

>        *  An end user does not know why the connection was prevented
>           and, consequently, may repeatedly try to reach the domain but
>           with no success.  Frustrated, the end user may switch to an
>           alternate network that offers no DNS filtering against malware
>           and phishing, potentially compromising both security and
>           privacy.  Furthermore, certificate errors train users to click
>           through certificate errors, which is a bad security practice.
>           To eliminate the need for an end user to click through
>           certificate errors, an end user may manually install a local
>           root certificate on a host device.  Doing so, however, is also
>           a bad security practice as it creates a security vulnerability

>           that may be exploited by a MITM attack.  When a manually
>           installed local root certificate expires, the user has to
>           (again) manually install the new local root certificate.

The above is a good explanation, but it appears excessive, deviating
from the gist of the draft. Instead, the authors could concisely write
that a client may see certificate errors when attempting to browse error
pages due to the redirection of HTTPS traffic to an unauthentic
webserver.


>    2.  The DNS response is forged to provide a NXDOMAIN response to
>        cause the DNS lookup to terminate in failure.  In this case, an
>        end user does not know why the domain cannot be reached and may
>        repeatedly try to reach the domain but with no success.
>        Frustrated, the end user may use insecure connections to reach
>        the domain, potentially compromising both security and privacy.

This appears to be a good example where having a structured error is an
advantage over the current practice.

>    3.  The extended error codes Blocked and Filtered defined in
>        Section 4 of [RFC8914] can be returned by a DNS server to provide
>        additional information about the cause of a DNS error.

>    4.  These extended error codes do not suffer from the limitations
>        discussed in bullets (1) and (2), but the user still does not
>        know the exact reason nor he/she is aware of the exact entity

I suggest removing "he/she"; it reads well without it.

>        blocking the access to the domain.  For example, a DNS server may
>        block access to a domain based on the content category such as
>        "Malware" to protect the endpoint from malicious software,
>        "Phishing" to prevent the user from revealing sensitive
>        information to the attacker, etc.  A user needs to know the
>        contact details of the IT/InfoSec team to raise a complaint.

A user does not "need to know". "A user may want to know" is perhaps
better text here. Depending on the feature implementing filtering (e.g.,
RPZ vs. parental control) I doubt if some of our customers would even
indicate if rewriting/filtering occurred going by past activity. So all
this is optional.

>    5.  When a DNS resolver or forwarder forwards the received EDE
>        option, the EXTRA-TEXT field only conveys the source of the error
>        (Section 3 of [RFC8914]) and does not provide additional textual
>        information about the cause of the error.

This claim does not appear accurate. RFC 8914 section 3 mentions "the
source of the error SHOULD be attributed in the EXTRA-TEXT field" in the
context of forwarding only, and just that the source is also included
alongside any other text that may also be present. I don't see that
there are any limitations on what may be included in the EXTRA-TEXT
field, and there could even be multiple EDE options.

> 4.  I-JSON in EXTRA-TEXT Field

>    DNS servers that are compliant with this specification send I-JSON
>    data in the EXTRA-TEXT field [RFC8914] using the Internet JSON
>    (I-JSON) message format [RFC7493].

Reword as "DNS servers that are compliant with this specification send
data in the EXTRA-TEXT field [RFC8914] encoded using the Internet JSON
(I-JSON) message format [RFC7493]."

However, using some kind of binary encoding may reduce the size of the
EDE option. DNS client software can decode the binary encoding for
human-readable presentation.

>       Note that [RFC7493] was based on [RFC7159], but [RFC7159] was
>       replaced by [RFC8259]
.
>    This document defines the following JSON names:

>    c: (contact)  The contact details of the IT/InfoSec team to report
>       mis-classified DNS filtering.  This field is structured as an
>       array of contact URIs (e.g., tel, sips, https).  At least one
>       contact URI MUST be included.  This field is mandatory.

I suggest not making it mandatory. The operator may wish to indicate
that filtering occurred without attracting flak from some users.

Also, just how many IT teams respond or take action when something is
reported to them? Not all do.

>    j: (justification)  'UTF-8'-encoded [RFC5198] textual justification

>       for this particular DNS filtering.  The field should be treated
>       only as diagnostic information for IT staff.  This field is
>       mandatory.

I suggest not making it mandatory. If it is mandatory, some operators
may put whitespace or "N/A" in the field's value.

>    s: (suberror)  the suberror code for this particular DNS filtering.
>       This field is optional.

There are 16 bits in RFC 8914's INFO-CODEs, allowing a total of 65536
values. I suggest adding more values there than starting another
registry. Try to keep text and constructs as simple as it can be.
There's already an RCODE, and an EDE INFO-CODE, and the draft's
proposing a 3rd level of suberror code. This is excessive.

>    o: (organization)  'UTF-8'-encoded human-friendly name of the
>       organization that filtered this particular DNS query.  This field
>       is optional.

>    New JSON names can be defined in the IANA registry introduced in
>    Section 11.2.  Such names MUST consist only of lower-case ASCII
>    characters, digits, and hyphens (that is, Unicode characters U+0061
>    through 007A, U+0030 through U+0039, and U+002D).  Also, these
>    names MUST be 63 characters or shorter and it is RECOMMENDED they
>    be as short as possible.

>    The text in the "j" and "o" names can include international
>    characters.  If the text is displayed in a language not known to the
>    end user, browser extensions to translate to user's native language
>    can be used.

I suggest deleting this paragraph. It has already been mentioned
elsewhere that the fields are UTF-8 encoded. Describing browser
extentions to translate strings deviates from the topic of this draft.

>    To reduce packet overhead the generated JSON SHOULD be as short as
>    possible: short domain names, concise text in the values for the "j"
>    and "o" names, and minified JSON (that is, without spaces or line
>    breaks between JSON elements).

s/packet overhead/DNS message size/

It isn't exactly "overhead" if it's the contents.

>    The JSON data can be parsed to display to the user, logged, or
>    otherwise used to assist the end-user or IT staff with
>    troubleshooting and diagnosing the cause of the DNS filtering.

> 5.  Protocol Operation

> 5.1.  Client Generating Request

>    When generating a DNS query the client includes the EDE option
>    (Section 2 of [RFC8914]) in the OPT pseudo-RR [RFC6891] to elicit the
>    EDE option in the DNS response.

Is this what this draft requires, or is the sentence above claiming that
RFC 8914 requires it as well?

> It SHOULD use an OPTION-LENGTH of 2,
>    the INFO-CODE field set to "0" (Other Error), and an empty EXTRA-TEXT
>    field.  This signal indicates that the client desires that the server
>    responds in accordance with the present specification.

Why?

This draft appears to describe a simple extension of EDE, limited to
structuring the value in the EXTRA-TEXT field.

> 5.2.  Server Generating Response

>    When the DNS server filters its DNS response to an A or AAAA record
>    query, the DNS response MAY contain an empty answer, NXDOMAIN, or
>    (less ideally) forged A or AAAA response, as desired by the DNS
>    server.

Again, limiting to A/AAAA is not correct. Other RR types are also
filtered by filtering features in implementation today.

> In addition, if the query contained the OPT pseudo-RR the DNS server
>    MAY return more detail in the EXTRA-TEXT field as described in
>    Section 5.3.

>    Servers may decide to return small TTL values in filtered DNS
>    responses (e.g., 2 seconds) to handle domain category and reputation
>    updates.

Suggesting TTLs here appears off-topic. The draft is just about
structuring the EDE.EXTRA-TEXT field.

>    Because the DNS client signals its EDE support (Section 5.1) and
>    because EDE support is signaled via a non-cached OPT resource record
>    (Section 6.2.1 of [RFC6891]) the EDE-aware DNS server can tailor its
>    filtered response to be most appropriate to that client's EDE
>    support.  If EDE support is signaled in the query the server MUST NOT
>    return the "Forged Answer" extended error code because the client can
>    take advantage of EDE's more sophisticated error reporting (e.g.,
>    "Filtered", "Blocked").  Continuing to send "Forged Answer" even to
>    an EDE-supporting client will cause the persistence of the drawbacks
>    described in Section 3.

Why? What if forged-answer info-code is returned? A web user-agent can
ignore the answer section and use the structured EXTRA-TEXT field
anyway. The paragraph above is not very clear.

> 5.3.  Client Processing Response

>    On receipt of a DNS response with an EDE option from a DNS responder,
>    the following actions are performed on the EXTRA-TEXT field:

>    *  Verify the field contains valid JSON.  If not, the requestor MUST
>       discard data in the EXTRA-TEXT field.

>    *  The response MUST be received over an encrypted DNS channel.  If
>       not, the requestor MUST discard data in the EXTRA-TEXT field.

Why is this additional requirement present over RFC 8914? RFC 8914 does
not prevent unencrypted DNS transports from carrying a human readable
EXTRA-TEXT field (which may be displayed by a client program such as
'dig').

>    *  Servers which don't support this specification might use plain
>       text in the EXTRA-TEXT field so that requestors SHOULD properly

s/in the EXTRA-TEXT field so that/field, and so/


> 6.  Interoperation with RPZ Servers

>    This section discusses operation with an RPZ server [RPZ] that
>    indicates filtering with a NXDOMAIN response with the Recursion
>    Available bit cleared (RA=0).

>    When a DNS client supports this specification it includes the EDE
>    option in its DNS query.

>    If the server does not support this specification and is performing
>    RPZ filtering, the server ignores the EDE option in the DNS query and
>    replies with NXDOMAIN and RA=0.  The DNS client can continue to
>    accept such responses.

>    If the server does support this specification and is performing RPZ
>    filtering, the server can use the EDE option in the query to identify
>    an EDE-aware client and respond appropriately (that is, by generating
>    a response described in {#server-response}) as NXDOMAIN and RA=0 are
>    not necessary when generating a response to such a client.

If NXDOMAIN is not necessary, what RCODE will be returned in
RPZ-rewritten responses where NXDOMAIN is returned today?


Thank you for attempting this. Some of what is described appears as an
improvement over what is practised currently.

The review above may seem overly critical because it mostly contains
suggestions to correct/change text, rather than praise for what is good.

However, overall, after reading the draft till the end and considering
what it proposes, I think that based on the INFO-CODE, having a web
browser display the EXTRA-TEXT field of RFC 8914 as a text string would
serve the purpose of displaying information (whatever the operator
desires to show) about what filtering occurred, and any other free-text
such as contact information. Perhaps additional EDE INFO-CODEs may be
added to the RFC 8914 registry as required, and it may be prescribed
that browsers avoid loading web-pages with address records from forged
answers and instead display the EXTRA-TEXT field.

This JSON encoding of the same and adding a registry for fields within
it appears excessive for the purpose it aims to serve.

		Mukund