Saibato
commented
4 years ago The Tor socks proxy can not return SRV records if u ask to resolve a seeder name,, so u get with high probability only the first entry from the DNS call the exit node does or a faked one from a rogue exit and not a list of addresses we used to get from the UDP call.
The Tor socks proxy will just return an open TCP socket to the first A or AAAA entry the exit found by his DNS call. so unless u don't know exactly the SRV name ( derived from the node id) u cant use V3 addresses since they can not be easy mapped in in ipv6 address returns. ( btw that was what i had preferred for core instead of ADDRv2 since we could have mapped one V3 address in three AAAA answers and use seemingly the old DNS way to seed, now we have BIP155 and are forced to use direct node calls or HTTPS what identify us like a cookie)
But if u know the SRV or V3 address name u could also direct call the node and stay in the Tor net and never exit Tor.
So, if we trust seeders we could use there fixed V3 addresses they give us hard coded like there fqdn in bitcoin core or in our case the SRV name that encoded the v3 and call one of them. by chance. And find other nodes by the gossip.
Alternatively u could use a service like https://developers.cloudflare.com/1.1.1.1/fun-stuff/dns-over-tor but that in combination with https make not much sense for privacy, since https can identify u like a cookie does. And cloudfare could answer anything, so...
But if the goal is to get random private seeds and the seeders should not know they are called, I guess any use of DNS over Tor or else is not the best idea, or I change Tor a bit and implement in The socks service SRV returns.
case PROXY_SOCKS5_WANT_CONNECT_OK:
/* response is variable length. BND.ADDR, etc, isn't needed
* (don't bother with buf_pullup()), but make sure to eat all
* the data used */
/* wait for address type field to arrive */
if (datalen < 4)
return 0;
switch (data[3]) {
case 0x01: /* ip4 */
addrlen = 4;
break;
case 0x04: /* ip6 */
addrlen = 16;
break;
case 0x03: /* fqdn (can this happen here?) */
if (datalen < 5)
return 0;
addrlen = 1 + data[4];
break;
default:
*reason = tor_strdup("invalid response to connect request");
return -1;
}
-- fqdn (can this happen here?) That i could maybe change. But what would be my incentive to do that?
ZmnSCPxj
Currently we just use
dig. The big issue withdigis that it has no option I can find where it can be asked to do a DNS-over-TCP query via a SOCKS5 proxy (i.e. tor). It can work withtorifybut that increases our dependencies, and does not necessarily work for all proxy settings.We may want to implement DNS-over-TCP directly, if only because we can tunnel that over a SOCKS5 proxy so that DNS seed queries can hide the IP of the user at least. DNS-over-TCP is preferred if we have a Tor proxy since Tor will do end-to-end encryption anyway, but we also want to avoid DNS attacks even if the user does not use Tor, which is why we might want to use DNS-over-HTTPS instead. However, I have no idea if lseed supports HTTPS, or if using a recursive resolver will let me paper over that lack if lseed does not support DNS-over-HTTPS. Probably @cdecker knows.
For now CLBOSS uses
digwith atorifyif it works, and ifalways-use-proxyis set, requirestorifyalways.