On Mon, Aug 19, 2019 at 1:29 PM Tommy Jensen <Jensen.Thomas=
[email protected]> 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 <[email protected]> on behalf of Iain
> Sharp <[email protected]>
> *Sent:* Monday, August 19, 2019 2:56 AM
> *To:* [email protected] <[email protected]>
> *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
>
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
