Compare commits
1 Commits
master
...
dns-applic
| Author | SHA1 | Date | |
|---|---|---|---|
| 9ca8429af7 |
505
i2p2www/pages/site/docs/applications/dns.html
Normal file
505
i2p2www/pages/site/docs/applications/dns.html
Normal file
@ -0,0 +1,505 @@
|
||||
|
||||
{% extends "global/layout.html" %}
|
||||
{% block title %}{% trans %}DNS over I2P{% endtrans %}{% endblock %}
|
||||
{% block lastupdated %}{% trans %}October 2021{% endtrans %}{% endblock %}
|
||||
{% block accuratefor %}1.5.0/0.9.51{% endblock %}
|
||||
{% block content %}
|
||||
|
||||
<p>{% trans -%}
|
||||
This content was adapted from content written by i2pd contributor Acetone. It
|
||||
was translated by [TODO: an unknown third party], copied from <a
|
||||
href="https://rucore.net/en/dns-over-i2p-true-privacy-of-dns-queries-2/">RuCore.
|
||||
net</a>,
|
||||
and lightly edited by idk. The original appeared at:
|
||||
<a href="https://habr.com/ru/company/itsoft/blog/572140/">habr.com</a>.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
Today it is difficult to surprise someone with the terms DoH (DNS over HTTPS),
|
||||
DoT (DNS over TLS) and other crypto-gadgets for DNS. If someone just jumped on a
|
||||
train and doesn’t understand what this is about, DNS (Domain Name System) is a
|
||||
domain name system that each of us uses hundreds and thousands of times during
|
||||
the day. All human-readable names like habr.com, cia.gov and others lead to a
|
||||
specific IP address, which a computer can find out by contacting special
|
||||
servers.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
Large enterprises, home Internet providers, as well as anyone who wants to have
|
||||
their own DNS server, because the DNS server is very simple in its device. Among
|
||||
other considerations, their servers are deployed for reasons of additional
|
||||
privacy, because the administrator of a foreign server, to which we turn, will
|
||||
see our address and will know which web resource we decided to visit.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
The DNS protocol is old (~ 1987), so it does not provide any encryption. All DNS
|
||||
requests and responses go over the network in the clear, so in the initial
|
||||
variation, not only the administrator of the DNS server, but also the operators
|
||||
of all intermediate nodes through which traffic passes, can spy on the user.
|
||||
Modern solutions like DNSCrypt, DNS over HTTPS and the like solve the
|
||||
problem of
|
||||
intercepting information along the way, as they encrypt DNS requests from the
|
||||
user to the server and in the opposite direction. But! The protocols that
|
||||
encrypt traffic do not solve one important issue – the analysis of all requests
|
||||
on the side of the server itself, which still sees both the request itself and
|
||||
the IP address from which it came. The DNSCrypt project has an additional gadget
|
||||
for that, but I was not impressed by this layering on a three-story pie. Perhaps
|
||||
because I have my own pie … I will be glad to adequate criticism, but I hope
|
||||
there will be no stupid comments that every person on the planet needs to have
|
||||
his own personal DNS server to maintain privacy.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
DNS over the anonymous network I2P is a concept in which DNS requests are
|
||||
encrypted, but also: firstly, the server administrator has no idea about the
|
||||
real IP address of the user; secondly, the user does not know the location of
|
||||
the server he is accessing (also good, in order to avoid possible pressure on
|
||||
the administrator). DNS over I2P, or DoI2P (or DoI at all) is a very
|
||||
entertaining variation on the use of hidden networks, which we will now take a
|
||||
closer look at.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<h2>{% trans %}Theory{% endtrans %}</h2>
|
||||
|
||||
<p>{% trans -%}The standard calls for a DNS server to run on port 53 (websites,
|
||||
for example, run on standard ports 80 and 443), but what is more interesting in
|
||||
this case is what transport protocol does DNS use. This information is required
|
||||
to create suitable tunnels over the I2P network.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
An I2P router that provides access to the I2P network provides proxies of the
|
||||
SOCKS and HTTP types at the local address. In most cases, it is a proxy that is
|
||||
used to work with the network, but to fine-tune the connection through a hidden
|
||||
network, separate tunnels are created in a special configuration file. Tunnels
|
||||
can be server and client tunnels. Their essence lies in accepting connections
|
||||
from a hidden network to a designated local port of some service, for
|
||||
example, a
|
||||
web server, or in transferring client connections from a local tunnel
|
||||
address to
|
||||
a hidden network. Tunnels are divided into two main types: TCP and UDP.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
The main working protocol of DNS is UDP, but the standard provides for the
|
||||
transfer of some information over the TCP protocol. This means that you need to
|
||||
create two server and two client tunnels: the first for UDP connections, the
|
||||
second for TCP.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<h2>{% trans %}Server Setup{% endtrans %}</h2>
|
||||
|
||||
<p>{% trans -%}
|
||||
The example uses a dnsmasq server that is extremely easy to install and
|
||||
configure, but you can use any server you like. The simplest configuration
|
||||
option for this server looks like this:
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<pre><code>
|
||||
port=53
|
||||
listen-address=256.257.258.259
|
||||
domain-needed
|
||||
bogus-priv
|
||||
server=8.8.8.8
|
||||
</code></pre>
|
||||
|
||||
|
||||
<p>{% trans -%}
|
||||
This configuration means that absolutely all requests will be sent to the
|
||||
address 8.8.8.8. Such a server does not make much sense, but as a layer of
|
||||
anonymity and just an example for an article – that’s it. The server accepts
|
||||
requests to an IP address 256.257.258.259, port 53. The fictitious IP address
|
||||
serves only as an example, as if depicting a pre-existing DNS server accessible
|
||||
from the regular Internet. In fact, you can use a local address 127.0.0.1 and
|
||||
any port at your discretion, if you serve users exclusively through a hidden
|
||||
network.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
To make the DNS server accessible from I2P, you need to create server tunnels.
|
||||
I am using i2pd on Debian 10. The default tunnels config file is in the path
|
||||
/etc/i2pd/tunnels.conf. Below is the minimum configuration required to work.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<pre><code>
|
||||
[DNS-TCP]
|
||||
type = server
|
||||
host = 256.257.258.259
|
||||
port = 53
|
||||
keys = hidden-dns.dat
|
||||
|
||||
[DNS-UDP]
|
||||
type = udpserver
|
||||
host = 256.257.258.259
|
||||
address = 256.257.258.259
|
||||
port = 53
|
||||
keys = hidden-dns.dat
|
||||
</code></pre>
|
||||
|
||||
<p>{% trans -%}
|
||||
Notice the line address in the UDP tunnel section. This is a necessary
|
||||
parameter
|
||||
for a non-local address, which tells i2pd from which address incoming requests
|
||||
from the hidden network will come from. This parameter is required for UDP
|
||||
tunnels. It can be omitted if an address is used 127.0.0.1.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
The parameter keys specifies the keys that form the intranet address. By
|
||||
default, they are in the directory /var/lib/i2pd. If the file is not found, a
|
||||
new one is created.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
Restart i2pd for the changes to take effect. You can see the I2P tunnel address
|
||||
in the web console, under the “I2P Tunnels” tab. In my case, it is
|
||||
dnsgzxkak4zlrrs5tfh42ob57iley4xrp7srrltn2j2yl2ynbiaq.b32.i2p.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<h2>{% trans %}Client Setup{% endtrans %}</h2>
|
||||
|
||||
<p>{% trans -%}
|
||||
In my case, the client machine also uses i2pd and the Debian operating system,
|
||||
the tunnels file is located in the same place as on the server –
|
||||
/etc/i2pd/tunnels.conf. The client configuration might look like this:
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<pre><code>
|
||||
[DNS-CLIENT-TCP]
|
||||
type = client
|
||||
address = 127.0.0.1
|
||||
port = 35353
|
||||
inbound.length = 2
|
||||
outbound.length = 2
|
||||
destination = dnsgzxkak4zlrrs5tfh42ob57iley4xrp7srrltn2j2yl2ynbiaq.b32.i2p
|
||||
keys = transient-dns
|
||||
|
||||
[DNS-CLIENT-UDP]
|
||||
type = udpclient
|
||||
address = 127.0.0.1
|
||||
port = 35353
|
||||
destination = dnsgzxkak4zlrrs5tfh42ob57iley4xrp7srrltn2j2yl2ynbiaq.b32.i2p
|
||||
keys = transient-dns
|
||||
</code></pre>
|
||||
|
||||
<p>{% trans -%}
|
||||
The parameters inbound.length and outbound.length are responsible for the
|
||||
length of the incoming and outgoing tunnels. By default, they are three hops,
|
||||
but I have reduced these values to two to minimize latency a little.
|
||||
Similar parameters are applicable for server tunnels as well. Additional
|
||||
parameters are specified only in the first section, since the very first block
|
||||
defines the parameters that apply to all tunnels using the same key (in my
|
||||
case, this transient-dns). Keys starting with a word transient are temporary
|
||||
– after each restart of i2pd, the client will contact the server from a new
|
||||
intranet address.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
For new tunnels to be created, you need to restart i2pd. On this it may seem
|
||||
that the deed is done. But no, there is one more nuance left.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
The file responsible for configuring DNS on my operating system (Debian 10)
|
||||
does not support specifying a port. Only the IP address of the server can be
|
||||
specified. All requests will be sent to the port 53, but our tunnel is hanging
|
||||
on the port 35353. If you specify a port in the client tunnels 53, an error
|
||||
will occur and no tunnels will be created, because all ports below 1024 are
|
||||
privileged – reserved for special needs. Only the superuser (root) can start
|
||||
the service on this port, and i2pd, like other applications, works without
|
||||
superuser rights. Take a deep breath before running i2pd (or some other
|
||||
third-party software) as root, and then read on.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<h2>{% trans %}Epilogue{% endtrans %}</h2>
|
||||
|
||||
<p>{% trans -%}
|
||||
{%- endtrans %}</p>
|
||||
|
||||
|
||||
|
||||
<h2>{% trans %}Additional Information{% endtrans %}</h2>
|
||||
<ul>
|
||||
<li></li>
|
||||
</ul>
|
||||
|
||||
|
||||
{% endblock %}
|
||||
idk@lib14:~/Workspace/GIT_WORK/i2p.www$ find . -name dns.html -exec bash -c
|
||||
"cat {} | fold -w 80 -s - | tee {} " \;
|
||||
{% extends "global/layout.html" %}
|
||||
{% block title %}{% trans %}DNS over I2P{% endtrans %}{% endblock %}
|
||||
{% block lastupdated %}{% trans %}October 2021{% endtrans %}{% endblock %}
|
||||
{% block accuratefor %}1.5.0/0.9.51{% endblock %}
|
||||
{% block content %}
|
||||
|
||||
<p>{% trans -%}
|
||||
This content was adapted from content written by i2pd contributor Acetone. It
|
||||
was machine translated, copied from <a
|
||||
href="https://rucore.net/en/dns-over-i2p-true-privacy-of-dns-queries-2/">RuCore.
|
||||
net</a>,
|
||||
and lightly edited by idk.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
Today it is difficult to surprise someone with the terms DoH (DNS over HTTPS),
|
||||
DoT (DNS over TLS) and other crypto-gadgets for DNS. If someone just jumped on a
|
||||
train and doesn’t understand what this is about, DNS (Domain Name System) is a
|
||||
domain name system that each of us uses hundreds and thousands of times during
|
||||
the day. All human-readable names like habr.com, cia.gov and others lead to a
|
||||
specific IP address, which a computer can find out by contacting special
|
||||
servers.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
Large enterprises, home Internet providers, as well as anyone who wants to have
|
||||
their own DNS server, because the DNS server is very simple in its device. Among
|
||||
other considerations, their servers are deployed for reasons of additional
|
||||
privacy, because the administrator of a foreign server, to which we turn, will
|
||||
see our address and will know which web resource we decided to visit.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
The DNS protocol is old (~ 1987), so it does not provide any encryption. All DNS
|
||||
requests and responses go over the network in the clear, so in the initial
|
||||
variation, not only the administrator of the DNS server, but also the operators
|
||||
of all intermediate nodes through which traffic passes, can spy on the user.
|
||||
Modern solutions like DNSCrypt, DNS over HTTPS and the like solve the problem of
|
||||
intercepting information along the way, as they encrypt DNS requests from the
|
||||
user to the server and in the opposite direction. But! The protocols that
|
||||
encrypt traffic do not solve one important issue – the analysis of all requests
|
||||
on the side of the server itself, which still sees both the request itself and
|
||||
the IP address from which it came. The DNSCrypt project has an additional gadget
|
||||
for that, but I was not impressed by this layering on a three-story pie. Perhaps
|
||||
because I have my own pie … I will be glad to adequate criticism, but I hope
|
||||
there will be no stupid comments that every person on the planet needs to have
|
||||
his own personal DNS server to maintain privacy.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
DNS over the anonymous network I2P is a concept in which DNS requests are
|
||||
encrypted, but also: firstly, the server administrator has no idea about the
|
||||
real IP address of the user; secondly, the user does not know the location of
|
||||
the server he is accessing (also good, in order to avoid possible pressure on
|
||||
the administrator). DNS over I2P, or DoI2P (or DoI at all) is a very
|
||||
entertaining variation on the use of hidden networks, which we will now take a
|
||||
closer look at.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<h2>{% trans %}Theory{% endtrans %}</h2>
|
||||
|
||||
<p>{% trans -%}The standard calls for a DNS server to run on port 53 (websites,
|
||||
for example, run on standard ports 80 and 443), but what is more interesting in
|
||||
this case is what transport protocol does DNS use. This information is required
|
||||
to create suitable tunnels over the I2P network.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
An I2P router that provides access to the I2P network provides proxies of the
|
||||
SOCKS and HTTP types at the local address. In most cases, it is a proxy that is
|
||||
used to work with the network, but to fine-tune the connection through a hidden
|
||||
network, separate tunnels are created in a special configuration file. Tunnels
|
||||
can be server and client tunnels. Their essence lies in accepting connections
|
||||
from a hidden network to a designated local port of some service, for example, a
|
||||
web server, or in transferring client connections from a local tunnel address to
|
||||
a hidden network. Tunnels are divided into two main types: TCP and UDP.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
The main working protocol of DNS is UDP, but the standard provides for the
|
||||
transfer of some information over the TCP protocol. This means that you need to
|
||||
create two server and two client tunnels: the first for UDP connections, the
|
||||
second for TCP.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<h2>{% trans %}Server Setup{% endtrans %}</h2>
|
||||
|
||||
<p>{% trans -%}
|
||||
The example uses a dnsmasq server that is extremely easy to install and
|
||||
configure, but you can use any server you like. The simplest configuration
|
||||
option for this server looks like this:
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<pre><code>
|
||||
port=53
|
||||
listen-address=256.257.258.259
|
||||
domain-needed
|
||||
bogus-priv
|
||||
server=8.8.8.8
|
||||
</code></pre>
|
||||
|
||||
|
||||
<p>{% trans -%}
|
||||
This configuration means that absolutely all requests will be sent to the
|
||||
address 8.8.8.8. Such a server does not make much sense, but as a layer of
|
||||
anonymity and just an example for an article – that’s it. The server accepts
|
||||
requests to an IP address 256.257.258.259, port 53. The fictitious IP address
|
||||
serves only as an example, as if depicting a pre-existing DNS server accessible
|
||||
from the regular Internet. In fact, you can use a local address 127.0.0.1 and
|
||||
any port at your discretion, if you serve users exclusively through a hidden
|
||||
network.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
To make the DNS server accessible from I2P, you need to create server tunnels.
|
||||
I am using i2pd on Debian 10. The default tunnels config file is in the path
|
||||
/etc/i2pd/tunnels.conf. Below is the minimum configuration required to work.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<pre><code>
|
||||
[DNS-TCP]
|
||||
type = server
|
||||
host = 256.257.258.259
|
||||
port = 53
|
||||
keys = hidden-dns.dat
|
||||
|
||||
[DNS-UDP]
|
||||
type = udpserver
|
||||
host = 256.257.258.259
|
||||
address = 256.257.258.259
|
||||
port = 53
|
||||
keys = hidden-dns.dat
|
||||
</code></pre>
|
||||
|
||||
<p>{% trans -%}
|
||||
Notice the line address in the UDP tunnel section. This is a necessary
|
||||
parameter
|
||||
for a non-local address, which tells i2pd from which address incoming requests
|
||||
from the hidden network will come from. This parameter is required for UDP
|
||||
tunnels. It can be omitted if an address is used 127.0.0.1.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
The parameter keys specifies the keys that form the intranet address. By
|
||||
default, they are in the directory /var/lib/i2pd. If the file is not found, a
|
||||
new one is created.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
Restart i2pd for the changes to take effect. You can see the I2P tunnel address
|
||||
in the web console, under the “I2P Tunnels” tab. In my case, it is
|
||||
dnsgzxkak4zlrrs5tfh42ob57iley4xrp7srrltn2j2yl2ynbiaq.b32.i2p.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<h2>{% trans %}Client Setup{% endtrans %}</h2>
|
||||
|
||||
<p>{% trans -%}
|
||||
In my case, the client machine also uses i2pd and the Debian operating system,
|
||||
the tunnels file is located in the same place as on the server –
|
||||
/etc/i2pd/tunnels.conf. The client configuration might look like this:
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<pre><code>
|
||||
[DNS-CLIENT-TCP]
|
||||
type = client
|
||||
address = 127.0.0.1
|
||||
port = 35353
|
||||
inbound.length = 2
|
||||
outbound.length = 2
|
||||
destination = dnsgzxkak4zlrrs5tfh42ob57iley4xrp7srrltn2j2yl2ynbiaq.b32.i2p
|
||||
keys = transient-dns
|
||||
|
||||
[DNS-CLIENT-UDP]
|
||||
type = udpclient
|
||||
address = 127.0.0.1
|
||||
port = 35353
|
||||
destination = dnsgzxkak4zlrrs5tfh42ob57iley4xrp7srrltn2j2yl2ynbiaq.b32.i2p
|
||||
keys = transient-dns
|
||||
</code></pre>
|
||||
|
||||
<p>{% trans -%}
|
||||
The parameters inbound.length and outbound.length are responsible for the
|
||||
length of the incoming and outgoing tunnels. By default, they are three hops,
|
||||
but I have reduced these values to two to minimize latency a little.
|
||||
Similar parameters are applicable for server tunnels as well. Additional
|
||||
parameters are specified only in the first section, since the very first block
|
||||
defines the parameters that apply to all tunnels using the same key (in my
|
||||
case, this transient-dns). Keys starting with a word transient are temporary
|
||||
– after each restart of i2pd, the client will contact the server from a new
|
||||
intranet address.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
For new tunnels to be created, you need to restart i2pd. On this it may seem
|
||||
that the deed is done. But no, there is one more nuance left.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
The file responsible for configuring DNS on my operating system (Debian 10)
|
||||
does not support specifying a port. Only the IP address of the server can be
|
||||
specified. All requests will be sent to the port 53, but our tunnel is hanging
|
||||
on the port 35353. If you specify a port in the client tunnels 53, an error
|
||||
will occur and no tunnels will be created, because all ports below 1024 are
|
||||
privileged – reserved for special needs. Only the superuser (root) can start
|
||||
the service on this port, and i2pd, like other applications, works without
|
||||
superuser rights. Take a deep breath before running i2pd (or some other
|
||||
third-party software) as root, and then read on.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
Remove from /etc/resolv.conf the previous DNS, so that all queries were
|
||||
exclusively through I2P, and add a single server – local: nameserver
|
||||
127.0.0.1.
|
||||
This will tell the operating system to go to the address for name-to-address
|
||||
resolution 127.0.0.1:53. It remains to ask the kernel of the system to redirect
|
||||
requests from the port 53 to 35353where our TCP / UDP tunnels hang, and then
|
||||
send responses in the opposite direction. It’s time for the iptables magic
|
||||
(sorry not the newfangled netfilter, I’m an old school magician).
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<pre><code>
|
||||
iptables -t nat -A PREROUTING -i lo -p udp – dport 53 -j REDIRECT –
|
||||
to-port 35353
|
||||
iptables -t nat -I OUTPUT -p udp -d 127.0.0.1 – dport 53 -j REDIRECT –
|
||||
to-port 35353
|
||||
iptables -t nat -A PREROUTING -i lo -p tcp – dport 53 -j REDIRECT –
|
||||
to-port 35353
|
||||
iptables -t nat -I OUTPUT -p tcp -d 127.0.0.1 – dport 53 -j REDIRECT –
|
||||
to-port 35353
|
||||
</code></pre>
|
||||
|
||||
<p>{% trans -%}
|
||||
Do you hear? Listen, this is fanfare! Check the resolving in any convenient
|
||||
way,
|
||||
I will use the utility nslookup:
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<pre><code>
|
||||
acetone@adeb:~$ nslookup habr.com
|
||||
Server: 127.0.0.1
|
||||
Address: 127.0.0.1#53
|
||||
|
||||
Non-authoritative answer:
|
||||
Name: habr.com
|
||||
Address: 178.248.237.68
|
||||
</code></pre>
|
||||
|
||||
<h2>{% trans %}Epilogue{% endtrans %}</h2>
|
||||
|
||||
<p>{% trans -%}
|
||||
During the configuration, I noticed that dnsmasq only occupies a UDP socket in
|
||||
standby mode, but I decided to leave the TCP tunnel according to the DNS
|
||||
standard, which provides for the transfer of some information over TCP. Be
|
||||
that as it may, the functionality described is perfectly observed even in
|
||||
the absence of TCP tunnels.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
The above configuration takes on average 1-2 seconds to request and respond
|
||||
to the DNS server. If your result seems too slow for you, you can reduce the
|
||||
length of the server and client tunnels to 2. There are options with tunnels
|
||||
in one transit node, but this is applicable only for devices that you do
|
||||
not worry about being compromised: for example, if your DNS is not secret ,
|
||||
the length of the tunnels can be equal to one or even zero! In this case,
|
||||
you enable the user to build a longer anonymizing tunnel from his side. The
|
||||
main thing is to do everything wisely and not be lazy to get acquainted with
|
||||
the documentation , as well as consult with knowledgeable people.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
As a demonstration (and maybe for permanent use), you can use the DNS server,
|
||||
the user configs for which are given above.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
{% endblock %}
|
||||
Reference in New Issue
Block a user