Re: [dns-privacy] Operating System API support for DNS security policy

[Bob Harold <[e-mail]>]

On Mon, Aug 19, 2019 at 1:29 PM Tommy Jensen <Jensen.Thomas=
[e-mail]> wrote:

> Hey Iain,
>
> Iain> Many applications rely on operating system APIs to access DNS
> services. As native support of DNS over TLS rolls out in to operating
> systems it seems likely that some applications will wish to control the
> security policy that the operating system applies when it performs DNS
> resolution. For example, the application may wish to require that the
> operating system uses an encrypted DNS protocol.
>
> I actually don't see this being necessary. Walking through the
> possibilities:
>
>    - If the OS supports DoT and the configured servers support it:
>       - OS should be using DoT whether the app requests it or not
>    - If the OS supports DoT but the servers don't:
>       - App intent isn't helpful (to the same server)
>    - If the OS doesn't support it:
>       - App intent isn't helpful
>
> I read this differently - the api needs to tell the app whether the OS
does encrypted DNS:

   - OS supports DoT and can connect to a DoT resolver
      - App uses OS for DNS
   - OS does not support DoT
      - App connects to a DoT server itself, bypassing the OS  (even though
      I dislike this, unless the user has agreed)
   - OS supports DoT but cannot reach a DoT server
      - various choices, we don't need to discuss this now.

-- 
Bob Harold


>
>
> My view is that the OS should be taking the most secure DNS route it has
> available regardless of app request (after all, think of all the apps which
> won't request DoT but should). In the case where the OS supports DoT but
> isn't using it, that decision is being made in the context of other
> information, such as enterprise configuration, that the app may not have.
>
> Iain> Unless operating systems support secure DNS standards and expose
> APIs to allow applications to use them effectively then applications that
> require secure DNS have little choice other than to roll their own
> implementations.
>
> I totally agree. Platforms should be providing the network tools apps need
> so all apps can benefit similarly, rather than leaving apps to figure out
> networking nuance on their own. I just think in this case that there should
> never have to be a situation where an app needs to request DNS encryption
> (because either it's already happening or it can't happen for some reason
> unknown to the app).
>
> Summary: I think such an API should be unnecessary on well-behaved
> platforms.
>
> Thanks,
> Tommy
> ------------------------------
> *From:* dns-privacy <[e-mail]> on behalf of Iain
> Sharp <[e-mail]>
> *Sent:* Monday, August 19, 2019 2:56 AM
> *To:* [e-mail] <[e-mail]>
> *Subject:* [dns-privacy] Operating System API support for DNS security
> policy
>
>
> All,
>
>
>
> DNS over TLS offers the ability to perform DNS queries over a TLS secured
> channel. In my understanding, DNS over TLS is not yet available in all
> operating systems, but operating system support could become common in
> future.
>
>
>
> Many applications rely on operating system APIs to access DNS services. As
> native support of DNS over TLS rolls out in to operating systems it seems
> likely that some applications will wish to control the security policy that
> the operating system applies when it performs DNS resolution. For example,
> the application may wish to require that the operating system uses an
> encrypted DNS protocol.
>
>
>
> Today, most operating systems use the getaddrinfo() function described in
> RFC3493 as the basis of their API for translating DNS names to IP
> addresses, but this does not have security policy attributes.. Is anyone
> aware of any activity to enhance the RFC3493 work to add application
> control of security policy to the getaddrinfo()  capabilities?
>
>
>
> Unless operating systems support secure DNS standards and expose APIs to
> allow applications to use them effectively then applications that require
> secure DNS have little choice other than to roll their own implementations.
>
>
>
>
>
> Thanks
>
>
>
> Iain
>