[tor-dev] Tor and DNS

[Nick Mathewson]

On Sat, Feb 4, 2012 at 10:38 PM, Ondrej Mikle <ondrej.mikle at gmail.com> wrote:
> On 02/01/2012 10:01 AM, Jacob Appelbaum wrote:
>>
>> That sounds good. I'll wait for the first draft and send feedback.
>
> First draft is ready here:
>
> https://github.com/hiviah/torspec/blob/master/proposals/ideas/xxx-dns-dnssec.txt

Cool!  Since you're calling it a draft, I'm not assigning it a number
yet; please let me know when you want that to change.

Some initial comments:

>  DNS_BEGIN payload:
>
>    RR type  (2 octets)
>    RR class (2 octets)
>    ID       (2 octets)
>    length   (1 octet)
>    query    (variable)
>
>  The RR type and class match counterparts in DNS packet. ID is for
>  identifying which data belong together, since response can be longer
>  than single cell's payload. The ID MUST be random and MUST NOT be
>  copied from xid of request DNS packet (in case of using DNSPort).

I think you can dispense with the "ID" field entirely; the "StreamID"
part of the relay cell header should already fulfill this role, if I'm
understanding the purpose of "ID" correctly.

Like Jakob, I'm wondering why there isn't any support for setting flags.

I wonder whether the "length" field here is redundant with the
"length" field in the relay header.  Probably not, I guess: Having a
length field here means we can send

>  DNS_RESPONSE payload:
>
>    ID           (2 octets)
>    data length  (2 octets)
>    total length (4 octets)
>    data         (variable)

So to be clear, if the reply is 1200 bytes long, then the user will
receive four cells, with relay payload contents:
 { ID = x, data_len = 490, total_len = 1200, data = (bytes[0..489] }
 { ID = x, data_len = 490, total_len = 1200, data = (bytes[490..979] }
 { ID = x, data_len = 220, total_len = 1200, data = (bytes[980..1199],
zero padding}
}

As above, I think we can eliminate the ID field.  Also, in this case,
I think the length field in this packet _is_ redundant with the length
field of the relay cell header.

I think the total_len field could be replaced with a single bit to
indicate "this is the last cell".

>  Data contains the reply DNS packet. Total length describes length of
>  complete response packet.

I think we want to do some sanitization on the reply DNS packet. In
particular, we have no need to say what the transaction ID was, or


Initial Questions:

When running in dnsport mode, it seems we risk leaking information
about the client resolver based on which requests it makes in what
order.  Is that so?

How many round trips are we looking at here for typical use cases, and
what can we do to reduce them?  We've found that anything that adds
extra round trips to opening a connection in Tor is a real problem for
a lot of use cases, and so we should try to avoid them as much as
possible.

-- 
Nick