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

[Ben Schwartz <[e-mail]>]

On Thu, May 23, 2019 at 11:24 AM dagon <[e-mail]> 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. https://www.cafepress.com/nxdomain/8592477
>
> 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
> [e-mail]
> D970 6D9E E500 E877 B1E3  D3F8 5937 48DC 0FDC E717
>
> _______________________________________________
> Doh mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/doh
>