[tor-dev] DNS(SEC) draft update

[Bry8 Star]

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 at 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev