IETF plants privacy test inside DNS

'Stubby' aims to protect your metadata from snoopers

The Internet Engineering Task Force's (IETF's) years-long effort to protect Internet users has taken a small step forward, with one option for better Domain Name System (DNS) privacy reaching the test stage.

The idea isn't to flick the switch to encryption in one big hit, but rather, to provide a resolver that can accept connections and return responses over Transport Layer Security (TLS) at the user-side.

The demonstrator's only dependency is OpenSSL version 1.0.2 or better, so Stubby can authenticate hostnames.

The problem Dickinson and others are trying to address is that DNS requests are extremely revealing about user activity, since they identify every server you seek out on the public Internet.

As the American Civil Liberties Union's Daniel Kahn Gillmor told the IETF in a joint presentation with Dickinson at last week's IETF 97 in Seoul, DNS metadata leakage allows individuals to be identified.

While DNS data is public, Gillmor argued, individual DNS transactions should not be, and stub-to-resolver encryption is arguably the best place to start.

Which brings us back to Stubby: since fixing the whole DNS in one shot is something of a Mars mission, one of the steps along the way is to privacy-enable a “stub resolver” (for example, the DNS resolver in a home router counts as a stub, and if it were supported, it could encrypt its communications with an ISP's DNS).

On a Linux or MacOS box, Stubby provides the local stub, sending outgoing DNS requests from 127.0.0.1 to a DNS Privacy Server (there are currently four), using the “strict” or “opportunistic” profiles defined in https://tools.ietf.org/html/draft-ietf-dprive-dtls-and-tls-profiles-07 this IETF draft.

Dickinson's company, Sinodun, offers privacy servers at dnsovertls.sinodun.com and dnsovertls1.sinodun.com, and there are two others at getdnsapi.net and dns.cmrg.net.

The work falls into the context of the Internet Architecture Board's declaration in 2014 that “pervasive monitoring is an attack” that standards developers need to unite to defeat. ®