Configuring Private DNS via DHCP

At IETF 102 in Montréal, I presented some slides on DHCPv6 Private DNS Discovery at the DRIU BOF.

The talk was based on an Internet Draft that Willem Toorop and I worked on: DHCPv6 Options for private DNS Discovery. It provided a means to include an Authenticated Domain Name (ADN) for a nameserver to be used with DNS over TLS (DoT) or DNS over HTTPS (DoH).

To say that the talk was received poorly is an understatment...

Ted Lemon made a good argument that DHCP should only be used for boostrapping initial network parameters and not for full fledged configuration of all network parameters.

There was enough consensus that we feel that moving forward with this work would go against the wishes of the IETF community.

There still is a need for configuring the ADN in a trusted campus environment but a different proposal will need to be invented for this use case.

Overall, it was a good excercise and I hope that by documenting this here, it will discourage others from going down this path in the future.

Update

Ted Lemon's talk can be found here in the IETF Proceedings on YouTube at 33:18.

As Sarah Dickinson recently mentioned at DNS-OARC 27 in San Jose, CA, https://indico.dns-oarc.net/event/27/session/4/contribution/20, there is a work in progress for a TLS DNS Proxy for the Apple iPhone/iPad running iOS 11 and above. This uses the new DNS Proxy Network Extension and, when enabled, all DNS requests will be sent to a resolver over TLS.

I expect this new DNS Network Extension to be available for macOS in a future release as well.

Check back here in a bit to see the status and sign up for beta testing.

UPDATE:

After receiving the following message on the Console, it appears that the only way to use the new DNS Proxy Network Extension in iOS 11 is through Mobile Device Management (MDM) Tools as a supervised device. This makes it impossible to install for the average user through the App Store.

Therefore, I am suspending this effort until this extension is more useful to a wider audience.

Oct  5 17:29:26 iPhone nehelper(NetworkExtension)[99] <Error>: -[NEHelperConfigurationManager:562  Warning: allowing creation/modification of a DNS proxy configuration on non-supervised device because the requesting app (DNS-TLS) is a development version. This will not be allowed for the production version of DNS-TLS

UPDATE 2:

An Apple representative confirmed this is currently only for supervised devices but he seems to indicate they are considering opening this up to all devices but with no assurances or timeline:

I’ve just confirmed that, as things currently stand, NEDNSProxyProvider is limited to supervised devices.  We have a bug on file (r. 34843801) requesting that this restriction be lifted.  I suspect that this will happen but, as per usual, I can’t make any specific promises about that, or about the timeline for this change.  It certainly wouldn’t hurt for each of you to file your own bug describing your use case, how this restriction is affecting you, and what workarounds you’ve resorted to.

UPDATE 3:

I posted the sample code on github here:

https://github.com/pusateri/DNS-TLS

Overview

• nst is a new tool written in javascript node.js. It is a generic DNS name server test tool that can be used to test new DNS features in a server.

• A major goal is to be able to support testing of long-lived DNS connections in addition to simple query/response tests. Long-lived connections are used for DNS Privacy connection optimization, DNS Stateful Operations such as DNS Push Notifications, and service discovery with a discovery proxy and relay.

Overview

• sdtest is a client simulation tool for testing DNS subscriptions. It supports both the older Long Lived Queries (LLQ) and the new replacement DNS Push Notifications.

• Since it is a work in progress, the best way to follow it is to look at the github sdtest project documentation that is being updated as the code is written.

https://github.com/pusateri/sdtest

Lua style configuration

Most configuration can be provided in the delegating DNS server. discd queries this DNS server for subdomains and names to listen for. If you don't have full control over the delegating server, you can override or augment the configuration with a local config file.

There is a sample config file in $SYSCONFIDR/discd.lua. For Linux, this is /etc/discd.lua. For FreeBSD, it would be /usr/local/etc/discd.lua. Here, you can override the host and domain name as well as the subdomains for each interface. Some sample configuration is included below. While it might not be obvious, using a Lua language file for configuration provides a lot of flexibility for generating the variables to be read by the discd daemon.

hostname = 'foo.bar.com' -- only needed to override default
port = {
    -- defaults, not yet implemented
    udp = 53, tcp = 53, tls = 853, llq = 5352, push = 853
}
certificate = {
    -- looks for letsencrypt certs automatically in the default location by hostname
    crt = '/etc/letsenscrypt/live/foo.bar.com/cert.pem',
    key = '/etc/letsenscrypt/live/foo.bar.com/privkey.pem',
    chain = '/etc/letsenscrypt/live/foo.bar.com/fullchain.pem'
}
interfaces = {
    -- currently required if no reverse PTR net records
    { name = 'eth0', subdomain = 'sub1.bar.com' },
    { name = 'eth1', disable = true },
}

Disclaimer

LLQ and DNS Push Notifications are not fully implemented.