DNS Update Proxy

I recently published a new internet-draft: DNS Update Proxy for mDNS that describes a way to do campus wide service discovery as an alternative to the Discovery Proxy and mDNS Discovery Relay.

The main difference is that instead of delegating subdomains for each IP subnet and translating unicast queries into multicast queries, it pre-populates the unicast authoritative DNS server with all the services it can discover using DNS Update from a proxy listening to multicast DNS.

This allows faster responses and support for DNSSEC with full NSEC next record semantics.

I'm looking for feedback and will also be working on code at the Hackathon @ IETF104 in Prague. Send me a note if you want to work on this MIT licensed code. No Rust knowledge necessary.

Here's a link to the code https://github.com/pusateri/rupdateproxy

DNS Authoritative server lease lifetimes

Tim Wattenberg and I recently published a new internet-draft: DNS TIMEOUT Resource Record that provides a mechanism for authoritative DNS servers to save a lifetime for other resource records in the same zone.

Lifetimes are sometimes associated with records based on the source of the record. DHCP based address assignments have a lease lifetime as well as DHCPv6 prefix delegation. Service Discovery DNS UPDATE registrations use an EDNS(0) Lease Lifetime Option to attach a lifetime to the services being registered.

If you have other uses for TIMEOUT resource records, let me know!

In July of 2018, I gave a talk about thoughts on the future work of the DNS-SD working group. You can watch the recording here starting at 02:13:25.

Here are the slides:

What's the best programming language for DNS?

Everytime I get ready to start a new project, I struggle with what language to write it in. Lately, I've been writing a lot of prototype DNS features. The development environment is becoming more and more important to me. In the past, I've used the standard vim/gcc/gdb/ctags/id-utils tools. This still works but after having experimented with other languages, I realize this is outdated. After using Xcode on macOS for iPhone/iPad development, I've come to really appreciate Xcode for the speed of the edit/compile/debug cycle. But available libraries and language features in C are still a problem and Objective-C isn't portable.

I've tried some interpreted languages like python and ruby but they don't seem to be suited for high performance, scalable network server software and debugging them is not easy.

After using Xcode and the LLVM based tools, I really love the speed of LLVM based solutions and all of the advantages they bring like the static analyzer and optimizations that can be made at compile time with memory efficiency, strict typing, and debugging. Therefore, I decided to only look at LLVM based solutions. Sorry Golang. Sorry Node.js.

Also, I'm starting to like features introduced in many of the functional programming languages like promises or futures, async/await, and observables (see here).

Based on this criteria, I've found two possibilities:

1. Swift
2. Rust

So next, I started looking for DNS libraries so I didn't have to re-invent the wheel. I had recently contributed quite a bit to the Node.js dns-packet javascript library and redoing all of the low-level work so I could get to the work I really wanted to do isn't an attractive option.

There's a scattering of Swift DNS code around but nothing low level or comprehensive. But Rust has what seems to be a very exciting option:

https://github.com/bluejekyll/trust-dns

This work is broken down into a bunch of smaller Rust Crates, see here.

So if you're a DNS Rust developer and you want to collaborate, let me know!

I am going to see how much I can integrate Rust into Xcode 10.0 and would love some help.

Update

This dns-parser crate seems pretty good so far. When programming custom DNS applications, I find it simpler to work with.

Update 2

The answer is NLnetLabs. What was the question? Oh yeah, what is the best DNS library I've found so far for Rust? domain and the crate is here: crate.

Well-known DNS Server Reputation Service

While preparing for a talk I gave at IETF 102 in Montréal, I had an idea about establishing a reputation service for sharing trust about well-known public DNS servers. Sort of a wisdom-of-the-crowds attempt for clients and operating systems to bootstrap trust when learning about new public DNS servers. Trust is local and trust doesn't scale as Leif Johansson and Lucy Lynch once told me. So this is an attempt at conveying trust or more likely conveying the lack of trust.

The talk related to DHCP, which wasn't well received, but it's not clear how well the reputation service part was received. HTTPS has a form of a reputation service for identifying compromised certificates called Online Certificate Status Protocol (OCSP).

While public DNS servers also have certificates that could benefit from OCSP, the DNS reputation service I was proposing was more about the anwers returned by the DNS resolvers. Ideally, DNSSEC would be more widespread and the answers returned by a resolver could all be validated by the client. But clients don't normally do DNSSEC validation. They trust the resolvers to do it for them when asked. So, are resolvers returning the correct results? We hope so but how do you catch them if they aren't.

Imagine if you attach to a network that is a bad actor. The network operator gives you DNS resolvers to use over DHCP but they intend to log your DNS traffic and sell access to it. The only ones who know about this are the buyer and the seller and neither have an interest in letting you know.

Now, what if they return invalid results? You are trusting your resolver to give you accurate results. The only way you can be sure though is to do DNSSEC validation at the client.

So imagine if there was a registry, say at dnsprivacy.org, where users could report a public DNS server. The service could list their security practices, audit logs, third-party verification, etc to allow users to decide which DNS servers they trust. If a bad actor is found to be abusing its resolver data, others would immediately know.

If this is something you would like to see happen, contact me!

Update

Marek Vavruša made a great point on the DNSOP mailing list here. The network operator should be involved in this reputation service by pushing the list of its servers that it considers trustworthy. Then the clients can evaluate these servers.

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.

DNS over HTTPS

At the IETF 101 London Hackathon, I created a javascript test client for Stephane Bortzmeyer. There are actually two versions. The first one runs in node.js: DoH client.

The second version uses webpack to run inside the browser: DoH browser client.

As the draft standard changes, I'll update these clients to follow.

Node.js DNS Packet library

Recently, I've been contributing to the node.js library dns-packet. This library takes a JSON description of DNS fields and encodes them into raw DNS packets. On the receiving side, it also decodes raw DNS packets and returns a JSON representation.

It's a handy package that I am using for another future project to be announced soon I hope.

sdtest tool project terminated

• sdtest was a client simulation tool for testing DNS subscriptions. It was written in C and while useful, was limited by the amount of code required to extend it and the lack of C programmers who would do so.

• Therefore, the project was terminated in favor of a new extensible tool called nst (Name Server Test tool) written in javascript node.js. See more on this site under test for more information on nst.

The IETFers app has just been updated (v2.5) to include support for the new iPhone X and iOS 11! Send feedback inside the app in Settings.

Also includes Calendar bug fixes.

Overview

Discovery daemon (discd) is an implementation of the "Discovery Proxy for Multicast DNS-Based Service Discovery" specified as an internet draft of the IETF:

draft-ietf-dnssd-hybrid

It dynamically maps multicast DNS services into the unicast DNS name space. This allows remote service discovery requests to be answered when the querier is not on the same link local network as the service provider.

Traditionally, zero-conf networking (or Bonjour as Apple Computer calls it) only provides answers to queries on the local network. This works great for home and small offfice (SOHO) networks but frustrates corporate and campus users when a device they want to communicate with is on another IP subnet for network scaling reasons.

By dynamically mapping the ever changing multicast DNS (mDNS) services into the unicast DNS namespace, it's possible to remotely query services through a proxy.

discd is that proxy.

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

The IETFers iPhone/iPad app I wrote and maintain for the worldwide Internet Engineering Task Force (IETF) meetings is available for download in the Apple App Store.

If you have bug reports or feature requests, use the Settings panel and send me your wishes!

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

Requirements of the delegating server

The hybrid proxy is an authoritative DNS server for one or more subdomains. Each of these subdomains MUST be delegated to the hybrid proxy by the parent zone.

Subdomains

Subdomains are delegated to another server by defining NS records in the delegating server. The following records create three subdomains and delegate those subdomains to the listed servers.

floor1.example.com. IN      NS      server1.example.com.
floor2.exmaple.com. IN      NS      server2.example.com.
floor3.example.com. IN      NS      server3.example.com.

Browse Records

Service Discovery clients will query known search domains to see if they are browseable for services. Initially, they will query for b.dns-sd.udp.example.com. If the domain is browseable, it will have PTR records for one or more browseable domains. This could include a PTR record for the domain and also for subdomains. For a client to search a hybrid proxy for discoverable services, PTR records for the subdomain of each IP subnet represented by the hybrid proxy must be listed in the delegating server.

b._dns-sd._udp IN      PTR     @                   ;apex is browseable
b._dns-sd._udp IN      PTR     floor1.example.com. ;delegated to discovery proxy
b._dns-sd._udp IN      PTR     floor2.example.com.
b._dns-sd._udp IN      PTR     floor3.example.com.

The client will then query each of the subdomains listed to see if they are browseable, for example, b.dns-sd.udp.floor1.example.com. The hybrid proxy should answer this query with its hostname.

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.

To install on Ubuntu 14.04 LTS (Trusty Tahr), please add this repo and update. 64-bit only.

sudo apt-key adv --keyserver pgp.mit.edu --recv-keys F93418C56652E60C
sudo add-apt-repository 'deb [arch=amd64] http://dl.dnsdisco.com/ trusty main'
sudo apt-get update

To install on Ubuntu 16.04 LTS (Xenial Xerus), please add this repo and update. 64-bit only.

sudo apt-key adv --keyserver pgp.mit.edu --recv-keys F93418C56652E60C
sudo add-apt-repository 'deb [arch=amd64] http://dl.dnsdisco.com/ xenial main'
sudo apt-get update

The software can then be installed with the following commands:

sudo apt-get install discd
sudo apt-get install discli
sudo apt-get install discweb # (coming soon)

In July of 2016, I gave a talk to the IETF DNS-SD Working Group in Berlin with a status update of DNS Push Notifications.

Here are the slides:

In March of 2015, I gave a talk to the IETF DNS-SD Working Group in Dallas introducing DNS Push Notifications. This work was a joint effort between Stuart Cheshire and myself as a next generation follow on to LLQ.

Here are the slides:

In November of 2014, I gave a talk to the IETF DNS-SD Working Group in Honolulu explaining how Long Lived Queries (LLQ) work.

Here are the slides:

In June of 2014, I gave an invited talk to the Research & Education Track of NANOG 61 explaining what a Discovery Proxy was (Hybrid Proxy at the time) and how Long Lived Queries (LLQ) works. The link at the end of the slides http://hypd.info is no longer valid and should be changed to https://dnsdisco.com.

Here are the slides: