Re: [Doh] Captive portals (was Re: suggested slides for IETF 104 on draft-reid-doh-operator)

Daniel Stenberg <> Fri, 15 March 2019 08:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 873061311E6 for <>; Fri, 15 Mar 2019 01:12:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8NSwxnlOL6lQ for <>; Fri, 15 Mar 2019 01:11:58 -0700 (PDT)
Received: from ( [IPv6:2a00:1a28:1200:9::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3E6101311DC for <>; Fri, 15 Mar 2019 01:11:58 -0700 (PDT)
Received: from (mail []) by (8.15.2/8.15.2/Debian-4) with ESMTPS id x2F8Brd1001512 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 Mar 2019 09:11:53 +0100
Received: from localhost (dast@localhost) by (8.15.2/8.15.2/Submit) with ESMTP id x2F8BqxY001502; Fri, 15 Mar 2019 09:11:52 +0100
X-Authentication-Warning: dast owned process doing -bs
Date: Fri, 15 Mar 2019 09:11:52 +0100 (CET)
From: Daniel Stenberg <>
To: Jim Reid <>
cc: Martin Thomson <>,
In-Reply-To: <>
Message-ID: <>
References: <> <> <>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
X-fromdanielhimself: yes
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="1129329158-732140084-1552637513=:5797"
Archived-At: <>
Subject: Re: [Doh] Captive portals (was Re: suggested slides for IETF 104 on draft-reid-doh-operator)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 Mar 2019 08:12:01 -0000

On Fri, 15 Mar 2019, Jim Reid wrote:

> Suppose a DoH client has already bootstrapped itself and knows the address 
> of its chosen DoH server. The device moves to a new net that has a captive 
> portal. Will the device try to speak DoH to that server’s address directly 
> instead of doing the captive portal dance?

Then we enter application specific territory. A hypothetical browser might for 
example first verify that it is "captive portal-less" before it activates DoH, 
and it might also feature a config entry that skips that waiting period (a 
wait that is annoying when you restart your browser and have N tabs you'd like 
to reload at once etc).

Yes, validating local resolvers (and others) have the same problem. Captive 
portals in general are a world of pain.

> Likewise, what happens what a DoH client is configured to only use DoH and 
> therefore never interacts with the network’s or captive portal’s por 53 
> resolver?

A browser set to *only* use DoH and never "native" will effectively be locked 
out from the network when it finds itself in a captive portal. (There's at 
least one Firefox bug on this.) Which proves that all pieces work as intended!

In those cases, some users have been known to fire up a *separate* browser to 
resolve the captive situation as then the DoH-using browser can come back to 
the living.