Re: [tor-talk] Hidden Services - how to implement something like Round Robin DNS?

[coderman <coderman@xxxxxxxxx>]

On 10/5/14, Jeremy Rand <biolizard89@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk