Subject: [Add] Comparative DoH Discovery DNS RR Types

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 29 Jun 2020 15:36:42 +0000

Just noting far we have a variety of suggestions on CNAME, URI, TXT, RESINFO and HTTPSSVC (though I don’t think all have I-Ds as yet) - always nice to see the ideas flowing. :-) As a practical person that in IETF land is considered an implementer, I naturally feel inclined towards RR types that already exist as this enables something to be rapidly deployed.

As all of these become documented a discussed a bit further - or even tested experimentally - my humble suggestion is that it may be helpful for the WG to develop a grid of all the options with their associated pros & cons.

Thanks
Jason

---

From: Paul Vixie <[email-masked]>
Date: Mon, 29 Jun 2020 21:01:49 +0000

On Monday, 29 June 2020 15:36:42 UTC Livingood, Jason wrote:
> Just noting far we have a variety of suggestions on CNAME, URI, TXT, RESINFO
> and HTTPSSVC (though I don’t think all have I-Ds as yet) - always nice to
> see the ideas flowing. :-) As a practical person that in IETF land is
> considered an implementer, I naturally feel inclined towards RR types that
> already exist as this enables something to be rapidly deployed.

the community apparently lacks coherence on the importance of rapid deployment 
as compared to the importance of technical excellence. if we're not going to 
add any more new RR types because they take ten years to become usable (see 
the SPF RR vs. the later _spf TXT RR), we should say that, and close the RR 
type registry, so as to avoid confusing newcomers.

if on the other hand we're going to continue to evolve DNS in ways that 
include adding new RR types, and all the initiators who are stuck behind 
dumbass middleboxes who reject or butcher unknown RR types are going to fail 
hard and be excluded from the new applications and protocols in order to put 
more pressure on middlebox users/makers/distributors, we should say that.

either way, nothing is temporary. whatever we use for resolver discovery will 
be present as a data pattern and code path in all future software. improved 
signal patterns and associated logic will live alongside the unimproved ones, 
raising the bar for both short-term expedients and later improvement to be 
"worthy of its coexistence cost". for clarity, that's a _very_ high bar.
 
> As all of these become documented a discussed a bit further - or even tested
> experimentally - my humble suggestion is that it may be helpful for the WG
> to develop a grid of all the options with their associated pros & cons.

such grid would be well informed by the attached graphic.

-- 
Paul

---

From: Adam Roach <[email-masked]>
Date: Mon, 29 Jun 2020 16:38:20 -0500

> more pressure on middlebox users/makers/distributors, we should say that.

Perhaps it would be worthwhile for the DNS community to consider putting 
together concrete guidance for middleboxes, similar to what 
https://datatracker.ietf.org/wg/straw/about/ did for SIP. I suggest 
follow-ups on this topic are probably more on-charter for DNSOP than ADD.

/a

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 29 Jun 2020 15:22:23 -0700

> On Jun 29, 2020, at 2:01 PM, Paul Vixie <[email-masked]> wrote:
> 

Agreed on both points.

To that end, one of the reasons I like using HTTPS RR (aka HTTPSSVC) for the ADD information is that this RR type, while new, is tied directly to the deployment of TLS Encrypted Client Hello (ECH). Improving the privacy of names on a network requires, ultimately, both encrypted DNS *and* encrypted SNIs in the client hello.

Of course, a client could only expect to do ECH when it already has encrypted DNS set up, but I’d prefer that the architecture not design for that case. We should have a system that allows to discover local encrypted resolver support, and even do ECH to hosts private to a local-network. There will indeed be networks or middle boxes that butcher this, but they also could be butchering other aspects that would stop the local network from upgrading from Do53 to DoT/DoH.

Tommy

> Paul-- 
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Jun 2020 19:57:49 -0400

> either way, nothing is temporary. whatever we use for resolver

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.

I was among the first who did that back in 2002, and it wasn't that hard.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Daniel Migault <[email-masked]>
Date: Mon, 29 Jun 2020 21:14:11 -0400

I agree that new RRtypes can be added but I am not convinced we need new
ones for the discovery. What is unclear to me is the use of  HTTPS as
opposed to SVCB for the DNS optionally over HTTP and most of the time over
TLS. I have the feeling that alpn could be used to determine HTTP.

That said RRtype are one aspect but I believe that we should also
agree/discuss what we expect from the discovery. Here are my thoughts on
what the discovery should achieve:

   REQ 1: DRDP MUST enable a DNS client to discover the available
   resolving services with their associated characteristics in order to
   proceed to a selection process.  The selection process takes
   resolving services identities and associated parameters and proceeds
   to the selection.
   Any sort of resolving service selection is outside the scope of DRDP.

   REQ 2: While the discovery process is triggered by the DNS client, a
   third party MUST be able to provide necessary input information so a
   resolving service discovery process can be triggered within a
   specific context.
   Provisioning protocols to provide this information is not as per say
   in scope of DRDP.  DRDP defines the format of the format for such
   input as well as a set of such inputs.

   REQ 3: Any information used in DRDP MUST be authenticated by its
   owner.  In particular, the characteristics associated to the
   resolving service MUST be certified by the resolving service operator
   / owner and MUST be associated a validity period.  In addition, a
   third party providing a set of inputs MUST authenticate that set.

   REQ 4: Information associated to the resolving services is intended
   to enable the selection process that is assumed to match the end user
   or application policy.  The selection process is out of scope of
   DRDP.  Information may carry some characteristics of a resolving
   service or hints that will help the selection.  In particular an
   operator of multiple resolving service MUST be able to associate a
   preference to the proposed resolving services.  To ease automation of
   the selection as well as to make multiple applications benefit from
   DRDP the information MUST be carried over a standardized format.

   REQ 5: DRDP MUST be designed to be used indifferently by a DNS client
   using any DNS transport protocol (Do53, DoT, DoH, ...).  However,
   DRDP SHOULD be able to restrict the information retrieved to a
   certain type of resolving service, i.e. Do53, DoT, DoH.

   REQ 6: DRDP deployment MUST NOT be disruptive for the legacy DNS
   client or infrastructure and legacy client SHOULD be able to
   incrementally include DRDP.

[1] https://datatracker.ietf.org/doc/draft-mglt-add-rdp/

Yours,
Daniel

-- 
Daniel Migault
Ericsson

---

From: Christian Huitema <[email-masked]>
Date: Mon, 29 Jun 2020 19:14:36 -0700

> are usually put there intentionally, and they deserve what they get.

I heard EKR make two arguments for using CNAME: not just middlebox
compatibility, but also software simplicity. The latter is interesting,
and might be worth explaining a bit. The way I understand it, Mozilla
would rather use a well known API like getaddrinfo(), rather than a more
capable API that supports different record types. I can guess that this
is a software simplicity/complexity trade-off. I suppose that the more
capable API tend to be implemented slightly differently on different
OSes, which leads to more complex code with a variety of #ifdef to
accommodate the different platform, more tests, and probably more bugs.
But I may be getting it wrong, and I would rather hear what Mozilla
actually thinks...

-- Christian Huitema

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 30 Jun 2020 12:25:05 +1000

> But I may be getting it wrong, and I would rather hear what Mozilla

I'm not super close to this, but my understanding is that we now have two resolution paths: one native and one for DoH.  On the DoH path, we have greater ability to manage new RRtypes and queries.  However, this specific case cannot follow that path.  As this has to be cross-platform, there is a non-trivial amount of plumbing required to support doing anything other than the getaddrinfo() call.  Our abstractions are pretty old and have never had to grow the ability grow features like the ability to handle new RRtypes.  In other words, Christian, your guess is spot on.

As this is (currently) driven by a need for expediency, and CNAME works, it wasn't worth investing a whole lot of effort in finding something better, especially when it is clear that the matter was not settled.  If presented with an IETF consensus position on the topic, that would likely be a different story.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 30 Jun 2020 02:25:45 +0000

On Tuesday, 30 June 2020 02:14:36 UTC Christian Huitema wrote:
> ... The way I understand it, Mozilla
> is a software simplicity/complexity trade-off.

i don't like seeing evidence that the getdnsapi.net people wasted a decade 
building something that ended up being too complicated to go into the MPR.

in case it's not obvious: i do not think we should make "forever" decisions 
based on what programming language or system library happens to be convenient 
at this decade. (nor upon what dumbass middleboxes we're often stuck behind.)

> ...

i hope you're getting it wrong too, because then i would be getting it wrong, 
since i understood the mozilla corporation's comments here the same way you 
describe.

-- 
Paul

---

From: Rob Sayre <[email-masked]>
Date: Mon, 29 Jun 2020 20:34:04 -0700

On Mon, Jun 29, 2020 at 8:37 AM Livingood, Jason <
[email-masked]> wrote:

> Just noting far we have a variety of suggestions on CNAME, URI, TXT,
> RESINFO and HTTPSSVC (though I don’t think all have I-Ds as yet) - always
> nice to see the ideas flowing. :-) As a practical person that in IETF land
> is considered an implementer, I naturally feel inclined towards RR types
> that already exist as this enables something to be rapidly deployed.
>

TXT was used for ESNI/ECH draft -02. It only took ten or twelve lines of
code to get the value out of a DNS response, but it felt hacky, in the
pejorative sense.

It seemed unlikely that a large number of server implementations would
encode the data in the same way.

thanks,
Rob

---

From: dagon <[email-masked]>
Date: Tue, 30 Jun 2020 06:02:23 +0000

> 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.

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
[email-masked]
D970 6D9E E500 E877 B1E3  D3F8 5937 48DC 0FDC E717

---

From: tirumal reddy <[email-masked]>
Date: Tue, 30 Jun 2020 16:39:57 +0530

> 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.

---

From: tirumal reddy <[email-masked]>
Date: Tue, 30 Jun 2020 16:45:41 +0530

> code to get the value out of a DNS response, but it felt hacky, in the

TXT has been misused by malware to exfiltrate data and to send C&C traffic.

-Tiru

---

From: Paul Wouters <[email-masked]>
Date: Tue, 30 Jun 2020 01:09:21 -0400 (EDT)

On Tue, 30 Jun 2020, Martin Thomson wrote:

> I'm not super close to this, but my understanding is that we now have two resolution paths: one native and one for DoH.

That would be unfortunate if true. Making the resolving code and results
different based on the _transport_ of the same DNS data is asking for a
lot of complicated bug reports and confused users.

Imagine needing to tell your users for some websites you need to enable
DoH and for some websites you need to disable DoH.....

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 29 Jun 2020 20:34:46 -0400 (EDT)

> more pressure on middlebox users/makers/distributors, we should say that.

I fully agree with Paul V here, but I do want to point out that in this
case, we _might_ want an exception to this because this is a mechanism
to find and get to a well working modern DNS resolver. We are specifically
using some crappy old hotspot technology DNS to gain access to proper
DNS.

For everything else, I agree to just do the RRTYPE. And once we have
the mechanism to get to a proper modern DNS resolver, never come to IETF
again with proposals that hack or overload existing RRTYPEs.

And even in this case, perhaps we should insist on defining both, so we
can kill the hack in 10-15 years.

Paul