[tor-dev] Special-use-TLD support

[Sebastian G. <bastik.tor>]

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.