Subject: [Add] List of ADD?

From: David Huberman <[email-masked]>
Date: Sun, 7 Jul 2019 14:44:38 +0000

Hello,

I was giving a presentation this past week on "What's Going on in the World of DNS?" to 
an audience of network operators and government technical policy makers.  One of the 
questions I got from the audience was about current implementations of ADD.  Other 
than Firefox and Chrome, I wasn't able to point the questioner to any other applications 
publicly doing RFC 8484 DoH; there is also some malware using the non-standard 
Google API for DNS-over-HTTPS.

Have any applications or OSes publicly committed to DoT? Does anyone know of any other 
application makers publicly talking about ADD that they could please share here on-list?

Thank you!
David

David Huberman
Senior Technical Engagement Specialist
Office of the CTO
ICANN
M: +1-571-342-2267
E: [email-masked]

---

From: Joe Abley <[email-masked]>
Date: Sun, 7 Jul 2019 11:06:22 -0400

Hi David,

> application makers publicly talking about ADD that they could please share here on-list?

Do you want to answer the question of what applications are doing DNS, or to the questions of what applications are doing DNS with specific transports? Both are interesting, I think, but usefully separate.

Netflix apps and chrome key devices are examples of applications that are doing DNS that people have mentioned to me, recently. I don't know what transport they are using (I don't use either and haven't had a chance to look myself).

There are several applications that do DoT specifically for the purpose of allowing the user to select particular transports; Sinodun's stubby is an easy example. But that doesn't seem like what you're looking for.

Joe

---

From: nusenu <[email-masked]>
Date: Sun, 07 Jul 2019 15:11:00 +0000

David Huberman:
> I was giving a presentation this past week on "What's Going on in the
> World of DNS?" to an audience of network operators and government
> technical policy makers.  One of the questions I got from the
> audience was about current implementations of ADD.  Other than
> Firefox and Chrome, I wasn't able to point the questioner to any
> other applications publicly doing RFC 8484 DoH;

You might find these two pages of use:

https://github.com/curl/curl/wiki/DNS-over-HTTPS#supported-in-browsers-and-clients
https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implementation+Status

dnscrypt-proxy also implementing DoH, has multiple frontend applications but are
also probably not "applications" in the sense of "ADD".
https://dnscrypt.info/implementations
 
> Have any applications or OSes publicly committed to DoT? 

Android 9 has DoT support.
systemd has a first version of DoT without the strict profile,
but Android and systemd are not really "applications" in the sense of ADD
I guess.

-- 
https://twitter.com/nusenu_

---

From: Wes Hardaker <[email-masked]>
Date: Sun, 07 Jul 2019 14:35:46 -0700

David Huberman <[email-masked]> writes:

> there is also some malware using the non-standard Google API for
> DNS-over-HTTPS.

They've started using real DOH too, at least based on:

https://www.zdnet.com/article/first-ever-malware-strain-spotted-abusing-new-doh-dns-over-https-protocol/

(which even references RFC8484)

-- 
Wes Hardaker
USC/ISI

---

From: nusenu <[email-masked]>
Date: Sun, 07 Jul 2019 21:51:00 +0000

> (which even references RFC8484)

It doesn't really matter that much but people pointed out
that this specific malware did not speak DoH as in RFC8484

https://twitter.com/bagder/status/1146740062127886338

---

From: "Mark Delany" <[email-masked]>
Date: 7 Jul 2019 21:54:00 +0000

On 07Jul19, David Huberman allegedly wrote:

> application makers publicly talking about ADD that they could please share here on-list????

Where you being specific about "applications and OSes" as that seems to be a narrower question than
one which might identify growing popularity (or risk by the sounds of your target audience)?

For example, did you want to include resolver libraries, resolvers and middle-ware boxes that can
use ADD on their upstream side as they effectively "cause" ADD use by many applications?

Mark.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 7 Jul 2019 21:54:14 +0000

> (which even references RFC8484)

Nope. The writer of the article apparently didn't even read the reference that the article gives to the Qihoo 360 analysis; that clearly shows the query and response are using the pre-8484 Google API, not RFC 8484.

Again: DNS-over-HTTPS has been possible for long before RFC 8484, and there are many ways to do it that don't conform to the standard.

--Paul Hoffman

---

From: Jim Reid <[email-masked]>
Date: Sun, 7 Jul 2019 23:14:12 +0100

> On 7 Jul 2019, at 22:35, Wes Hardaker <[email-masked]> wrote:
> 
> They've started using real DOH too

FWIW a (proof of concept) DoH based exfiltration attack was done at the end of last year:
https://sensepost.com/blog/2018/waiting-for-godoh

---

From: "Ralf Weber" <[email-masked]>
Date: Mon, 08 Jul 2019 00:26:10 +0200

Moin!

On 7 Jul 2019, at 23:54, Paul Hoffman wrote:

> Nope. The writer of the article apparently didn't even read the 
> reference that the article gives to the Qihoo 360 analysis; that 
> clearly shows the query and response are using the pre-8484 Google 
> API, not RFC 8484.
Well it still shows the danger of an publicly available infrastructure 
for name resolution that hides in other traffic and therefore is hard to 
block.

> Again: DNS-over-HTTPS has been possible for long before RFC 8484, and 
> there are many ways to do it that don't conform to the standard.
While this is true, having a standard encourages large players to have 
such an infrastructure as we see now. This is a real problem for 
enterprises and everybody that uses DNS to deliver a service, which is 
why we have to make sure that these publicly available large 
infrastructures are deployed in a sensible way both from the services 
and client side, as otherwise the bad guys will use this infrastructure 
for bad stuff.

As you note there has been other ways to evade the network name 
resolution before (VPNs, public DNS, proxies), but they either had a 
small number of targets, or a traffic/port pattern that was easy to 
block. The fact that Google has a publicly available DNS resolution 
system on their main website and this is used by malware clearly shows 
the danger of it. The same problem would arise if someone offered 
RFC8484 on the same host that runs a popular website, which is why we 
need to discuss the deployment of it.

So long
-Ralf
—--
Ralf Weber

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 7 Jul 2019 22:49:06 +0000

Small factual correction:

On Jul 7, 2019, at 3:26 PM, Ralf Weber <[email-masked]> wrote:
> 
> The fact that Google has a publicly available DNS resolution system on their main website and this is used by malware clearly shows the danger of it.

The analysis given in the Qihoo 360 description of this malware clearly shows that the DNS resolver was Cloudflare, not Google.

--Paul Hoffman

---

From: David Huberman <[email-masked]>
Date: Tue, 9 Jul 2019 22:51:24 +0000

Hello,

Thank you to Joe and nusenu for the helpful replies!

Joe wrote:

> Do you want to answer the question of what applications are doing DNS,
> or to the questions of what applications are doing DNS with specific transports?
> Both are interesting, I think, but usefully separate.
  
Both, and I agree they're separate and interesting.  When I talk about ADD to
operators or to technically-inclined policy makers, I'm describing the overall
playing field of ADD. OSes configured to use DoT are interesting, and the people
I'm engaging with right now want to know who they are. They also want to know
what other applications (apart from Firefox and Chrome) are using DoH.

>From Joe and nusenu's reply, what I'm seeing includes:
Netflix apps
Bromite
curl
... and a burgeoning toolset that software developers can use to implement ADD

On the OS side, there are some Linux implementations using systemd that implement
DoT.  I don't know what other OSes are currently supporting, or imminently plan to
support, DoT.  I'd love to hear of any!

Thanks!
/david