Offsite Memory

Update:

• Another DNSCurve forwarder entered the race. CurveDNS – A DNSCurve Forwarding Name Server supports both UDP and TCP and is IPv6-capable.
• Matthew Dempsky’s patch to djbdns remains the only available DNSCurve resolver for Linux. GbDns by George Barwood appears to support both DNSCurve and DNSSEC, but runs on Windows only.
• In addition to the Ubuntu packages, I also built packages for Debian Lenny.
  • Import the repository key: wget -O - http://download.opensuse.org/repositories/home:/lampeh:/dnscurve/Debian_5.0/Release.key | apt-key add -
  • Add deb http://download.opensuse.org/repositories/home:/lampeh:/dnscurve/Debian_5.0 . to /etc/apt/sources.list

I can haz running code?

DNSCurve has been hyped vaporware promoted for nearly two years while DNSSEC finally enjoys steady deployment and interoperable implementations. Now that OpenDNS announced the adoption of DNSCurve and many twits were tweeted about how OpenDNS uses “DNSCurve today, not DNSSEC tomorrow“, I wanted to find out how ready and usable DNSCurve really is today.

I won’t go into any of the aesthetic and operational problems of the DNSCurve design. I just wanted to make it work. Now.

To install the (so far) only available DNSCurve prototype by Matthew Dempsky, you need the DNSCurve forwarding proxy for authoritative servers and a DNSCurve patch for dnscache from the djbdns package. Both require the NaCl library to compile.

For easier installation, I built my own Ubuntu DNSCurve repository:

apt-get install daemontools djbdns dnscurve-forward

The UDP DNSCurve proxy

First, install the UDP part of the DNSCurve proxy server.

Create a user account for dnscurve:

useradd -r -d /var/lib/dnscurve-forward dnscurve

Now initialize a standard daemontools environment. Because dnscurve has no configure script yet, I used dnscache-conf:

dnscache-conf dnscurve dnscurve /var/lib/dnscurve-forward 85.10.240.252

Remove unnecessary files:

rm -r seed env/CACHESIZE env/DATALIMIT root/ip root/servers

The current implementation doesn’t seem to support IP address selection for outgoing queries (towards the authoritative server) using $IPSEND. Use route and/or iptables to force a specific source address if necessary.

Put the IP address of the authoritative server into env/FORWARD:

echo 85.10.240.254 >env/FORWARD

Modify the run script to start dnscurve-forward via udpserver:

#!/bin/sh
exec 2>&1
exec envdir ./env sh -c '
exec envuidgid dnscurve softlimit -d300000 udpserver "$IP" 53 /usr/bin/dnscurve-forward "$FORWARD"
'

Create a key pair for the server:

$ dnscurve-kegyen
DNS public key: uz5mjzrmru60lc6kdsszqhlsw0gvjdj6j9cknmr22qkjwsl7mrtdyz
Hex public key: 13fe3baf36402e1319c6df3e8939701b3268605a91ce2b848d906379e6cdcc7f
Hex secret key: 7c4db642ea6ee136c9ce05588d695326f90a95fa5959245a60a23e4c1dd0df83

Put the private key into env/DNSCURVE_PRIVATE_KEY:

echo "7c4db642ea6ee136c9ce05588d695326f90a95fa5959245a60a23e4c1dd0df83" >env/DNSCURVE_PRIVATE_KEY

Enable the service by linking it into the daemontools service directory:

ln -s /var/lib/dnscurve-forward /etc/service/

The service should start immeditately:

svstat /etc/service/dnscurve-forward
/etc/service/dnscurve-forward: up (pid 18158) 1 seconds

Now place the “DNS public key” into the zone file and point the A record towards your DNSCurve proxy server:

example.com. NS uz5mjzrmru60lc6kdsszqhlsw0gvjdj6j9cknmr22qkjwsl7mrtdyz.example.com.
uz5mjzrmru60lc6kdsszqhlsw0gvjdj6j9cknmr22qkjwsl7mrtdyz.example.com. A 85.10.240.252

Your DNSCurve proxy should now forward requests to the authoritative server. Watch log/main/current for error messages if it doesn’t work.

$ dig example.com SOA @85.10.240.252

Large UDP packets

The proxy passes on EDNS flags and returns large UDP responses unharmed:

$ dig +dnssec kein.sicherheitsproblem.de DNSKEY @85.10.240.252
[...]
;; MSG SIZE rcvd: 794


Fragmented UDP responses also pass through the proxy:

$ dig +bufsize=4096 +ignore kein.sicherheitsproblem.de ANY @85.10.240.252
[...]
;; MSG SIZE rcvd: 1949


DNSSEC zones

DNSSEC records passed through the DNSCurve proxy (in clear, without encryption) still validate. So, at least in theory, DNSSEC and DNSCurve could be used together, with DNSCurve encrypting the DNSSEC-signed records on the transport link between the last-hop resolver and the DNSCurve content server.

The TCP DNSCurve proxy

Update: The DNSCurve proxy does not support TCP yet. Because the client side implementation in dnscache does not use EDNS0, DNSCurve response size is currently limited to 512 bytes or less.

The DNSCurve resolver

The patched dnscache resolver doesn’t need any special configuration:

dnscache-conf dnscache dnscache /var/lib/dnscache 85.10.240.251

(don’t forget to allow clients to query your server by creating files in $ROOT/ip/)

Enable the service by linking it into the daemontools service directory:

ln -s /var/lib/dnscache /etc/service/dnscache

Now query your dnscache for a domain with DNSCurve public keys:

$ dig kein.sicherheitsproblem.de SOA @85.10.240.251

The dnscache logfile signals DNSCurve queries with a “+” in the “tx” log lines:

==> /var/lib/dnscache/log/main/current <==
@400000004b8717b12538965c tx 0 6 kein.sicherheitsproblem.de. kein.sicherheitsproblem.de. + 550af0fc


Hooray, it works!

IPv6 and all the other stuff

Unfortunately, the DNSCurve patch conflicts with the widely used IPv6 patches which in turn also conflict with the useful CNAME correcting patches. Oh what a joy is Open Source. Why does djb software always need so many patches to work right?

My older patches are obsolete, now that glibc 2.11 supports RES_USE_DNSSEC and fixed an EDNS-related bug.

I backported the changes to the glibc versions used in Ubuntu 9.04 (Jaunty Jackalope) and 9.10 (Karmic Koala) as well as Debian Lenny:

• Ubuntu 9.04: backported RES_USE_DNSSEC patch for glibc 2.9
• Ubuntu 9.10: backported RES_USE_DNSSEC patch for eglibc 2.10.1
• Debian Lenny: backported RES_USE_DNSSEC patch for glibc 2.7

Binary packages for Ubuntu are available from my Personal Package Archive.

Note: This article is obsolete. Follow this link for backported RES_USE_DNSSEC patches from glibc 2.11.

While my recent take on making glibc more DNSSEC-friendly is “good enough” to let OpenSSH verify SSHFP records, it’s a workaround and not a real solution. A better approach would be to give applications the choice to use the RES_USE_DNSSEC resolver option and let them test for the AD flag in lookup responses or even verify the signatures on their own.

Here’s a patch to enable RES_USE_DNSSEC without adding actual signature validation support to the glibc resolver.

EDNS0 in glibc

Stock glibc already comes with support for EDNS0. RES_USE_EDNS0 or “options edns0” in /etc/resolv.conf add an EDNS0 OPT record to queries but offer no method to set DO=1:

127.0.0.1.47056 > 127.0.0.1.53: [1au] A? fnord.gov. ar: . OPT UDPsize=1024 (38)ldns
127.0.0.1.53 > 127.0.0.1.47056: NXDomain q: A? fnord.gov. 0/1/1 [...] ar: . OPT UDPsize=4096 (103)

Note: A problem can occur in the interaction of (portable) OpenSSH and glibc, resulting in queries with an invalid UDPsize=0. See this post on the openssh-unix-dev mailing list with a proposed workaround (committed). Also reported to Ubuntu and the glibc bug tracker (fixed).

Adding support for DO

This patch adds RES_USE_DNSSEC to resolv.h and a resolv.conf-option “dnssec-ok“.

[download patch]

A resolver option for security-aware applications

An application may now set RES_USE_DNSSEC and test for the AD flag in DNS responses while resolver functions oblivious to DNSSEC are not irritated by large extraneous record sets.

You may have to recompile DNSSEC-aware applications (e.g. OpenSSH) to recognize and use RES_USE_DNSSEC.

hauke@pope:~$ ssh -v -o VerifyHostKeyDNS=yes orbit.attraktor.org
OpenSSH_5.1p1 Debian-5ubuntu1a, OpenSSL 0.9.8g 19 Oct 2007
[...]
debug1: found 1 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS

127.0.0.1.41424 > 127.0.0.1.53: [1au] A? orbit.attraktor.org. ar: . OPT UDPsize=1024 (48)
127.0.0.1.53 > 127.0.0.1.41424: q: A? orbit.attraktor.org. 1/0/1 [...] ar: . OPT UDPsize=4096 (64)
127.0.0.1.60880 > 127.0.0.1.53: [1au] SSHFP? orbit.attraktor.org. ar: . OPT UDPsize=65535 OK (48)
127.0.0.1.53 > 127.0.0.1.60880: q: SSHFP? orbit.attraktor.org. 3/0/1 [...] ar: . OPT UDPsize=4096 OK (428)

Global settings in /etc/resolv.conf

Additionally, DO can be enabled globally in /etc/resolv.conf through “options dnssec-ok“. Don’t do it unless you have a good reason, as it can lead to unwanted behaviour.

Under the global option, all queries set DO=1 and may return DNSSEC records even where the resolver functions don’ t expect them. These functions usually return the correct answer, yet they log warnings:

firefox: gethostby*.getanswer: asked for "bd.hauke-lampe.de IN A", got type "46"

Also, the default buffer size is too small for many DNSSEC answers:

127.0.0.1.48227 > 127.0.0.1.53: 31891+ [1au] A? fnord.gov. ar: . OPT UDPsize=1024 OK (38)
127.0.0.1.53 > 127.0.0.1.48227: 31891 NXDomain|$ q: A? fnord.gov. 0/4/1 [...] ar: . OPT UDPsize=4096 OK (767)

A NXDOMAIN response in .gov with NSEC3 exceeds the 1024 byte buffer and needs to be retried with TCP:

127.0.0.1.56428 > 127.0.0.1.53: S, 1:1(0)
127.0.0.1.53 > 127.0.0.1.56428: S, 1:1(0) ack 1
127.0.0.1.56428 > 127.0.0.1.53: ., 1:1(0) ack 1
127.0.0.1.56428 > 127.0.0.1.53: P, 1:41(40) ack 1 31891+ [1au] A? fnord.gov. ar: . OPT UDPsize=1024 OK (38)
127.0.0.1.53 > 127.0.0.1.56428: ., 1:1(0) ack 41
127.0.0.1.53 > 127.0.0.1.56428: P, 1:1504(1503) ack 41 31891 NXDomain$ q: A? fnord.gov. 0/8/1 [...] ar: . OPT UDPsize=4096 OK (1501)
127.0.0.1.56428 > 127.0.0.1.53: ., 41:41(0) ack 1504
127.0.0.1.56428 > 127.0.0.1.53: F, 41:41(0) ack 1504
127.0.0.1.53 > 127.0.0.1.56428: F, 1504:1504(0) ack 42
127.0.0.1.56428 > 127.0.0.1.53: ., 42:42(0) ack 1505

Frequent retries over TCP increase the load on the name server and delay the answer to the client.

Larger default buffer size

The second patch changes the default query buffer size from 1024 to 4096. Usually not needed unless you have to enable “options dnssec-ok” for some reason and want to reduce the number of TCP queries.

Beware: Default buffer sizes are statically defined in several files. I certainly have not checked all cases for side-effects and may have missed a definition or changed one where it was not necessary.

[download patch]

With 4096 byte buffer size, even larger responses return without truncation:

127.0.0.1.35864 > 127.0.0.1.53: 64866+ [1au] A? fnord.gov. ar: . OPT UDPsize=4096 OK (38)
127.0.0.1.53 > 127.0.0.1.35864: 64866 NXDomain$ q: A? fnord.gov. 0/8/1 [...] ar: . OPT UDPsize=4096 OK (1501)

127.0.0.1.38231 > 127.0.0.1.53: 40972+ [1au] A? bd.hauke-lampe.de. ar: . OPT UDPsize=4096 OK (46)
127.0.0.1.53 > 127.0.0.1.38231: 40972$ q: A? bd.hauke-lampe.de. 3/5/16 [...] ar: . OPT UDPsize=4096 OK (2661)

Fragmented responses “work for me”:

(flags [DF], proto UDP (17), length 74) 10.42.20.232.48882 > 10.42.23.3.53: [udp sum ok] 25583+ [1au] A? bd.hauke-lampe.de. ar: . OPT UDPsize=4096 OK (46)
(flags [+], proto UDP (17), length 1500) 10.42.23.3.53 > 10.42.20.232.48882: 25583$ q: A? bd.hauke-lampe.de. 3/5/16 [...] [|domain]
(flags [none], proto UDP (17), length 1209) 10.42.23.3 > 10.42.20.232: udp

I did not find the source of this 256 byte buffer size:

127.0.0.1.36225 > 127.0.0.1.53: 44875+ [1au] ANY ANY? 1.0.0.127.in-addr.arpa. ar: . OPT UDPsize=256 OK (51)
127.0.0.1.53 > 127.0.0.1.36225: 44875 Refused q: ANY ANY? 1.0.0.127.in-addr.arpa. 0/0/1 ar: . OPT UDPsize=4096 OK (51)

Where to go from here

[This section is still in draft]

• Does this patch make the stub resolver “security-aware” in the terms of DNSSEC RFCs? I have not verified the MUSTs and SHOULDs against this code
• The next step would probably be DNSSEC validation in the resolver. The glibc stub resolver uses old code from BIND8 (see resolv/README). Maybe it can be amended with features from libUnbound?
  • Must support NSEC3, otherwise rather pointless
  • Example: .se provides a DNSSEC patch for dkim-milter
  • Still, implementing DNSSEC in a stub-resolver is expensive and introduces bugs in critical libraries
• Where expensive DNSSEC validation is undesirable,  the query could be protected by TSIG between the resolver and the recursor or even between the application and the resolver?
  • port TSIG from BIND8 libraries to glibc
  • ldns supports TSIG, too
• Other applications could set RES_USE_DNSSEC and test the AD flag
  • gnupg: “--auto-key-locate“, RFC2538bis/RFC4398
    • secure fingerprint and URL / public key in CERT RR
    • gpg --auto-key-locate cert -e -r [email protected]

Update: If you just want to know how to use OpenSSH with SSHFP DNS records, read this.

1. Create the SSHFP record, repeat with DSA key if necessary:

ssh-keygen -r foohost.example.com -f /etc/ssh/ssh_host_rsa_key.pub

2. Put the record into the DNS zone:

foohost.example.com.    A     192.168.1.1
                        SSHFP 1 1 1cee8dde082a7d50b8f46440f4c12a7bcd7c2741

3. In /etc/ssh/ssh_config or ~/.ssh/config, set:

Host *
  VerifyHostKeyDNS yes

4. Test:

ssh -v foohost.example.com
[...]
debug1: found 1 secure fingerprints in DNS

Done.

OpenSSH can match host keys against fingerprints stored in SSHFP records in DNS and even check for the “Authenticated Data” (AD) flag in DNSSEC-secured lookups. While users of OpenBSD and derivative run-time libraries already benefit from this, glibc doesn’t support it yet. With a single line of inofficial patchery, we can get this bit set, though.

This is a patch for the DNS security-aware user. It does not make your application any more secure than it is now.

The compatible way

The most compatible method is to set the AD flag in the query header. That way, the response won’t contain all the additional DNSSEC-related records that could otherwise confuse an application which does not expect them. Neither the stub resolver nor OpenSSH validate RRSIGs on their own yet, anyway. Also, this method doesn’t need EDNS0 support in the resolver library. The validating recursor simply sets AD in its response header if the answer passed signature validation. OpenSSH tests for AD and can optionally use the result to trust a fingerprint without user interaction.

The RFCs define AD only for DNS responses at this time but IETF work is underway to standardize its use in queries, too. Both BIND and Unbound already implement it.

The downside is that incompatible DNS proxies and packet filters could strip AD flags or drop the packets altogether. If you’re stuck behind such an appliance and cannot run your own recursor, you’re probably out of luck. For further information on DNSSEC compatibility in popular broadband routers and SOHO firewalls, read the results of a study conducted by Nominet and Core Competence: DNSSEC-CPE-Report.pdf (pg. 12, Request Flag Compatibility)

So, my current quick and ugly hack is to unconditionally set AD in all queries sent by the stub resolver by hard-wiring “hp->ad = 1” in  res_nmkquery(). Ideally, the library would allow AD to be set through the use of a resolver option.

This patch “works for me” with Ubuntu Jaunty glibc-2.9-4ubuntu6 and also applies against stock glibc 2.10.1:

[download patch]

--- glibc-2.9/resolv/res_mkquery.c
+++ glibc-2.9-ad/resolv/res_mkquery.c
@@ -141,6 +141,7 @@
    hp->opcode = op;
    hp->rd = (statp->options & RES_RECURSE) != 0;
    hp->rcode = NOERROR;
+   hp->ad = 1;
    cp = buf + HFIXEDSZ;
    buflen -= HFIXEDSZ;
    dpp = dnptrs;

With this patch and “VerifyHostKeyDNS=yes” enabled in SSH config, OpenSSH can trust a host key fingerprint found in DNS:

debug1: found 1 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS

The True Way

The preferred method would be to use an EDNS0 OPT record and set its DNSSEC OK (DO) bit. This allows the resolver to negotiate a larger maximum response size and also returns all DNSSEC-related records, so that the resolver or application could validate the responses themselves, closing the insecure gap between a stub resolver and its validating recursor.

Unfortunately, glibc’s resolver codes still needs some work before it can make good use of EDNS0 for DNSSEC.

Since glibc 2.6, EDNS0 can be enabled by “options edns0” in /etc/resolv.conf or the RES_OPTIONS environment variable (see manpage) and also by adding RES_USE_EDNS0 to the resolver API options.  But this alone won’t let OpenSSH see the AD flag in DNS responses.

Note: A problem can occur in the interaction of (portable) OpenSSH and glibc, resulting in queries with an invalid UDPsize=0. See this post on the openssh-unix-dev mailing list with a proposed workaround (committed). Also reported to Ubuntu and the glibc bug tracker (fixed).

Also, RES_USE_DNSSEC is not yet defined in resolv.h or honored by the resolver code.

Additionally, the resolver’s default buffer size of 1024 byte is too small if RES_USE_DNSSEC is enabled for all queries. DNSSEC RFCs requires a minimum EDNS buffer size of 1220 bytes (although there is ongoing discourse on this limitation) and should be much larger in practice.  DNSSEC records increase the size of an answer by a sizable amount. Too small a buffer leads to truncated responses that need to be retried over TCP, placing a high burden on the server’s resources.

I addressed the issues with a different patch.

If you think you know what you’re doing and still want to experiment with DO=1 in stub resolver queries right now, add NS_OPT_DNSSEC_OK to the flags in __res_nopt():

[download patch]

--- glibc-2.9/resolv/res_mkquery.c
+++ glibc-2.9-do/resolv/res_mkquery.c
@@ -248,6 +248,7 @@
    *cp++ = NOERROR;    /* extended RCODE */
    *cp++ = 0;        /* EDNS version */
    /* XXX Once we support DNSSEC we change the flag value here.  */
+   flags |= NS_OPT_DNSSEC_OK;
    NS_PUT16(flags, cp);
    NS_PUT16(0, cp);    /* RDLEN */
    hp->arcount = htons(ntohs(hp->arcount) + 1);