Re: [tor-dev] Tor and DNS

[Ondrej Mikle <ondrej.mikle@xxxxxxxxx>]

On 02/08/2012 02:59 AM, Nick Mathewson wrote:
> On Tue, Feb 7, 2012 at 7:33 PM, Ondrej Mikle <ondrej.mikle@xxxxxxxxx> wrote:
> 
> I think if we want an extra field in the future, we want to put it
> after the end of the response (that is, after total_len), rather than
> having it be optionally in every cell.

OK.

>> That also means AXFR/IXFR would be off limits (I'm OK with that).
> 
> Me too.

Without AXFR/IXFR we could limit total_len to 2 octets.

>> "End" bit would work, but I find it easier to know beforehand how much data to
>> expect - we don't have to worry about realloc and memory fragmentation. Client
>> could deny request if claimed total_length is too high right away (or later if
>> OR keeps pushing more data than claimed).
> 
> Hm. If so, maybe total_len only needs to be in the first cell then.

True. Though I'd prefer it in every DNS_RESPONSE cell, I find "firm" cell
structure less error-prone (saving 2 octets per cell does not seem so
substantial). The total_length in following cells belonging to the same StreamID
could be just ignored.

Just to sum up the changes of DNS_RESPONSE, the new structure would be:

    total length (2 octets)
    data (variable)

>> So no additional overhead for RELAY_BEGIN.
>>
>> Case of DNSPort queries - example for addons.mozilla.org with empty cache:
> 
> Hang on, is each one of these a *round trip*? I don't think so.  That
> is, you don't need to get the answer for the A query before you do the
> other lookups; the client can launch them all at once.

libunbound tries to parallelize requests as much as possible, sending bunch of
requests first, continuing as the responses return.

(Hm, I've just noticed that when asking a forwarder, libunbound serializes it
instead. I'll have to ask about this.)

> I wonder, do we want to add a "resolve and connect" mode to
> relay_begin, as discussed elsewhere in this thread?

Only reason I can think of being useful is for getting NSEC/NSEC3 proof that
domain does not exist. Does not seem worth the extra complexity, unless someone
thinks of better use.

Ondrej
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev