Delivery-Date: Sun, 05 Oct 2014 18:58:26 -0400
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,
	DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID
	autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 3188E1E0BD0;
	Sun,  5 Oct 2014 18:58:24 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 781932138A;
	Sun,  5 Oct 2014 22:58:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 365A920DCA
 for <tor-talk@lists.torproject.org>; Sun,  5 Oct 2014 22:58:16 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at eugeni.torproject.org
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id a0g94Kn5QfFm for <tor-talk@lists.torproject.org>;
 Sun,  5 Oct 2014 22:58:16 +0000 (UTC)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com
 [IPv6:2a00:1450:4010:c03::22b])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id CE6562095D
 for <tor-talk@lists.torproject.org>; Sun,  5 Oct 2014 22:58:15 +0000 (UTC)
Received: by mail-la0-f43.google.com with SMTP id mc6so3476837lab.30
 for <tor-talk@lists.torproject.org>; Sun, 05 Oct 2014 15:58:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :content-type; bh=BsL9MQR0erwtHUmEeY4+ptiRoqcna43lrVRO+J+oYlE=;
 b=ubyWdAqkXpNcIVoqRTRezU4cGJqAtaG3buYy+HQvQpGZVsDF230phzW9RIGsJjjTds
 gQvfSVtKY004nKPh9JKba9x7n5QpOMvHzMXiYSifWfzrw4gtaUT947gh+Bchox8tbjif
 iSlUuXDtM19zhPTatFJiHZ+ymUN7xkCLAi36AoxfX4cNKFnbiX8GGM6Zf7XoCVBX/AWD
 mnJS8C8UE22KQDhwO9sODEO5D97tfWlxbZ5ZRcNuSQZid/tdAhIAXzqfhAqR6bCWahDi
 mq20q8QoV7vR7IQ2IEcvc24vIDnL8SNuRRz7co5Xf7olvFWATOfooGNlZ1+udv7nx4BC
 ISGw==
MIME-Version: 1.0
X-Received: by 10.152.4.165 with SMTP id l5mr21134779lal.49.1412549890909;
 Sun, 05 Oct 2014 15:58:10 -0700 (PDT)
Received: by 10.112.156.225 with HTTP; Sun, 5 Oct 2014 15:58:10 -0700 (PDT)
In-Reply-To: <5431BBFC.9000101@gmail.com>
References: <CABEFZyxd2h5+OoPrQ=3_SX_8Lwa5a1cH4tKCebnVpb8sjtjuaA@mail.gmail.com>
 <CABEFZyxmLnG1ASNstFZ48OZF1hzSDDkGDE_W4iOkkmKSyxcxww@mail.gmail.com>
 <5427A44D.9060108@gmail.com>
 <CAJVRA1Rz4uVsXTLDm3s+Nxa-uC8efUKM221i4L9rmihODEr+-A@mail.gmail.com>
 <5431BBFC.9000101@gmail.com>
Date: Sun, 5 Oct 2014 15:58:10 -0700
Message-ID: <CAJVRA1TfkvusMFCW0JVVd7hqt9L8mbO0CEuRdkkszjhh3=SzXQ@mail.gmail.com>
From: coderman <coderman@gmail.com>
To: tor-talk@lists.torproject.org
Subject: Re: [tor-talk] Hidden Services - how to implement something like
 Round Robin DNS?
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

On 10/5/14, Jeremy Rand <biolizard89@gmail.com> wrote:
> ...
> Any chance you could provide more details on what you're using?  Last
> I heard the only Namecoin resolvers that handle Tor/I2P services were
> FreeSpeechMe and NMCSocks; FreeSpeechMe doesn't handle round-robin,
> and I'm pretty sure NMCSocks doesn't either.


i can describe how to build it; as this is not conforming DNS
protocol.  perhaps one day re-distributable, or secondary sourced...

---

this configuration is specifically to avoid hotspots with singular
onion hostnames, of any sort. currently this is brittle if you are
"unlucky".

this configuration is specifically oriented around transparent Tor
proxy use, with AutoMapHostsOnResolve and a private address space
routed when internal names resolve.

this configuration is specifically designed to co-operate with other
services, like i2p eep sites on different ranges, and ORCHID mappings
into IPv6.


then,

use mostly stock namecoind - you may want to use a "mod" to monitor
.bit resolutions for current status, and trigger updates as needed;
multi-onion names are simply published under alias: and the list is
priority ordered onions.

the resolution is performed by a modified powerdns authoritative and
local caching resolver pair. see https://github.com/PowerDNS/pdns

the authoritative is used to implement a .hidden alias that provides
the mapping across .onion (or other) addresses which are then cached
via the local resolver, also configured in /etc/resolv.conf as the
only resolver. (12.0.0.1:53)

the authoritative pipe-backend like backend does the work. (i use
shared memory mapped pages)

when a request <name>.hidden (e.g. peertech.hidden arrives, the
resolver back-end queries local bitcoind for alias:. the local DNSPort
is queried for each onion in the alias list in parallel, if not cached
[see addendum],

the list of ordered [see adendum] addresses is returned as DNS RR with
modest / adaptive expiry to the requester.

the client, assuming transparent routable path, then connects any IPv4
or IPv6 capable client to endpoint as desired. this also works for TCP
multi-path with some additional tweaks ;)


best regards,
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

