27.09.2015, 19:47 Jeff Burdges:
Hi,
I have nothing to add, but there are a few spelling mistakes that someone might want to correct before adding it to the repository.
Design
We denote by N an abstract name service supplier package. There are two steps required to integrate N safely with Tor :
Of course, N must be modified so as to (a) employ Tor for it's own
s/it's/its
traffic and (b) to use Tor in a safe way. We deem this step outside the scope of the present document since it concerns modifications to N that depend upon N's design. We caution however that peer-to-peer technologies are famous for sharing unwanted information and producing excessively distinctive traffic profiles, making (b) problematic. Another proposal seeks to provide rudementary tools to asist with (a).
s/rudementary/rudimentary s/asist/assist
We shall instead focus on modifying Tor to route some-but-not-all DNS queries to N. For this, we propose a NameService configuration option that tells Tor where to obtain the DNS record lying under some specific TLD.
Anytime Tor resolves a DNS name ending in an Special-Use TLD appearing in an NameService configuration line then Tor makes an RPC request for the name record using given UNIX domain socket or address and port.
We should allow CNAME records to refer to .onion domains, and to regular DNS names, but care must be taken in handling CNAME records that refer to Special-Use TLDs handled by NameSerice lines. Tor should reject CNAME records that refer to the .exit domains.
(I wonder if .exit is still valid, also if it is 'the' .exit instead of just .exit)
Configuration
We propose two Tor configuration options :
NameSubstitution [.]source_dnspath [.]target_dnspath NameService [.]dnspath socketspec [noncannonical] [timeout=num] [-- service specific options]We require that socketspec be either the path to a UNIX domain socket or an address of the form IP:port. We also require that that each
'that' appears twice.
*dnspath be a string conforming to RFC 952 and RFC 1123 sec. 2.1. In other words, a dnsspec consists of a series of labels separated by periods . with each label of up to 63 characters consisting of the letters a-z in a case insensitive mannor, the digits 0-9, and the
s/mannor/manor
hyphen -, but hyphens may not appear at the beginning or end of labels.
NameSubstitution rules are applied only to DNS query strings provided by the user, not CNAME results. If a trailing substring of a query matches source_dnspath then it is replaced by target_dnspath.
NameService rules route matching query to to appropriate name service
'to' appears twice, and I guess it is not correct. I fail to parse the sentence, but it might be 'matching queries' or 'a matching query'.
supplier software. If a trailing substring of a query matches dnspath, then a query is sent to the socketspec using the RPC protcol descrived
s/protcol/protocol s/descrived/described
below. Of course, NameService rules are applied only after all the NameSubstitution rules.
There is no way to know in advance if N handles cahcing itself, much
s/cahcing/caching
less if it handles caching in a way suitable for Tor. Ideally, we should demands that N return an approporaite expiration
s/approporaite/appropriate
time, which Tor can respect without harming safety or performance. If this proves problematic, then configuration options could be added to adjust Tor's caching behavior.
Seconds is the unit for the timeout option, which defaults to 60 and applies only to the name service supplier lookup. Tor DNS queries, or attempts to contact .onion addresses, that result from CNAME records should be given the full timeout alloted to standard Tor DNS queries, .onion lookups, etc.
Any text following -- is passed verbatim to the name service suppllier
s/suppllier/supplier
as service specific options, according to the RPC protocol described below.
Best regards, Sebastian G.