[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Special-use-TLD support
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.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev