Re: [Add] Comparative DoH Discovery DNS RR Types

On Tue, 30 Jun 2020 at 11:32, dagon <dagon@sudo.sh> wrote:

> On Mon, Jun 29, 2020 at 07:57:49PM -0400, Michael Richardson wrote:
>
> > I'm with Paul. I prefer creating new RR types.
> > There aren't that many dumbass middleboxes around, and those that are
> there,
> > are usually put there intentionally, and they deserve what they get.
>
> +1
>
> Middleware ignoring RFC 3597 has a privacy benefit: it won't leak the
> local DNS discovery details.  A marginal DNS appliance, unable to
> process RESINFO and other inherently local, policy-based novel types,
> won't pass such traffic to 3d parties.
>

The BCP document https://tools.ietf.org/html/bcp152#section-4.3 says DNS
forwarders on home routers MUST proxy unknown RR types.

>
> E.g., ancient Cisco PIX will drop IN RESINFO?, failing the user back
> to udp/53.  But such middleware could pass TXT-based discovery,
> sharing the local DoH policies.  It also announces to the outside "oh
> look, someone just started a browser".
>
> Further, firewall operators must parse and ponder the global vs. local
> significance of such TXT records.  Their solutions won't be
> consistent, creating a new generation of quirked gear.  Could the
> draft (perhaps off the ADD list) provide advice for transit, firewalls
> and middleware witnessing such local discovery?  Silently drop? ICMP?
> SERVFAIL?
>
> This is in contrast to DNSSEC, often dropped by broken middleware.
> DNSSEC conversations generally have global and e2e utility, since each
> hop and even appliances can validate.  DoH discovery is local, and
> best dropped by non-speakers.
>
> --
> David Dagon
> dagon@sudo.sh
> D970 6D9E E500 E877 B1E3  D3F8 5937 48DC 0FDC E717
>
> --
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>