Hello,
I was interested in the project for allowing any kind of DNS support in Tor for GSoC, or, since it is late for that deadline, then also otherwise. After reading proposal 219, I have some questions.
1. A comment by NM suggests that we should specify exact behavior when generating DNS packets (line 56). Should the DNS packets not be generated as according to RFC 1035? Are there other things that need to be taken into consideration here?
2. Another comment (line 63) asks whether 496 bytes is enough for the DNS packet of a DNS_BEGIN cell. Since QNAME can be arbitrarily long, I suppose it is possible that 496 is not enough? If this seems like a reasonable concern, then maybe we could do a similar thing to the DNS_RESPONSE cells with allowing multiple cells for a single question and having a flag to indicate the last cell?
3. What would cause a DNS_BEGIN request or response to be aborted (line 105)?
4. How do we differentiate special names like .onion, .exit, .noconnect (line 145)?
5. The comments at (lines 135-143) indicate that it might not be necessary or practical to refuse requests that resolve to local addresses. This means that such queries will not be sent, but an error will be returned before sending to a DNS server?
Thanks so much. Best, Lucy
On Sun, Apr 2, 2017 at 10:20 AM, Lucille Newman newmanlucy@uchicago.edu wrote:
Hello,
I was interested in the project for allowing any kind of DNS support in Tor for GSoC, or, since it is late for that deadline, then also otherwise. After reading proposal 219, I have some questions.
- A comment by NM suggests that we should specify exact behavior when
generating DNS packets (line 56). Should the DNS packets not be generated as according to RFC 1035? Are there other things that need to be taken into consideration here?
HI!
The issue is that RFC 1035 and other DNS RFCs allow a certain amount of latitude in how DNS requests are encoded specifically. As one simple example: name compression is recommended but not required. I believe there are other examples too.
On the request side, that's bad for anonymity: we'd rather have all clients encoding their requests in the same way, so that exits can't tell them apart any more than necessary.
On the response side, I think it's okay to have different exits encode responses differently.
- Another comment (line 63) asks whether 496 bytes is enough for the DNS
packet of a DNS_BEGIN cell. Since QNAME can be arbitrarily long, I suppose it is possible that 496 is not enough? If this seems like a reasonable concern, then maybe we could do a similar thing to the DNS_RESPONSE cells with allowing multiple cells for a single question and having a flag to indicate the last cell?
That would probably be fine.
- What would cause a DNS_BEGIN request or response to be aborted (line
105)?
It might make sense to abort a request if the client realizes that the application no longer wants it -- for example, if it's happening in response to a TCP DNS request (not currently supported on the client side) and the TCP connection is closed.
I don't know if it's absolutely necessary to support that.
- How do we differentiate special names like .onion, .exit, .noconnect
(line 145)?
I think we could go with the list in addr-spec.txt in the torspec repository.
- The comments at (lines 135-143) indicate that it might not be necessary
or practical to refuse requests that resolve to local addresses. This means that such queries will not be sent, but an error will be returned before sending to a DNS server?
I think that's the intended behavior, if it makes good security sense.
Peace,
-
Lucille Newman -
Nick Mathewson