Re: [DNSOP] Structured Data for DNS Access Denied Error Page

Eric Rescorla <ekr@rtfm.com> Fri, 09 July 2021 17:00 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023EE3A27F7 for <dnsop@ietfa.amsl.com>; Fri, 9 Jul 2021 10:00:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dwi_lGDMMqiV for <dnsop@ietfa.amsl.com>; Fri, 9 Jul 2021 10:00:54 -0700 (PDT)
Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A53283A27EF for <dnsop@ietf.org>; Fri, 9 Jul 2021 10:00:54 -0700 (PDT)
Received: by mail-il1-x136.google.com with SMTP id j12so11035190ils.5 for <dnsop@ietf.org>; Fri, 09 Jul 2021 10:00:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w2vV3HpVMOuH2MV4StavYHuYqOipd434QZPG1CM1NdA=; b=n+YQIDKyci1MX6gHJCZm6reZNFG4DwNkC4B60y6a0MK4125o7QJlP1KJ0Bd3Al5Zd6 w6XNmcsylJcVLwJIBw2YxQ0XsMgf6zc/k2AW13UJ7460EfP0apWLPRWa2MigYw4zNNqs oVPlm3xLZw7w2EzlWWE5kgYDttJOXbnHusCn6e1kmBajyhTTPfKsrfG2kzll3t3IjoQt pWKEMMGIUkDfR8wqW1Y2zWM3zK7VAxMxkEULUHRl4odyFYBFVx1CkHFw+h8jpgdt178n ++lZWsUtv+LDrbPrWQ5Oa0YjAhbzMaqTUhvF0YE8KSvFVV9jQ73IQkLq+5/aYCeC6nZP LfEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w2vV3HpVMOuH2MV4StavYHuYqOipd434QZPG1CM1NdA=; b=nAVT9Q95j8AifJ5io+ZPn9qeToWdIw1hOnqTzCdloPWrFg367VD9LQHgC18KkReq5P pTf53JNOyS8FGQKeGIf4oJWB+l3XpJ3j4/l/vcPaNNvMBmeMoZffNfx9wGiJbtn1MMNl gf77Tv4V8J362pf/nmL5EPCs+5LycPrgkVvJxKpAg1QjipmOo74mvwvdZxhIEBxD3R7t tkZumRmURZkbNe3OcKpCbHk18CvISeWSu9b09WTCZlPMA5RPJfYVhiIw863UG0GJg6DS faxsmFOqpKI43kvBssz8dR0+z14NU/gBCrI6G7MxCjKtnbCcjSJKz5bREQoKowEOriXG jamg==
X-Gm-Message-State: AOAM531k4nnZeTrMrCVW2wHJBfIAcPy3fpNeeUKGsM1rKzyxGndn6ZJY nGZElqMYJm+jP9dWpOpY3ITn4OiCGLb0jnfFO7aZlA==
X-Google-Smtp-Source: ABdhPJzhO/efqN6WTaNYAoW8juXULp44SIxbXVWcpHhgGwMqOl8PkyYdaikpRvRi4J1gJLYB92L2F6eQVVZt1tG4Rb8=
X-Received: by 2002:a92:d848:: with SMTP id h8mr6537841ilq.282.1625850053382; Fri, 09 Jul 2021 10:00:53 -0700 (PDT)
MIME-Version: 1.0
References: <2F619855-709C-4F7C-B33D-FE296866A606@gmail.com>
In-Reply-To: <2F619855-709C-4F7C-B33D-FE296866A606@gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 9 Jul 2021 10:00:17 -0700
Message-ID: <CABcZeBMSw3s95+KHFhSCrx2pa1_zH8TJotJvi-gsCJ6NJFFbeA@mail.gmail.com>
To: Dan Wing <danwing@gmail.com>
Cc: DNSOP WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e3e75005c6b3b600"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8GeBpc7o0Uudbt5Dk8cJbGzdHjg>
Subject: Re: [DNSOP] Structured Data for DNS Access Denied Error Page
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Jul 2021 17:01:08 -0000

On Fri, Jul 9, 2021 at 7:43 AM Dan Wing <danwing@gmail.com> wrote:

> We just published Structured Data for DNS Access Denied Error Page which
> defines computer-parsable error information for DNS filtering:
>
>    DNS clients using services which perform filtering may wish to
>    receive more information about such filtering and the reason for that
>    filtering.  To this end, Extended DNS Error Codes [RFC8914] provide
>    information about when different types of filtering have occurred,
>    and DNS Access Denied Error Page [I-D.reddy-dnsop-error-page]
>    provides a URI to give further information to the end-user about the
>    reasons for the filtering.  However, the latter draft assumes a
>    client with a user-interface that can display a web page to the end-
>    user, whereas many clients may in fact be "headless", i.e., acting on
>    behalf of other network elements; such clients can include DNS
>    forwarders and proxies.  Such clients cannot make use of a web-page
>    designed for presentation to an end-user, but may instead be able to
>    make use of structured data.  This draft provides a mechanism for
>    such clients to request and receive structured data from the URI
>    returned by the DNS Access Denied Error Page mechanism.
>

Thanks for posting this, Dan. Just as a matter of UX, this seems more
likely to
be usable than a web page because the client will want to ensure that the
user
is not confused into thinking that the error page contents are where they
wanted
to go. Structured data like this allows the client to provide the error in
its own
UI.

-Ekr


>    When a third party provides DNS filtering, there are deployments
>    where disclosing that third party to the host (which originated the
>    DNS query) is desirable but other deployments where such disclosure
>    is not desired.  For example, the IT organization might contract
>    filtering to a third party but want trouble-tickets from employees to
>    be handled by IT, rather than having employees interact directly with
>    the third party.  As another example, all the employees at a small
>    business or all the members of a household might be informed of the
>    third party so they can troubleshoot filtering with that third party
>    directly.
>
>
> Full document is at:
>
> https://datatracker.ietf.org/doc/html/draft-wing-dnsop-structured-dns-error-page-00.html
>
> -d
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>