Re: [Doh] Maybe moving draft-ietf-doh-resolver-associated-doh to draft-sah-resolver-information

Ben Schwartz <> Thu, 23 May 2019 15:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D796B120072 for <>; Thu, 23 May 2019 08:54:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.51
X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gnk0ysC846Wc for <>; Thu, 23 May 2019 08:54:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2CA7D120125 for <>; Thu, 23 May 2019 08:54:20 -0700 (PDT)
Received: by with SMTP id k187so3871150vsk.12 for <>; Thu, 23 May 2019 08:54:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=naM1gEnodMcta8VlSvN+hueE5c88J8lPyOuG7sZ09Es=; b=Ir22rgpwR+Dsp9hCSt08lO8pbNWjxZRnR0eNG835vTAsLmc7/OjdiQpAk2b4IKLu/u 94ofqT8uAEXjicUAYgCNsmrglDHcTs95t67yjo6DPLSWdibvJY9Hw3rD2W5/G28n5K4w Bo90+fkR8RLZQ/ZJZ5jn6K+uy+Hjyxgd0ZjGspg5qLLvn3uiQAcLg2WaA9fZT5nfZ8mU mHqjzAEv3Gkjwu1dCifubEa0iH+fY8Hxx6iIykdZcgsW8oVDrPNEYB66ugmYQD99EZt8 DeliCAkROTkbWeEEu22kI8Z3+kOOci5OjJl6pa7zMwAkoRRRDF9sv2anYhwjdLqn2L4k xFng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=naM1gEnodMcta8VlSvN+hueE5c88J8lPyOuG7sZ09Es=; b=c6RxRTYkH9g8xFiJUvbWDzTeArvUOo+GdFMY6bqoHvtw4NWQuuDSJPiZqnTC9dfzCe nMD2x8CtdwLkXuM45FjGDeHIyAjyF2T0F4M5SZmNqNWRPEl0CvE6ZaDlUlNr7ISxmDZg N1LTRPO8lh6URTBiH7XFQD2DrbKSGslMoS4zCC8OZDSeKmySS7pc9aYvZyf/BdnwR5z0 rKNA8pYxOe2Vs9FUnpTxUQI0lpW+78DzCQzCSEBTTOwBGnhnxzhzHNrQxRGs5pCUmm5O WFXSE9yGfth4wVtJGxmN+WPPm3V9+tS38+w2ffioRtk3cr6GWkp/Db7piU2C13GcCcZ9 jbyA==
X-Gm-Message-State: APjAAAVhBjOHqWxhtNAKRTi/WQGfBftznzC/0cW9XPK+pBALOHIFQtBS 4HWJqb4m2pe3Zkogap6ZeKMaOuQ7KOYA2ki+DjzWVQ==
X-Google-Smtp-Source: APXvYqxsXAfp5Y0LY7qxLKadZxbjPp8hvnBMKuYgx6hVmx2nn51paCP4u1qye1tFZHur05tiQcr/2tgkub2pTXsXfSk=
X-Received: by 2002:a67:ca9a:: with SMTP id a26mr19401685vsl.92.1558626858816; Thu, 23 May 2019 08:54:18 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Thu, 23 May 2019 11:54:07 -0400
Message-ID: <>
To: dagon <>
Cc: Paul Hoffman <>, doh WG <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000049e8fb0589901869"
Archived-At: <>
Subject: Re: [Doh] Maybe moving draft-ietf-doh-resolver-associated-doh to draft-sah-resolver-information
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: Thu, 23 May 2019 15:54:25 -0000

On Thu, May 23, 2019 at 11:24 AM dagon <> wrote:

> On Wed, May 22, 2019 at 10:49:45PM +0000, Paul Hoffman wrote:
> > Greetings again. For those in the DOH WG who are not also in the
> > DNSOP WG, you may not have seen that Puneet Sood, Roy Arends and I
> > have new drafts that would replace
> > draft-ietf-doh-resolver-associated-doh. During IETF 104, and on this
> > list, people asked why the mechanisms in
> > draft-ietf-doh-resolver-associated-doh were only for DoH. In
> > response, we created draft-sah-resolver-information and
> > draft-sah-resinfo-doh. The former is a general way of asking
> > resolvers for information about them; the latter is the definition
> > of the DoH-related information.
> One comment on draft-sah-resinfo-doh:
> Compare the use of a new RRType, ${SUDN}.arpa/IN/RESINFO, which yields
> a structured set of I-JSON fields, to a simple ${SUDN}.arpa/IN/A
> approach, with merely returns a record pointing to an appropriate
> server with resolver policy statements, perhaps on a web site or yaml
> ("This recursive blocks malware and ads, and per corporate policy all
> resolution must be local. Resolve elsewhere at your professional
> peril.  This is an M&A audit requirement."), and/or other meta data
> useful to the stub's DNS path choices.
> There are many advantages to RESINFO beyond well structured data,
> including identifying/addressing stray ${SUDN}.arpa queries seen just
> above-the-recursive by local operators (REFUSED, etc?).  And the
> networks who wish to block DOH will likely trigger on
> ${SUDN}.arpa/IN/RESINFO?  queries, for captive portal education,
> whereas triggering on SUDN IN/A? for DOH identification would have too
> many false positives induced by DNS prefetching.  (Aside: This was yet
> another global DNS accommodation for browsers, btw.)
> Although IN/RESINFO is the correct approach, compared to IN/A, I've
> been recently alerted to one potential draw back to a new RRType: some
> of the meta data one hopes to expose (e.g., filtration policy) might
> be easier to add or edit out-of-zone.
> That is, the simple ${SUDN}.arpa/IN/A approach points to a web site,
> which any summer intern in the legal department can edit (after the
> DNS operators add their rrset and close the ticket).  In contrast,
> ${SUDN}.arpa/IN/RESINFO seems to inhere more extensive, or ongoing +w
> access to a recursive config, with potentially significant impacts for
> DOH users in the case of accidents.  This is fine for just DOH URI
> fields, which don't change often.  But other data, not generated by
> the DNS operator teams, will prove less agile.
> Without existing appliance support for editing (and not merely rfc3597
> sane passing) of a novel RRType, adoption might be slow, since the DNS
> operators in organizations become entrained in the output of other
> groups.  Many organizations affected by DOH (e.g., banks, mid-sized
> and larger corps, ISPs) already have clear delineations in groups
> around security, DNS, network operations, customer care, policy and
> public statements.  Since draft-sah-resolver-information is designed
> to have more than just DOH URIs (and potentially could include policy
> details relevant to DOH pathing decisions), this seems important.

It seems like any such policy information could be referenced by URL in a
RESINFO RR, to support easy editing and separation of access controls.
Would a design of that sort address your concerns?

Had I realized this years ago, IN/RESINFO still would be the obvious
> choice compared to IN/A, since well structured fields encourage app
> developers to poll ${SUDN}.arpa for discrete information.  But the
> existing DOH deployment suggests speeding RESINFO uptake/adoption.
> Perhaps also supporting IN/A discovery of DNS filtration policy data
> could be useful.
> DNS appliance vendors would support IN/RESINFO of course, some quickly,
> some eventually.  But IN/A could be done today on existing installs.
> Perhaps a billion+ people have DOH available (currently off), and some
> are using it to start small office fires.  Exposing LAN policy to the
> apps quickly would help.  And it would discipline the anti-malware DNS
> filtration industry around transparency-to-the-stub.  (We can expect
> other DNS-abusive censors to continue to provide few or misleading
> details, which the browsers might well ignore as likely L8 imposed
> firewalls.)
> >  Both Google and Mozilla have said here that they look forward to a
> > way to find the DoH server associated with a user's resolver, so we
> > hope that the work can move forward at a reasonable pace. However,
> > if people in this WG think we're doing it wrong by having a general
> > mechanism for querying resolvers, please speak up here.
> Since users are already turning on DOH, there's urgency in exposing
> network policy information to apps.  Not just the DOH URI, but the
> imperative some networks see in DNS anti-malware filtering, as they
> now shop for PACs/TLS interception solutions, post-DOH.
> If you're revising draft-sah-resolver-information, could it support
> both A and RESINFO?  (The former for rapid uptake/captive portal use
> and avoiding portal triggering, the latter for standardized app
> integration, once DNS appliances support federated editing.)  Or
> anything just short of overloading TXT records once again?
> Cf.
> Or have I missed something making IN/RESINFO the exclusive solution
> and not merely superior to IN/A?
> I do like the general compass direction of
> draft-sah-resolver-information: telling users about recursive DNS
> settings and policy is wonderful.  This informs user consent and
> alternative resolution path choices.  My thanks to the authors
> for drafting their solution.
> --
> David Dagon
> D970 6D9E E500 E877 B1E3  D3F8 5937 48DC 0FDC E717
> _______________________________________________
> Doh mailing list