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

[dagon <[e-mail]>]

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.

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