PrivateDNS.txt

   1 Private DNS
   2
   3 Summary
   4
   5 Private DNS is an extension to standard Wide Area Bonjour that allows
   6 for secure, encrypted, and authorized communications. Private data sent
   7 from a client to a DNS server is encrypted using Transport Layer
   8 Security (TLS), ensuring that the data is hidden from prying eyes, and
   9 contains Transaction Signatures (TSIG), so the server can authorize the
  10 request. TSIGs are typically associated with Dynamic Updates; we are
  11 using them for standard and long-lived queries as well. Private DNS also
  12 protects Dynamic Updates from eavesdropping, by wrapping the update in a
  13 TLS communication channel if the server has been configured appropriately.
  14
  15 Architectural Overview
  16
  17 mDNSResponder has been modified to automatically issue a private query
  18 when necessary. After receiving an NXDOMAIN error, mDNSResponder checks
  19 in the system keychain to see if the user has a DNS query key (TSIG key)
  20 for the name in question, or for a parent of that name. If a suitable
  21 key is found, mDNSResponder looks up the zone data associated with the
  22 name of the question. After determining the correct name server,
  23 mDNSResponder looks up an additional SRV record "_dns-private._tcp". If
  24 it finds this record, mDNSResponder will re-issue the query privately.
  25 If either there is no _dns-private._tcp record, or there is no secret
  26 key, the call fails as it initially did, with an NXDOMAIN error.
  27
  28 Once the secret key is found and the SRV record is looked up, mDNSResponder
  29 opens a TLS connection to the server on the port specified in the SRV
  30 record just looked up. After the connection succeeds, mDNSResponder
  31 can proceed to use that communication channel to make requests of
  32 the server. Every private packet must also have a TSIG record;
  33 the DNS server uses this TSIG record to allow access to its data.
  34
  35 When setting up a long-lived query over TCP (with or without TLS)
  36 TCP's standard three-way handshake makes the full four-packet LLQ setup
  37 exchange described in <http://files.dns-sd.org/draft-sekar-dns-llq.txt>
  38 unnecessary. Instead, when connecting over TCP, the client simply sends
  39 a setup message and expects to receive ACK + Answers. The setup message
  40 sent is formatted as described in the LLQ document, however there is
  41 an additional TSIG' resource record added to the end of it. The TSIG
  42 resource records looks and acts exactly as it does in a secure update.
  43 So when the server receives an LLQ (or a standard query), it looks to
  44 see if the zone that is being referenced is public or private. If it's
  45 private, then it makes sure that the client is authorized to query that
  46 zone (by using the TSIG signature) and returns the appropriate data.
  47 When a zone is configured as private, the server will do this type of
  48 authorization checking for every query except those queries that are
  49 looking for SOA and NS records.
  50
  51 Implementation Issues
  52
  53 dnsextd
  54
  55 dnsextd has been modified to behave much like a DNS firewall. The "real"
  56 DNS server is configured to listen on non-standard ports on the loopback
  57 interface. dnsextd then listens on the standard DNS ports (TCP/UDP port
  58 53) and intercepts all DNS traffic. It is responsible for determining
  59 what zone a DNS request is associated with, determining whether the
  60 client is allowed access to that zone, and returning the appropriate
  61 information back to the caller. If the packet is allowed access, dnsextd
  62 forwards the request to the "real" nameserver, and returns the result to
  63 the caller.
  64
  65 It was tempting to use BIND9's facility for configuring TSIG enabled
  66 queries while doing this work. However after proceeding down that path,
  67 enough subtle interaction problems were found that it was not practical
  68 to pursue this direction, so instead dnsextd does all TSIG processing
  69 for queries itself. It does continue to use BIND9 for processing TSIG
  70 enabled dynamic updates, though one minor downside with this is that
  71 there are two configuration files (named.conf or dnsextd.conf) that have
  72 the same secret key information. That seems redundant and error-prone,
  73 and moving all TSIG processing for both queries and updates into dnsextd
  74 would fix this.
  75
  76 All private LLQ operations are TSIG-enabled and sent over a secure
  77 encrypted TLS channel. To accommodate service providers who don't want
  78 to have to keep open a large number of TLS connections to a large number
  79 of client machines, the server has the option of dropping the TLS
  80 connection after initial LLQ setup and sending subsequent events and
  81 refreshes using unencrypted UDP packets. This results in less load on
  82 the server, at the cost of slightly lower security (LLQs can only be set
  83 up by an authorized client, but once set up, subsequent change event
  84 packets sent over unencrypted UDP could be observed by an eavesdropper).
  85 A potential solution to this deficiency might be in using DTLS, which is
  86 a protocol based on TLS that is capable of securing datagram traffic.
  87 More investigation needs to be done to see if DTLS is suitable for
  88 private DNS.
  89
  90 It was necessary to relax one of the checks that dnsextd performs during
  91 processing of an LLQ refresh. Prior to these changes, dnsextd would
  92 verify that the refresh request came from the same entity that setup the
  93 LLQ by comparing both the IP Address and port number of the request
  94 packet with the IP Address and port number of the setup packet. Because
  95 of the preceding issue, a refresh request might be sent over two
  96 different sockets. While their IP addresses would be the same, their
  97 port numbers could potentially differ. This check has been modified to
  98 only check that the IP addresses match.
  99
 100 When setting up a semi-private LLQ (where the request and initial answer
 101 set is sent over TLS/TCP, but subsequent change events are sent over
 102 unencrypted UDP), dnsextd uses the port number of the client's TCP
 103 socket to determine the UDP event port number. While this eliminates the
 104 need to pass the UDP event port number in the LLQ setup request
 105 (obviating a potential data mismatch error), I think it does more harm
 106 than good, for three reasons:
 107
 108 1) We are relying that all the routers out there implement the Port
 109    Mapping Protocol spec correctly.
 110
 111 2) Upon setup every LLQ must NAT map two ports. Upon tear down every LLQ
 112    must tear down two NAT mappings.
 113
 114 3) Every LLQ opens up two sockets (TCP and UDP), rather than just the
 115    one TCP socket.
 116
 117 All of this just to avoid sending two bytes in the LLQ setup packet
 118 doesn't seem logical. The approach also necessitates creating an
 119 additional UDP socket for every private LLQ, port mapping both the TCP
 120 socket as well as the UDP socket, and moderately increasing the
 121 complexity and efficiency of the code. Because of this we plan to allow
 122 the LLQ setup packet to specify a different UDP port for change event
 123 packets. This will allow mDNSResponder to receive all UDP change event
 124 packets on a single UDP port, instead of a different one for each LLQ.
 125
 126 Currently, dnsextd is buggy on multi-homed hosts. If it receives a
 127 packet on interface 2, it will reply on interface 1 causing an error in
 128 the client program.
 129
 130 dnsextd doesn't fully process all of its option parameters.
 131 Specifically, it doesn't process the keywords: "listen-on",
 132 "nameserver", "private", and "llq". It defaults to expecting the "real"
 133 nameserver to be listening on 127.0.0.1:5030.
 134
 135
 136 mDNSResponder
 137
 138 Currently, mDNSResponder attempts to issue private queries for all
 139 queries that initially result in an NXDOMAIN error. This behavior might
 140 be modified in future versions, however it seems patently incorrect to
 141 do this for reverse name lookups. The code that attempts to get the zone
 142 data associated with the name will never find the zone for a reverse
 143 name lookup, and so will issue a number of wasteful DNS queries.
 144
 145 mDNSResponder doesn't handle SERV_FULL or STATIC return codes after
 146 setting up an LLQ over TCP. This isn't a terrible problem right now,
 147 because dnsextd doesn't ever return them, but this should be fixed so
 148 that mDNSResponder will work when talking to other servers that do
 149 return these error codes.
 150
 151
 152 Configuration:
 153
 154 Sample named.conf:
 155
 156 //
 157 // Include keys file
 158 //
 159 include "/etc/rndc.key";
 160 // Declares control channels to be used by the rndc utility.
 161 //
 162 // It is recommended that 127.0.0.1 be the only address used.
 163 // This also allows non-privileged users on the local host to manage
 164 // your name server.
 165
 166 //
 167 // Default controls
 168 //
 169 controls
 170         {
 171         inet 127.0.0.1 port 54 allow { any; } keys { "rndc-key"; };
 172         };
 173
 174 options
 175         {
 176         directory "/var/named";
 177         /*
 178          * If there is a firewall between you and nameservers you want
 179          * to talk to, you might need to uncomment the query-source
 180          * directive below. Previous versions of BIND always asked
 181          * questions using port 53, but BIND 8.1 uses an unprivileged
 182          * port by default.
 183          */
 184
 185         forwarders
 186                         {
 187                         65.23.128.2;
 188                         65.23.128.3;
 189                         };
 190
 191         listen-on port 5030 { 127.0.0.1; };
 192         recursion true;
 193         };
 194
 195 //
 196 // a caching only nameserver config
 197 //
 198 zone "." IN
 199         {
 200         type hint;
 201         file "named.ca";
 202         };
 203
 204 zone "localhost" IN
 205         {
 206         type master;
 207         file "localhost.zone";
 208         allow-update { none; };
 209         };
 210
 211 zone "0.0.127.in-addr.arpa" IN
 212         {
 213         type master;
 214         file "named.local";
 215         allow-update { none; };
 216         };
 217
 218 zone "hungrywolf.org." in
 219         {
 220         type master;
 221         file "db.hungrywolf.org";
 222         allow-update { key hungrywolf.org.; };
 223         };
 224
 225 zone "157.23.65.in-addr.arpa" IN
 226         {
 227         file "db.65.23.157";
 228         type master;
 229         };
 230
 231 zone "100.255.17.in-addr.arpa" IN
 232         {
 233         file "db.17.255.100";
 234         type master;
 235         };
 236
 237 zone "66.6.24.in-addr.arpa" IN
 238         {
 239         file "db.24.6.66";
 240         type master;
 241         };
 242
 243 key hungrywolf.org.
 244         {
 245         algorithm hmac-md5;
 246         secret "c8LWr16K6ju6KMO5zT6Tyg==";
 247         };
 248
 249 logging
 250         {
 251         category default { _default_log; };
 252
 253         channel _default_log
 254                 {
 255                 file "/Library/Logs/named.log";
 256                 severity info;
 257                 print-time yes;
 258                 };
 259         };
 260
 261
 262 Sample dnsextd.conf:
 263
 264 options { };
 265
 266 key "hungrywolf.org."
 267         {
 268         secret "c8LWr16K6ju6KMO5zT6Tyg==";
 269         };
 270
 271 zone "hungrywolf.org."
 272         {
 273         type private;
 274         allow-query { key hungrywolf.org.; };
 275         };