[tor-relays] DNS server

Thoughts thoughts at kevinsthoughts.com
Sun Apr 10 00:59:33 UTC 2022


DNS Caching (not Cash) simple does a normal lookup for an DNS domain 
requested and remembers it for some period of time so that it can answer 
from its cache of known addresses in microseconds (instead of the 
hundreds of milliseconds it might take to inquire over the internet) the 
next time that address resolution is requested.

All caching software will eventually "forget" and re-inquire, since 
addresses do change occasionally.  But think of that happening once 
every hour or four.

For example, think of a bitcoin miner setup to mine against a pool, say 
btc.viabtc.com.  The first time the miner asks for work a request is 
sent to the caching DNS server to resolve btc.viabtc.com.  The server, 
doesn't know who that is so goes upstream to the internet to its 
forwarding server, lets say 8.8.8.8, to get the answer.  That server 
responds in a, say 150 milliseconds with the answer:  172.65.233.152.  
The caching server remembers that answer and responds with it to the 
bitcoin miner who then initiates a connection to 172.64.233.152:3333 
(3333 is the port number on the server that responds to work request). 
About 2 minutes later, the miner will have completed its work and will 
request more work from btc.viabtc.com - but this time the caching server 
knows the answer and can respond in a millisecond or less with the 
answer.  So its more efficient...

Not a bit idea of your site has 1 bitcoin miner, but if it a farm, it 
might have anywhere from 100 to 100,000 bitcoin miners - that difference 
of 149 milliseconds really adds up.

With regards to "safety", I suppose... maybe.  If the google public dns 
server got hacked and instead of answering with 172.65.233.152 instead 
answered with 172.65.230.171 (a competitors pool that also runs on port 
3333), you would have the hours before the cache expired for google to 
figure it out and correct things. The "maybe" comes from the timing 
required.  If you caching dns server happened to hit googles dns server 
when it was corrupted, and google fixed things seconds later, your 
caching server would continue to respond with the wrong address until 
the entry expired.

So I'd say "Not really".  Hope the above explains why...

On 4/9/2022 7:05 PM, onionize at riseup.net wrote:
> Does Cash DNS give some advantages in safety?
> On 2022-04-08 08:06, Thoughts wrote:
>> Note that any dns caching software would help, unbound is just one
>> popular one.  dnsmasq is another.  In fact, if you wanted to, you
>> could use the full bind package and configure it for caching and
>> forwarding, although that would be a bit of overkill.  Once you
>> install caching software, make sure your /etc/resolv.conf or
>> equivalent is pointing to 127.0.0.1 as its first reference.
>> On 4/8/2022 2:04 AM, abuse--- via tor-relays wrote:
>>
>>>  From my point of view, it's mostly about reliability. You can use
>>> the hoster's DNS resolver, but be aware that a high-bandwidth exit
>>> asks a lot of DNS requests. Not every hoster's DNS resolver might be
>>> able to cope with it and as a result your exit might give users a
>>> poor experience.
>>>
>>> Best Regards,
>>>
>>> Kristian
>>>
>>> Apr 8, 2022, 07:20 by onionize at riseup.net:
>>>
>>>> I was setting up exit nodes and I had a question. Why is it
>>>> recommended
>>>>
>>>> to use DNS caching software Unbound? What benefits does it provide
>>>>
>>>> compared to using hoster's DNS resolver?
>>>>
>>>> _______________________________________________
>>>>
>>>> tor-relays mailing list
>>>>
>>>> tor-relays at lists.torproject.org
>>>>
>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>> _______________________________________________
>>> tor-relays mailing list
>>> tor-relays at lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>> _______________________________________________
>> tor-relays mailing list
>> tor-relays at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


More information about the tor-relays mailing list