[tor-commits] [torspec/master] Add Ondrej's dns proposal in its original form
nickm at torproject.org
nickm at torproject.org
Mon Aug 12 19:17:31 UTC 2013
commit e24878466c5233a852e38dde8acc9cb6511f5538
Author: Nick Mathewson <nickm at torproject.org>
Date: Fri Aug 2 11:44:49 2013 -0400
Add Ondrej's dns proposal in its original form
---
proposals/219-expanded-dns.txt | 267 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 267 insertions(+)
diff --git a/proposals/219-expanded-dns.txt b/proposals/219-expanded-dns.txt
new file mode 100644
index 0000000..c291984
--- /dev/null
+++ b/proposals/219-expanded-dns.txt
@@ -0,0 +1,267 @@
+Filename: xxx-dns-dnssec.txt
+Title: Support for full DNS and DNSSEC resolution in Tor
+Authors: Ondrej Mikle
+Created: 4 February 2012
+Modified: 19 August 2012
+Status: Draft
+
+0. Overview
+
+ Adding support for any DNS query type to Tor, as well as DNSSEC support.
+
+0.1. Motivation
+
+ Many applications running over Tor need more than just resolving FQDN to
+ IPv4 and vice versa. Sometimes to prevent DNS leaks the applications have to
+ be hacked around to be supplied necessary data by hand (e.g. SRV records in
+ XMPP). TLS connections will benefit from planned TLSA record that provides
+ certificate pinning to avoid another Diginotar-like fiasco.
+
+ DNSSEC is part of the DNS protocol and the most appropriate place for DNSSEC
+ API would be probably in OS libraries (e.g. libc). However that will
+ probably take time until it becomes widespread.
+
+ On the Tor's side (as opposed to application's side), DNSSEC will provide
+ protection against DNS cache-poisoning attacks (provided that exit is not
+ malicious itself, but still reduces attack surface).
+
+1. Design
+
+1.1 New cells
+
+ There will be two new cells, RELAY_DNS_BEGIN and RELAY_DNS_RESPONSE (we'll
+ use DNS_BEGIN and DNS_RESPONSE for short below).
+
+ DNS_BEGIN payload:
+
+ DNS packet data (variable length)
+
+ The DNS packet must be generated internally by libunbound to avoid
+ fingerprinting users by differences in client resolvers' behavior.
+
+ DNS_RESPONSE payload:
+
+ total length (2 octets)
+ data (variable)
+
+ Data contains the reply DNS packet or its part if packet would not fit into
+ the cell. Total length describes length of complete response packet, thus
+ one DNS_BEGIN may be answered by multiple DNS_RESPONSE cells.
+
+ DNS_BEGIN must use a non-zero, distinct StreamID, corresponding DNS_RESPONSE
+ will use the same StreamID. Similarly to RELAY_RESOLVE(D), no actual stream
+ is created.
+
+ AXFR and IXRF are not supported in this cell by design (see specialized tool
+ below).
+
+2. Interfaces to applications
+
+ DNSPort evdns - existing implementation will be updated to use DNS_BEGIN.
+
+3. Limitations on DNS query
+
+ Query class is limited to IN (INTERNET) since the only other useful class
+ CHAOS is practical for directly querying authoritative servers (OR in this
+ case acts as a recursive resolver). Query for class other than IN will
+ return REFUSED in the inner DNS packet.
+
+ Multiple questions in a single packet are not supported and OR will respond
+ with REFUSED as the DNS error code.
+
+ All query RR types are allowed.
+
+ [XXXX I originally thought about some exit policy like "basic RR types" and
+ "all RRs", but managing such list in deployed nodes with extra directory
+ flags outweighs the benefit. Maybe disallow ANY RR type? ]
+
+ Client as well as OR MUST block attempts to resolve local RFC 1918, 4193,
+ 4291 adresses (PTR). REFUSED will be returned as DNS error code from OR.
+
+ Request for special names (.onion, .exit, .noconnect) will return REFUSED.
+
+4. Implementation notes
+
+ Client will periodically purge incomplete DNS replies. Any unexpected
+ DNS_RESPONSE will be dropped.
+
+ AD flag must be zeroed out on client unless validation is performed.
+
+ [XXXX libunbound lowlevel API, Tor+libunbound libevent loop
+
+ libunbound doesn't publicly expose all the necessary parts of low-level API.
+ It can return the received DNS packet, but not let you construct a packet
+ and get it in wire-format, for example.
+
+ Options I see:
+
+ a) patch libunbound to be able feed wire-format DNS packets and add API to
+ obtain constructed packets instead of sending over network
+
+ b) replace bufferevents for sockets in unbound with something like
+ libevent's paired bufferevents. This means that data extracted from
+ DNS_RESPONSE/DNS_BEGIN cells would be fed directly to some evbuffers that
+ would be picked up by libunbound. It could possibly result in avoiding
+ background thread of libunbound's ub_resolve_async running separate libevent
+ loop.
+
+ c) bind to some arbitrary local address like 127.1.2.3:53 and use it as
+ forwarder for libunbound. The code there would pack/unpack the DNS packets
+ from/to libunbound into DNS_BEGIN/DNS_RESPONSE cells. It wouldn't require
+ modification of libunbound code, but it's not pretty either. Also the bind
+ port must be 53 which usually requires superuser privileges.
+
+ Code of libunbound is fairly complex for me to see outright what would the
+ best approach be.
+ ]
+
+5. Separate tool for AXFR
+
+ The AXFR tool will have similar interface like tor-resolve, but will
+ return raw DNS data.
+
+ Parameters are: query domain, server IP of authoritative DNS.
+
+ The tool will transfer the data through "ordinary" tunnel using RELAY_BEGIN
+ and related cells.
+
+ This design decision serves two goals:
+
+ - DNS_BEGIN and DNS_RESPONSE will be simpler to implement (lower chance of
+ bugs)
+ - in practice it's often useful do AXFR queries on secondary authoritative
+ DNS servers
+
+ IXFR will not be supported (infrequent corner case, can be done by manual
+ tunnel creation over Tor if truly necessary).
+
+6. Security implications
+
+ Transaction ID is provided randomly by libunbound, no need to modify.
+
+ As proposal 171 mentions, we need mitigate circuit correlation. One solution
+ would be keeping multiple streams to multiple exit nodes and picking one at
+ random for DNS resolution. Other would be keeping DNS-resolving circuit open
+ only for a short time (e.g. 1-2 minutes). Randomly changing the circuits
+ however means that it would probably incur additional latency since there
+ would likely be a few cache misses on the newly selected exits.
+
+
+7. TTL normalization idea
+
+ A bit complex on implementation, because it requires parsing DNS packets at
+ exit node.
+
+ TTL in reply DNS packet MUST be normalized at exit node so that client won't
+ learn what other clients queried. The normalization is done in following
+ way:
+
+ - for a RR, the original TTL value received from authoritative DNS server
+ should be used when sending DNS_RESPONSE, trimming the values to interval
+ [5, 600]
+ - does not pose "ghost-cache-attack", since once RR is flushed from
+ libunbound's cache, it must be fetched anew
+
+8. Round trips and serialization
+
+ Following are two examples of resolving two A records. The one for
+ addons.mozila.org is an example of a "common" RR without CNAME/DNAME, the
+ other for www.gov.cn an extreme example chained through 5 CNAMEs and 3 TLDs.
+ The examples below are shown for resolving that started with an empty DNS
+ cache.
+
+ Note that multiple queries are made by libunbound as it tries to adjust for
+ the latency of network. "Standard query response" below that does not list
+ RR type is a negative NOERROR reply with NSEC/NSEC3 (usually reply to DS
+ query).
+
+ The effect of DNS cache plays a great role - once DS/DNSKEY for root and a
+ TLD is cached, at most 3 records usually need to be fetched for a record
+ that does not utilize CNAME/DNAME (3 roundtrips for DS, DNSKEY and the
+ record itself if there are no zone cuts below).
+
+ Query for addons.mozilla.org, 6 roundtrips (not counting retries):
+
+ Standard query A addons.mozilla.org
+ Standard query A addons.mozilla.org
+ Standard query A addons.mozilla.org
+ Standard query A addons.mozilla.org
+ Standard query A addons.mozilla.org
+ Standard query response A 63.245.217.112 RRSIG
+ Standard query response A 63.245.217.112 RRSIG
+ Standard query response A 63.245.217.112 RRSIG
+ Standard query A addons.mozilla.org
+ Standard query response A 63.245.217.112 RRSIG
+ Standard query response A 63.245.217.112 RRSIG
+ Standard query A addons.mozilla.org
+ Standard query response A 63.245.217.112 RRSIG
+ Standard query response A 63.245.217.112 RRSIG
+ Standard query DNSKEY <Root>
+ Standard query DNSKEY <Root>
+ Standard query response DNSKEY DNSKEY RRSIG
+ Standard query response DNSKEY DNSKEY RRSIG
+ Standard query DS org
+ Standard query response DS DS RRSIG
+ Standard query DNSKEY org
+ Standard query response DNSKEY DNSKEY DNSKEY DNSKEY RRSIG RRSIG
+ Standard query DS mozilla.org
+ Standard query response DS RRSIG
+ Standard query DNSKEY mozilla.org
+ Standard query response DNSKEY DNSKEY DNSKEY RRSIG RRSIG
+
+ Query for www.gov.cn, 16 roundtrips (not counting retries):
+
+ Standard query A www.gov.cn
+ Standard query A www.gov.cn
+ Standard query A www.gov.cn
+ Standard query A www.gov.cn
+ Standard query A www.gov.cn
+ Standard query response CNAME www.gov.chinacache.net CNAME www.gov.cncssr.chinacache.net CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119
+ Standard query response CNAME www.gov.chinacache.net CNAME www.gov.cncssr.chinacache.net CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119
+ Standard query A www.gov.cn
+ Standard query response CNAME www.gov.chinacache.net CNAME www.gov.cncssr.chinacache.net CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119
+ Standard query response CNAME www.gov.chinacache.net CNAME www.gov.cncssr.chinacache.net CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119
+ Standard query response CNAME www.gov.chinacache.net CNAME www.gov.cncssr.chinacache.net CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119
+ Standard query A www.gov.cn
+ Standard query response CNAME www.gov.chinacache.net CNAME www.gov.cncssr.chinacache.net CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119
+ Standard query response CNAME www.gov.chinacache.net CNAME www.gov.cncssr.chinacache.net CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119
+ Standard query A www.gov.chinacache.net
+ Standard query response CNAME www.gov.cncssr.chinacache.net CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119
+ Standard query A www.gov.cncssr.chinacache.net
+ Standard query response CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119
+ Standard query A www.gov.foreign.ccgslb.com
+ Standard query response CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119
+ Standard query A wac.0b51.edgecastcdn.net
+ Standard query response CNAME gp1.wac.v2cdn.net A 68.232.35.119
+ Standard query A gp1.wac.v2cdn.net
+ Standard query response A 68.232.35.119
+ Standard query DNSKEY <Root>
+ Standard query response DNSKEY DNSKEY RRSIG
+ Standard query DS cn
+ Standard query response
+ Standard query DS net
+ Standard query response DS RRSIG
+ Standard query DNSKEY net
+ Standard query response DNSKEY DNSKEY RRSIG
+ Standard query DS chinacache.net
+ Standard query response
+ Standard query DS com
+ Standard query response DS RRSIG
+ Standard query DNSKEY com
+ Standard query response DNSKEY DNSKEY RRSIG
+ Standard query DS ccgslb.com
+ Standard query response
+ Standard query DS edgecastcdn.net
+ Standard query response
+ Standard query DS v2cdn.net
+ Standard query response
+
+ An obvious idea to avoid so many roundtrips is to serialize them together.
+ There has been an attempt to standardize such "DNSSEC stapling" [1], however
+ it's incomplete for the general case, mainly due to various intricacies -
+ proofs of non-existence, NSEC3 opt-out zones, TTL handling (see RFC 4035
+ section 5).
+
+References:
+
+ [1] https://www.ietf.org/mail-archive/web/dane/current/msg02823.html
More information about the tor-commits
mailing list