DNS traffic. DNSCrypt – DNS traffic encryption for the paranoid. Installations use dnscrypt

Since the myth of anonymity on the Internet was dispelled, the issue of user privacy has joined the list of the most pressing ones. Not only can your online activities be tracked search engines and the websites you visit, but also your own internet service providers. Technically, this is not so difficult if DNS is issued to you by the provider, and this most often happens, everything passing through DNS traffic can be tracked by it, especially since DNS-requests are sent over an unencrypted connection.

It is clear that replacing intercepted packets will not be difficult even if you use VPN-services.

The only way to close the hole is through encryption. DNS-traffic, but for this you will need a special software, since none of operating systems does not support encryption DNS out of the box. The simplest encryption tool DNS- traffic is - small free utility, advantageously distinguished by the fact that it does not require additional settings, which means it can be used by beginners. There is a console tool - DNSCrypt Proxy, but you need to tinker with it - execute a series of commands in PowerShell, change address DNS manually and so on. Anyone who has the time and desire, please, can familiarize yourself with it on the page github.com/jedisct1/dnscrypt-proxy .

We suggest using the simpler and more convenient desktop version DNS- cryptographer. Download from the developer's website simplednscrypt.org The version of the program that corresponds to your OS bit level and install it.

It is equipped with an easy, intuitive interface and, moreover, in Russian, so you can easily figure out what’s what. Basic settings are made in the section "Menu". To start using the program, immediately after installation, click the button "Apply", and then select yours below network card, it should be ticked as shown in the screenshot. Switch "DNSCrypt Service" must be active.

It's easy to check if everything works. Execute in the window Run team ncpa.cpl, open the properties of your connection, select from the list IP version 4 (TCPIPv4) and open its properties. Radio button "Use the following DNS server addresses" must be active, and the field must indicate the preferred DNS-server. We have it 127.0.0.1 , your address may be different.

By default, the program automatically selects the most fast server, but you can change your preferences by selecting it yourself in the section.

The section parameters do not need to be changed if you are not using the protocol IPv4. IN general settings you can enable additional tabs "Black list of domains", "Domain Blocking Log", but this is again if you are going to work with the functions they offer, in particular, composing "black" domain lists.

The program scans the DNS responses of servers (this is enough, there are queries inside the responses), and if the domain name matches a regular expression, it prints the address from the A record (what was obtained as a result of resolution).

Using this utility, you can collect almost all the statistics - which domain name was resolved into an IP address, and when this happened. A trained user, of course, can hide this information (by writing the node to the hosts file, or using another channel for DNS queries, for example), but for the majority of nodes we will get a satisfactory picture.

How does this work:

$ sudo ./sidmat eth0 "." iu
We see domain names and what they resolve to (eth0 is the interface on which DNS traffic passes).

$ sudo ./sidmat eth0 "." iu | while IFS= read -r line; do printf "%s\t%s\n" "$(date "+%Y-%m-%d %H:%M:%S")" "$line"; done
We fix the time. All that remains is to redirect the result to a file, and you can use the correspondence table. The utility can capture DNS responses using pcap (on Linux/BSD) or using the nflog mechanism on Linux.

The same technique can be used to control traffic. Filter by domain, get domain addresses from keywords in names, etc.

You need to keep in mind that control may not be very accurate. If by the time the DNS response reaches the user and he starts transmitting traffic to this node, we do not have time to add the address to the ipset/iptables/routing table/somewhere else, then the traffic will go the “normal” way.

In addition, a qualified user can generate false DNS responses, meaning it is better to use this with caution for reprisals.

A few examples:

How to get a list of IP addresses to which vk.com and its subdomains resolve? (Without the "u" option, only unique IP addresses will be printed)

$ sudo ./sidmat eth0 "^vk.com$|\.vk.com$" d
With options “d” or “i” you can see which domain is resolved to the IP address, “d” prints the domain name to stderr.

How to block addresses that allow vk.com, its subdomains and all domains with the word odnoklassniki? (domains like avk.com will not fall under the rule, odnoklassnikii.com will).

$ sudo sh -c "/sidmat eth0 "^vk\.com$|\.vk\.com$|odnoklassniki" | /usr/bin/xargs -I () /sbin/iptables -A INPUT -s () - j DROP"
In addition to small regular expressions, you can use lists in a file (option “f”, the second argument is interpreted as the file name, its contents as one large regular expression). The lists can be quite large, we looked at the performance on the RKN domain list (traffic to prohibited domains was redirected to VPN), a regular PC router coped with this quite calmly.

You can help and transfer some funds for the development of the site

Using nstx it is possible to create an IP tunnel within DNS. The protocol of the same name that allows you to achieve this is called “” and stands for “ NameServer Transfer Protocol».

So, suppose the provider issues and allows you to use its DNS server. Let's imagine a regular DNS request: we request information on the provider's name server, the provider's server passes the request to another name server, which is responsible for the zone we need. And the last DNS server in the chain sends the received response back along the same route.

Now imagine that you can format IP packets into DNS queries from a name server and “shape” incoming traffic into the packets we need. And now we already have everything to build a full-fledged “IP over DNS” - ​​our own hidden tunnel for forwarding traffic through almost any third-party firewalls!

Now all that remains is to configure the fake nameserver and client, but in practice this is not always so easy.

The maximum packet size that can be transmitted is a maximum of 512 bytes over UDP. Therefore, we will need a assembler/disassembler mechanism that will collect and disassemble fragmented packets and check them for correctness. In this scheme, our fake DNS client can communicate with our fake DNS server constantly, but our DNS server can only respond. Therefore, the client will be responsible for reconciliation and maintaining two-way communication.

The first time I tried to do this was in 2008. For two weeks I slowly worked through this package, adjusted the source code to suit myself, re-read the manuals, and as a result, I got a working tunnel successfully built through our ultra-secure firewall corporate network. Then it was simply incredible for me!

In general, with a little desire and time, you can independently launch a fake client name server to create an “IP-over-DNS” tunnel.

Play, try. Look for ways to protect yourself from this. I warn you in advance that there are a lot of technical nuances here.

Hi all! It's time to look at DNS traffic through WireShark's magnifying glass.

Let me remind you that the DNS protocol is used to convert a symbolic name understandable to people, such as, for example, a website, into the IP address to which the request is made.

Download the traffic file. Open it in WireShark and look:

As you can see, the DNS protocol (in the selected zone it is the lowest - domain name system) is an add-on to the UDP protocol, which lies at the 4th level. That is, without establishing a permanent connection, but simply by sending packets (datagrams). Like TCP, UDP has ports. For DNS, this is port number 53, which can be easily seen in the protocol tree.

Going even lower, the UDP protocol is based on the IP protocol for transferring between networks. Currently, it is the main protocol for data transfer on the Internet. At this level we have information about the source and destination IP addresses. Well, also information about the encapsulated UDP packet.

The source address will be our machine (which requested information via DNS), and the destination IP address will be itself. DNS server, which (by implication) must have a database of such matches.

This database stores records of several types:

• A (host) – connects the host name and its IP address;
• AAAA (host) – connects the host name and its IPv6 address;
• CNAME (alias) – connects the node name and its alias to redirect to another node name;
• MX (mail exchange) – points to an IP address mail server processing this domain;
• NS (name server) – points to the DNS server serving this domain;
• SOA (start of authority) – indicates the starting zone for this domain, contains the IP of the main DNS server, address and contact information of the person, domain owner, timestamps, etc.;
• PTR (pointer) – pointer to feedback, which converts the IP address into a canonical name;
• SRV (server) – pointer to various services;
• The full list of entries can be viewed at http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml

So, let's return to our request. Let's look at the first package:

As we can see, if we expand the information tree in the packet analysis, we can see that a request has been received (Queries) to obtain a standard host record (Type: A) by name (Name: www.iana.org). That is, translated from DNS into Russian it will be like this:

"Hey, 68.87.76.178 ! Let me know what IP a guy named www.iana.org, I want to tell him something.”

This is how their conversations go. To which the server will respond (packet No. 2):

Here we see the answer to the question. In other words, the DNS server responds to the host that sent the request:

"Hey, 71.198.243.158 , you asked what address www.iana.org, so here is his address 192.0.34.162 !, now write to him directly”

In detail, you should also pay attention to the Flags fields, which show the characteristics of requests and responses:

Here I again turned to the 1st packet, in which the request to the server occurs.

Pay attention to the Transaction ID: This numeric value must be repeated in the response, which will mean that the response is specifically for this request.

A standard two-byte field whose values ​​are the sum of bits:

• the first bit (1) indicates that this is a request;
• 2-5 bits (4) – that this is a standard request;
• 7 bits (1) – that this is not a truncated request;
• 8 bits (1) – recursive query (i.e. if our DNS server does not know the IP of the host that we requested, it will itself query other DNS servers until it finds an answer;
• 10 bits (1) – reserved;
• 12 bits (1) – accept unauthorized responses. A response from a server is called authoritative if it claims that it itself serves this zone. If the server received a response from other servers, then such a response is not authoritative for us.

Now let's look at the response flags:

Pay attention to the transaction ID. It matches the ID of the previous package.

• The first bit (1) is that this is a response;
• 2-5 bits (4) – standard answer;
• 6 bits (1) - the authority of the response, if the server itself services this zone - it will return “1”, if it received a response from another place - it will be “0”;
• 7 bits (1) – shortened packet. In case the response does not fit into the size of the UDP datagram (512 bytes);
• 8 bits (1) – it is desirable to use recursive queries. If the flag is set to “0”, then in the response the client will receive a list of other servers from which it can try to find out the necessary information.
• 9 bits (1) – the server makes recursive requests;
• 10 bits (1) – reserved;
• 11 bits (1) – an authoritative response was received, that is, the server itself services this zone;
• 12 bits (1) – accept non-authoritative replies?
• 13-16 bits (4) – error code. If 0, then everything is fine.

Well, in general, we figured out the standard questions and answers on DNS.

By the way, there was a Trojan that stole data from a computer, sending it in the form of DNS queries to the server. Can you imagine what it's like? Most firewalls allow DNS, this is normal operation of the client computer. And the worm, under the guise of DNS requests, sent private data to the “left” DNS server. Like, “hey, host server, tell me the IP of the node named “mail” [email protected], password yyyyy”?” And the server recorded requests and could send meaningless responses, thereby recording all requests in some file. The number of DNS requests was large and under their guise it was possible to transfer megabytes of data completely unnoticed by the user. Unless you specifically listen to traffic, it is impossible to detect a data leak.

Protecting DNS connections for the paranoid

Using a VPN, do you think that no one is spying on you and that the transmitted data is protected? You're wrong. Now I will try to explain why.

ABOUT DNSCRYPT IN BRIEF

When using HTTPS or SSL, your HTTP traffic is encrypted, meaning it is protected. When you use a VPN, all your traffic is already encrypted (of course, it all depends on VPN settings, but, as a rule, this is the case). But sometimes, even when using a VPN, your DNS queries are not encrypted, they are sent as is, which opens up a lot of room for creativity, including MITM attacks, traffic redirection and much more.

This is where the open source DNSCrypt utility comes to the rescue, developed by the well-known creators of OpenDNS - a program that allows you to encrypt DNS queries. After installing it on your computer, your connections will also be protected and you will be able to surf the Internet more securely and look at outdoor advertising design. Of course, DNSCrypt is not a panacea for all problems, but only one of the security tools. You still need to use a VPN connection to encrypt all traffic, but pairing it with DNSCrypt will be more secure. If you are satisfied with such a brief explanation, you can immediately move on to the section where I will describe installing and using the program.

FOR THE REAL PARANOICS

Let's try to understand deeper. This section is for the truly paranoid. If you value your time, then you can immediately proceed to installing the program.

So, as they say, it is better to see once than to hear a hundred times. Let's say a client tries to contact dkws.org.ua. The first thing it needs to do is resolve the symbolic hostname to an IP address. If the network configuration is such that the provider’s DNS server is used (an unencrypted connection, red line in the figure), then the resolution of the symbolic name to the IP address occurs over an unencrypted connection.

Yes, no one will know what data you will transmit to dkws.org.ua. But there are some very unpleasant moments. Firstly, the provider, by looking at the DNS logs, will be able to find out which sites you visited. Do you need it? Secondly, the possibility of DNS spoofing and DNS snooping attacks is likely. I will not describe them in detail; many articles have already been written about this. In a nutshell, the situation could be as follows: someone between you and the provider can intercept the DNS request (and since the requests are not encrypted, it will not be difficult to intercept the request and read its contents) and send you a “fake” response. As a result, instead of visiting dkws.org.ua, you will go to the attacker’s website, which is exactly like the one you need, you will enter your password from the forum, and then the development of events, I think, is clear.

The situation described is called DNS leaking. DNS leaking occurs when your system, even after connecting to the VPN server or Tor, continues to query the ISP's DNS servers for domain name resolution. Every time you visit a new site, connect to a new server, or launch a network application, your system contacts your ISP's DNS to resolve the name to the IP. As a result, your provider or anyone located on the “last mile,” that is, between you and the provider, can receive all the names of the nodes that you access. The above option with IP address substitution is quite cruel, but in any case it is possible to track the nodes you have visited and use this information for your own purposes.

If you are “afraid” of your provider or simply don’t want him to see what sites you visit, you can (of course, in addition to using a VPN and other security measures) additionally configure your computer to use the DNS servers of the OpenDNS project (www.opendns.com ). Currently these are the following servers:

208.67.222.222;

208.67.220.220.

You don't need any other additional software. Just configure your system to use these DNS servers.

But the problem of intercepting DNS connections still remains. Yes, you are no longer accessing the provider’s DNS, but rather OpenDNS, but you can still intercept packets and see what’s in them. That is, if you wish, you can find out which nodes you accessed.

Now we come to DNSCrypt. This program allows you to encrypt your DNS connection. Now your ISP (and everyone between you and them) will not know exactly what sites you visit! I'll repeat it again. This program is not a replacement for Tor or VPN. As before, the rest of the data you transmit is transmitted without encryption if you do not use either a VPN or Tor. The program only encrypts DNS traffic.

The site https://www.dnsleaktest.com allows you to identify a DNS leak and explains how to get rid of it. Just go to this site. By clicking the Check for DNS leaks now button, you will receive a list of DNS servers through which your queries can pass. Therefore, you will see exactly who can find out which sites you visit.

In my case, the owners of 12 DNS servers have the ability to record all the sites I visit. But since I work through Tog, this issue worries me little.

The page bit.lv/1ctmaaJ describes how to fix this vulnerability (that is, what to do so that after connecting to a VPN, your system uses the DNS servers of the VPN provider, and not your Internet provider). I see no point in repeating all this, since anyone can cope with the step-by-step sequence of actions.

INSTALLATIONS USING DNSCRYPT

The easiest way to secure your DNS connection is to use DNSCrypt. You can, of course, follow the recommendations from www. dnsleaktest.com, or you can take the path of least resistance and just install DNSCrypt.

First of all, download DNSCrypt itself (https://github.com/QDendns/dnscrypt-win-client). I immediately provided a link to GitHub, where you can download the program. To download the program from GitHub, click the Download ZIP button. An archive with DNSCrypt sources will be downloaded. The already compiled version is located in the DNSCrypt directory of the archive. Unpack the files. Basically, you only need one file - dnscrypt-proxy.exe. It is located in the same directory. Everything else (sources) can be deleted.

But that's not all. If you've already Googled it, then you've seen screenshots of DNSCrypt. After launching dnscrypt-proxy.exe, you realized that something was wrong. The program started in the window command line. Everything is correct, you downloaded the proxy itself, and now you still need to download the shell for it. There is another project on GitHub - the shell we need.

Similarly, download the ZIP archive and unpack it somewhere. In the binaries/Release/ directory there will be a program called dnscrypt-winclient.exe. Copy this file to the directory where the dnscrypt-proxy.exe file is located.

All that remains is to run dnscrypt-proxy. eh. In the window that appears, select network adapters that you want to protect, and click the Start button. If everything is fine, then the message DNSCrypt is running will appear near the Stop button (the Start button will turn into it). By the way, please note that the interface for OS X looks slightly different.

AS A CONCLUSION

The article was not very long, since the program itself is very easy to use. But it wouldn't be complete if I didn't mention VPN. If you read this article and are interested in it, but you have not yet used the services of a VPN provider to encrypt your data, then it’s time to do so. The VPN provider will provide you with a secure tunnel to transfer your data, and DNSCrypt will secure your DNS connections. Of course, SecurityKISS is paid (free tariff plan can only be used for informational purposes), but you have to pay for security?

You can, of course, use Tor, but Tor works relatively slowly, and, whatever one may say, it is not a VPN - it will not be possible to “tariff” all traffic. In any case (whichever option you choose), your DNS connections are now secure. All that remains is to decide on a means of encrypting traffic (if you have not already done so).