Re: [dns-privacy] DPRIVE client with captive portal

John Heidemann <johnh@isi.edu> Mon, 08 August 2016 20:29 UTC

Return-Path: <johnh@isi.edu>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7638512D134 for <dns-privacy@ietfa.amsl.com>; Mon, 8 Aug 2016 13:29:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.147
X-Spam-Level:
X-Spam-Status: No, score=-8.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no
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 vcSQXkU84DJx for <dns-privacy@ietfa.amsl.com>; Mon, 8 Aug 2016 13:29:22 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 6404712B049 for <dns-privacy@ietf.org>; Mon, 8 Aug 2016 13:29:22 -0700 (PDT)
Received: from dash.isi.edu (vir.isi.edu [128.9.160.91]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u78KTCX5008982; Mon, 8 Aug 2016 13:29:12 -0700 (PDT)
Received: from dash.isi.edu (localhost6.localdomain6 [IPv6:::1]) by dash.isi.edu (Postfix) with ESMTP id 92844280098; Mon, 8 Aug 2016 13:29:11 -0700 (PDT)
From: John Heidemann <johnh@isi.edu>
To: Dan Wing <dwing@cisco.com>
In-reply-to: <ED71C48A-26C7-438D-859C-521122136606@cisco.com>
References: <ED71C48A-26C7-438D-859C-521122136606@cisco.com>
X-url: http://www.isi.edu/~johnh/
MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Date: Mon, 08 Aug 2016 13:29:11 -0700
Message-ID: <26953.1470688151@dash.isi.edu>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: johnh@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/OsTVZGdLy2JwnemF2pa-tI5R5DA>
Cc: dns-privacy <dns-privacy@ietf.org>
Subject: Re: [dns-privacy] DPRIVE client with captive portal
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Aug 2016 20:29:23 -0000

On Mon, 08 Aug 2016 10:49:17 -0700, =?utf-8?Q?=F0=9F=94=93Dan_Wing?= wrote: 
>Are there documented procedures for how a DPRIVE client handles joining a network with a captive portal, or other filtering, which prevents accessing the DPRIVE DNS server?

Yes.  From RFC-7858 section 4.2:

   However, a configured DNS server may be temporarily unavailable when
   configuring a network.  For example, for clients on networks that
   require authentication through web-based login, such authentication
   may rely on DNS interception and spoofing.  Techniques such as those
   used by DNSSEC-trigger [DNSSEC-TRIGGER] MAY be used during network
   configuration, with the intent to transition to the designated DNS
   provider after authentication.  The user MUST be alerted whenever
   possible that the DNS is not private during such bootstrap.

   -John Heidemann