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.
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.
The DNS protocol is as old as the world (~ 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 this, 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.
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 even DoI) is a very entertaining variation on the use of hidden networks, which we will now consider in detail.
Theory
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 DNS uses. This information is required to create suitable tunnels over the I2P network.
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.
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.
Server
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:
Code:
port=53
listen-address=256.257.258.259
domain-needed
bogus-priv
server=8.8.8.8This 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 portraying 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.
To make the DNS server accessible from I2P, server tunnels must be created. 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.
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.datNotice 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.
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.
Restart i2pd for the changes to take effect. The I2P address of the tunnel can be seen in the web console, under the "I2P Tunnels" tab. In my case, it is dnsgzxkak4zlrrs5tfh42ob57iley4xrp7srrltn2j2yl2ynbiaq.b32.i2p.
Customer
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:
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-dnsThe 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.
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.
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.
Of The the the the Remove of the From /etc/resolv.conf the DNS for the LEO for the LEO for the LEO for LEO previous, of SO That Were all queries EXCLUSIVELY through the the the I2P, the the the and the add a single server the - 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 the old school magician).
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 35353Do you hear? Listen, this is fanfare! Check the resolving in any convenient way, I will use the utility nslookup:
Code:
acetone@adeb:~$ nslookup carder.market
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
Name: carder.market
Address: 178.248.237.68Afterword
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.
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.
As a demonstration (and maybe for permanent use), you can use the DNS server, the user configs for which are given above.
habrastorage.org
