If an Unbound type of DNSSEC/validating resolver exist on end-user's (tor proxy user's) computer, then, it can be configured to prevent accidental dns leaks from any apps on that computer, by using unbound configuration command-lines like: local-zone: "onion." refuse local-zone: "exit." refuse local-zone: "noconnect." refuse so having an unbound on tor proxy user's side, has some benefit.
Unbound can have configuration commandline, like this: outgoing-interface: 192.168.0.10 The Network interface Adapater which is connected to Internet, should be configured to have a fixed ip, like 192.168.0.10, and that needs to be specified on outgoing-interface, so that Unbound can send queries thru such outgoing-interface. Normally at least those who uses computer for both Anonymity and Private purpose they can use fix net-adapter ip. Unbound usually uses different set of ports from that outgoing-interface IP address, to connect with different DNS server's DNS port. Unbound has option to use 1 outgoing port (from that outgoing-interface), but that will open it up for some other vulnerabilities. Unbound also has option to use a range of ports from that outgoing interface. So if tor can have a Transparent Listenning IP address (without any fixed/single port), then in Unbound, tor's transparent ip can be specified as outgoing. And that should work fine, for those who uses the VM or the computer only for Anonymity purpose. But i have failed to find such an option in Tor. If a transparent listenning ip address (able to listen on all ports) is too hard to code, or does not exist currently, then at least this feature should be added in tor, which at least be able to listen on a range of ports (if not the entire ports 1~65535), then that range can be pre-specified in Unbound. For example, this configuration command-line will use a range of 4096 ports only: outgoing-port-permit: 52000-56096 And if few ports in it are needed to be avoid, if used by other server programs or so in that computer, then something similar can be added in Unbound: outgoing-port-avoid: "52010,52011"
If an unbound configuration is using only one forward-zone command (for root zone, which is forward-zone: name: "." Then, 1 port based transparent proxy is useful. but, most unbound configuration needs more than one: forward-zone: name: "domain/TLD" forward-addr:/forward-host: stub-zone: name: "domain/TLD" stub-addr:/stub-host: In a multi stub/forwarding case, listenning to the entire port range or certain portion of entire port range from the outgoing interface ip address is needed.
In above cases a tor proxy user who is using properly configured unbound, does not need to use tor exit node's dns resolver. first-time accessing a site will have some delay, once its in the cache (on unbound on tor proxy user's computer) from 2nd query and so on it will be very fast, as no need to goto the exit-node for the answer.
If tor exit node has a recursive DNSSEC supported resolver, and if that can be used by the tor proxy user's unbound, then that will speed up dns res as well.
But if, tor proxy user does not have unbound, (which is many user's case), and using tor-exit-node's dnssec supported resolver for the local apps, then each/every query will get answer from exit-node's dns cache, will need to travel thru two/three middle-nodes, twice, once for asking, once for receiving answer, so it will be slower than other two scenario. To counter it, tor itself should also contain a dns cache that supports DNSSEC, acting as validating stub resolver for the local apps which will need use DNSSEC queries.
Google Public DNS, permanently stores user's certain information. There are other DNSSEC supported validating recursive dns servers/resolvers which respects Anonymity and Privacy.
-- Bry8Star. Sep 16, 2012. 03-30pm. utc.
On 8/22/2012 8:44 AM, Ondrej Mikle wrote:
On 08/20/2012 02:43 AM, Mike Perry wrote:
Thus spake Ondrej Mikle (ondrej.mikle@gmail.com):
I've revised the DNS draft, attaching it. In section 4 there are some options for integration with libunbound, but each of them requires some work with the stock libunbound code.
I'm not a DNS expert, but I have a couple preliminary requests/questions.
First, can you provide a section in the proposal on the analysis of the number of round trips over Tor for different request scenarios? If you offload full DNS responsibility to the client, certain query behaviors are going to be better than others with respect to the number of round trips over Tor. We're going to want to minimize these round trips, especially if we decide we want to rely on DNSsec/DANE for everything. Clients may also want to use this information to try to intelligently decide cases where we don't want to do full DNSsec queries and revert to the oldstyle SOCKS4A.
Added section 8 to the draft with a "common" and "extreme" example. Validation still would be done at both exit and client: client can't trust the AD bit from exit and exit must implement own recursive resolver via libunbound as ISP's resolvers often won't work with DNSSEC, the problem is usually in fetching DS records.
Second (and related), is it totally insane to map some sort of magic IP to "foward this query the local exit node resolver" so that the client can easily get DNS(sec) perspectives from each exit node's resolver caches? This might both minimize round trips for clients who don't want to either hardcode 8.8.8.8 or do full recursive resolves against the root servers. On the other hand, it might complicate query handling on the exit side and also introduce weird cache/poisoning attacks?
It's actually quite interesting idea, though not sure how to map a local 127.0.0./8 IP to a specific exit. If the exit changes inbetween queries (new circuit), should the client know somehow?
I also thought about "most lightweight" implementation which would just use ldns library on the exit's side - client would employ the "magic IP" as forwarder for local standalone unbound daemon. But it breaks on the inability of ISPs' resolvers to fetch DS records mentioned above.
For the perspective it should be noted that many CDNs and load balancers use short TTLs in the range 5-30, two subsequent queries may return different results.
Ondrej
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev