Re: [tor-dev] DNS/DNSSEC resolving in Tor (PoC implementation)

[Watson Ladd <watsonbladd@xxxxxxxxx>]

On Thu, Jan 26, 2012 at 3:42 PM, Ondrej Mikle <ondrej.mikle@xxxxxxxxx> wrote:
> Hi,
>
> I decided to give it a shot in implementing full DNS/DNSSEC resolution support
> for Tor, here's the branch:
>
> https://github.com/hiviah/tor
>
> ATM the biggest limitation is that reply DNS packet must fit in a single cell
> (i.e. max size is RELAY_PAYLOAD_SIZE).
>
> How it's implemented:
>
> There's new command SOCKS_COMMAND_RESOLVE_FULL for SOCKS interface and new cells
> RELAY_COMMAND_RESOLVE(D)_FULL. The RESOLVE_FULL cell contains query string and
> RR-type, RESOLVED_FULL just the DNS packet in wire format.
>
> Resolving is implemented via libunbound on the relay's side, ldns parses packet
> on client's side.
>
> The tor-resolve now uses the new SOCKS command and accepts -t parameter with
> RR-type (numeric, default 1 - RR-type 'A'), e.g.:
>
> ./src/tools/tor-resolve -t 28 lupa.cz localhost:10050
>
> Packet size: 319
> Flags: qr: 1, aa: 0, tc: 0, rd: 1, cd: 0, ra: 1, ad: 1
> -- Rcode: NOERROR
> -- Opcode: QUERY
> -- Question section
> lupa.cz. Â Â Â ÂIN Â Â ÂAAAA
> -- Answer section
> lupa.cz. Â Â Â Â600 Â Â IN Â Â ÂAAAA Â Â2001:67c:68::7b
> lupa.cz. Â Â Â Â600 Â Â IN Â Â ÂRRSIG Â AAAA 5 2 600 20121022235305 20111023235305 8130 lupa.cz.
> wFdVqKCEh4Nmac3v5K9y6HT+aIBAtF4Q9QIqHjlAl/ljp4m5TKkgKCF083zFTMh0LqfwdODfQdSNTKAwO55hyw==
> -- Authority section
> lupa.cz. Â Â Â Â600 Â Â IN Â Â ÂNS Â Â Âns.iinfo.cz.
> lupa.cz. Â Â Â Â600 Â Â IN Â Â ÂNS Â Â Âns6.adminit.cz.
> lupa.cz. Â Â Â Â600 Â Â IN Â Â ÂRRSIG Â NS 5 2 600 20121022235305 20111023235305 8130 lupa.cz.
> SpqkpBlK1dzrfACHh3yfUp01Vr/w9qzVYQms4RDXNQZW1Hwr5WYMHIuGrFEgOOrjyg1vB01HENXJf4i2ISx51g==
> -- Additional section
>
>
> Other implementation notes:
> - some checks like whether private address is resolved are missing (also a
> whitelist of allowed RR-types might be implemented)
> - in the SOCKS5 request, RR-type is hacked onto port number
> - in SOCKS5 reply, high byte of length is hacked onto SOCKS5 reserved byte
> - libunbound supports async resolving, for now synchronous is used
> - there are more details, grep FIXDNS in code
> - Makefile.am's have -lldns and -lunbound hardwired
> - new code may not be pretty at some places (getting to know Tor code)
I've got a more basic question: does the OP get enough information to
validate the DNSSEC data, or does it have to trust the OR? I don't
quite know enough to tell from the above.
Sincerely,
Watson Ladd



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither Liberty nor Safety."
-- Benjamin Franklin
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev