Lecture
DNS server (name-server, ns-server) is a domain name server. Every domain name on the Internet has an IP address. NS servers are needed in order to map a domain name to an IP address and vice versa. Also, the DNS server contains information about subdomains and MX records of the domain, text records. Nameserver is a server that has a program installed that converts domains from one form to another. From domen.ua form to 11 .222.111.222 . Typically the Nameserver is ns1.your_hosting.com.
For the correct functioning and maintenance of the domain name, you must specify at least two DNS servers. DNS servers store information about a zone and provide this information on request. In this case, one of the DNS servers is primary (primary), and the rest of the servers, which can be from 1 to 12 for each domain, are called secondary (secondary). All changes to DNS records about domain name settings are made to the primary DNS server, and the secondary DNS servers periodically update their databases , synchronizing them with the database of the primary DNS server.
% request from 2a02: 408: 7722: 1: 77: 222: 61: 170
% This is the Ukrainian Whois query server #F.
Of The Whois Domain is% are subject to the Terms of use
% See https://hostmaster.ua/services/
%
domain: i.ua
dom-the public: of NO
license: 75982
registrant: ua-dgvn-10
admin-c: ua-dgvn- 10
tech-c: ua-dgvn-10
mnt-by: ua.ukrnames
nserver: ns2.i.ua
nserver: ns1.i.ua
status: ok
created: 2006-03-24 16: 18: 47 + 02
modified: 2021-10-02 18: 42: 43 + 03
expires: 2022-03-24 16: 18: 47 + 02
source: UAEPP
% Glue Records:
% =============
nserver: ns1 .i.ua
ip-address: 91.198.36.2
nserver: ns2.i.ua
ip-address: 213.186.122.10
% Registrar:
% ==========
registrar: ua.ukrnames
organization: "Ukrainian internet names Center" LTD
organization-loc: п╒п · п▓ "п╕п╣ п╫я┌я─ п├п╫я┌п╣я─п╫п╣я┌-п├п╪п╣п╫ пя─п╟я≈п╫п╦ "
url: http: // www.ukrnames.com
city: Kharkiv
country: UA
source: UAEPP
% Registrant:
% ===========
contact-id: ua-dgvn-10
person: Digital Ventures LLC
organization: Digital Ventures LLC
.. ...
status: ok
status: linked
created: 2021-03-31 17: 47: 24 + 03
source: UAEPP
% Administrative Contacts:
% =================== ====
contact-id: ua-dgvn-10
person: Digital Ventures LLC
organization: Digital Ventures LLC
....
status: ok
status: linked
created: 2021-03-31 17: 47: 24 + 03
source: UAEPP
% Technical Contacts:
% ======== ===========
contact-id: ua-dgvn-10
person: Digital Ventures LLC
organization: Digital Ventures LLC
e-mail: hostmaster@digital-ventures.net
address: Gaidara str. 50
.....
DNS Watch - View DNS records
DNS records for the I.UA domain
Resource records
i.ua. SOA. ns1.i.ua. hostmaster.i.ua. 2016090101.28800.7200.604800.86400. IN. 7200.
i.ua. A. 91.198.36.14. IN. 7200.
i.ua. TXT. v = spf1 ip4: 91.198.36.0/25 ip4: 109.68.47.24/29 ip4: 193.84.72.0/24? all. Array. IN. 7200.
i.ua. NS. ns1.i.ua. IN. 7200.
i.ua. NS. ns2.i.ua. IN. 7200.
i.ua. MX. 10.mx16.i.ua. IN. 7200.
i.ua. MX. 10.mx17.i.ua. IN. 7200.
......
Authoritative Name Servers
Additional Records
ns1.i.ua. A. 91.198.36.2. IN. 5536.
ns2.i.ua. A. 213.186.122.10. IN. 5536.
mx7.i.ua. A. 213.186.122.10. IN. 5536.
In order to find out the DNS of a domain, you can use various web services to view whois data. For example, you can use the service http://wwhois.ru/whois.php If you use Linux for work, in order to check the DNS of the site, you just need to execute the command whois domain name.
To find out detailed information about which records are contained in DNS servers, you can use free services, for example http://secondary.net.ua/check/
WHOIS databases are managed primarily by registrars and registries; for example, the Public Domain Registry (PIR) maintains the .org registry. ICANN's IANA department manages the central registry for all types of Internet resources and points to the WHOIS server of the responsible (sub) -registry and the contact information for that registry.
DNS Registry Operators maintain another vital system, the authoritative DNS nameservers, which hold the key to where the site is located . For example, if you write www.icann.org in a browser, your ISP queries the DNS name server, starting at the hard-coded root servers to find the name servers associated with that domain name. It then connects to one of these name servers, which in turn returns the IP address of the searched domain name. Your computer can now connect to the computer that will provide the ICANN home page.
The decision to which Registry Operator is requested each time depends on the ever-growing end portion of the domain (i.e. .COM, .NET, .UK, CO.UK, IP6.ARPA), also known as top-level domain (TLD). If the ISP does not already have this information, it can determine which name server should contact for a particular part of the domain name, starting with requests to the root server. Various root servers are hosted around the world, which point to the corresponding name servers below.
WHOIS is designed along the same lines: Starting with WHOIS.IANA.ORG, follow the links to the WHOIS servers below until you get the information you need. This process is illustrated below with a “reduced” registry. A "short" registry requires an additional request to the registrar's database to obtain the WHOIS data for the domain name.
Computers on the network (including the Internet) have no names; data transfer is carried out using IP addresses.
IP-address (Internet Protocol Address) - a numeric address on the Internet, which looks like 123.123.123.123. IP addresses are difficult for a person to remember, especially when you visit dozens of sites a day with different IP addresses. Similar to how you store phone numbers, you can create a directory or phone book. The role of the telephone directory on the Internet is played by the DNS (Domain Name System), the domain name system. When you enter a domain in the Internet browser, it is converted into an IP address through DNS and uses it to access the server. The scheme for determining an IP address by domain name is quite complex.
Your computer contacts the DNS servers of your internet provider. The provider's DNS servers look for an IP address in their cache (intermediate buffer with fast access) and, if they find it, they give you this IP and by IP your computer accesses the server that hosts the site. If the domain - IP address pair is not in the cache, then the provider's DNS server makes recursive queries to the root DNS servers, of which there are only a few around the world.
Changes to domain settings on root servers are not updated instantly, but every few hours. For example, changes in the root DNS servers of the RU zone are updated only 4 times a day. Root servers return the addresses of the domain's NS servers, which store the domain's DNS zone (the IP address of the server with the site and other information about the domain).
Having received the addresses of NS-servers, the provider makes a request to one of them, receives the desired IP-address in response, stores it in the cache (so as not to subsequently access the root DNS-server every time) and transfers it to your browser. And only now, when the browser has the IP address of the site, it can contact the hosting server on which the site is located, and can display it on your computer screen.
So, the information on the root servers is updated only a few times a day, Internet providers most often update the DNS server cache no more than once a day (some providers update the cache even less often, but usually no more than 72 hours), therefore, if after registration or transferring a domain (changing NS servers), the site did not work immediately, do not worry - just wait a while.
NOTE: The above structure of DNS operation is greatly simplified, for details you can refer to the reference literature.
Freenom is the world's first and only free domain provider. Our mission is to attract people to the Internet and contribute to the development of the national digital economy around the world. Free domains work just like any other domains. You can use a free domain to host your website, blog, email account, and more! You can use a free domain with URL redirects, the free Freenom DNS service, or your own DNS service (name server). Extensions currently available with free domain registration:
http://www.freenom.com/
http://www.dot.tk/ru
Thus, free domains are some domains of African countries.
Tek free domains can be domains above the 3rd level or domains of the second level, but subject to ordering hosting or other services of a company that deals with domain deletion.
A domain name is a unique alphanumeric designation (including letters from A to Z, numbers from 0 to 9 and a hyphen "-") that is a necessary element of an Internet address. A domain name allows you to identify a website or email address on the Internet.
For example: "cy-pr.com" and "kremlin.ru" are domain names for Internet addresses http://cy-pr.com and http://kremlin.ru, respectively.
The registered domain name, at the request of the owner, can be active or inactive (used or not used). If the domain name is active, it is associated with an IP address - a unique numeric address of the computer (host) on which the website is located, indicated by the domain name.
The Internet is a collection of local area networks of computers located around the world that communicate with each other according to uniform rules called protocols. These rules are used on a voluntary basis, as there is no formally established or government mechanism to enforce them.
One important set of rules, known as the Domain Name System , or DNS (Domain Names System), connects names like www.cy-pr.com c numeric addresses that computers use to communicate with each other.
It is these Domain names that people use to find the necessary resource in the global network or send a message by e-mail.
A domain name consists of several fields separated by periods. The site https://intellect.icu says about it. The field on the far right is called the Top Level Domain , followed from right to left by the domain names (subdomains) of the lower level.
Each Top Level Domain has an Administrator, called the Zone Administrator , who is the legal entity responsible for managing and regulating that Domain's policies.
The hierarchical structure of domain names can be represented as a tree. The fully qualified domain name ends with a dot "." Denoting the root of the domain tree (this ending dot is not visible to the user). Next (from right to left) in the hierarchy are top-level domains, followed by second-level domains, then third-level domains (see Fig.). Domains of the third level are subdomains (subdomains) for domains of the second level, and domains of the second level are subdomains for top level domains. They are separated from each other by dots.
The figure illustrates the hierarchical organization of domain names with examples including many top-level domains:
This diagram briefly explains what happens when you want to visit a particular site.
1your computer contacts the DNS servers of your ISP ( arrow 1 ). The provider's DNS servers look for the IP address in their cache (intermediate buffer with fast access) and, if they find it, they give you this IP and by IP your computer accesses the server that hosts the site ( arrow 7 );
2 if the pair "domain - IP address" is not in the cache, the provider's DNS server makes recursive queries to the root DNS servers ( arrow 2 ), of which there are only a few around the world. Changes to domain settings on root servers are not updated instantly, but every few hours. For example, changes in the root DNS servers of the RU zone are updated only 4 times a day. The root servers return the addresses of the domain's DNS servers ( arrow 3 ) that store the domain's DNS zone;
3 having received the addresses of the DNS servers, the provider makes a request to one of them ( arrow 4 ), receives the desired IP address in response ( arrow 5 ), stores it in the cache (so that later does not contact the root DNS server each time) and transfers it to your browser ( arrow 6 );
4and only now, when the browser has the IP address of the site, it can contact the hosting server where the site is located ( arrow 7 ), and can display it on your computer screen ( arrow 8 ).
So:
The domain name system translates names into numeric addresses and vice versa transparently to the end user. This process relies on a system of servers called name servers , which store data that associates domain names with numeric addresses. Each name server is responsible for its own zone and stores a limited set of names and numeric addresses.
All name servers are linked to Root Name Servers , which coordinate data and allow users to find the server responsible for the portion of the Internet they want to reach. They are called root because they function at the root level - they serve as a single root domain "."
One of the Root Servers is the "Authority Server" (Root Server A). The Authority Server maintains a master copy of the file that recognizes all top-level domains, the so-called Root Zone File, this file is copied to the other root servers according to the specified algorithm.
Name servers are organized in a hierarchy similar to domain names.
For example, if someone wants to connect to the cy-pr.com portal website - www.cy-pr.com, his computer will ask for help from one of the root servers.
The root server will send the request to the server, which stores information about names ending in .ru . This server, in turn, will forward the request to a third server, the one that knows the numeric addresses for all names ending in .cy-pr.com .
This third server will return a digital address to the user to achieve a direct link to the www.cy-pr.com website.
The Internet is a collection of local area networks of computers located around the world that communicate with each other according to uniform rules called protocols.
In order not to remember the numerical address of the computer, the DNS system was created. The Domain Names System, or DNS, associates names like www.htmlweb.ru with the numeric addresses (188.40.41.77) that computers use to communicate with each other.
In order for your site with your domain name to work, you need to specify the DNS-servers on which it will be "recorded" on which server (hosting) your site is located. DNS servers look like:
ns1.yourhosting.ru ns2.yourhosting.ru
There are three ways to configure DNS:
To specify / change the DNS server for a domain, you need to:
Information about your changes will be available for a period from a few minutes to 72 hours. Therefore, at first, it is possible that the DNS servers will be old. It does not depend on the registrar or the hosting provider. You just have to wait.
To add / change records on the DNS server, you need to do the following:
An example of entering records in DNS:
Suppose you have registered the mydomain.ru domain and the IP address of the web server that will host the site - 195.128.128.26. In this case, you will need to create at least two "A" records for your domain (to link mydomain.ru and www.mydomain.ru with the address 195.128.128.26). To do this, in the form for adding records "A" in the "Subdomain name" field, specify "@" for the first record and "www" for the second record, and in the "Data" field specify 195.128.128.26 (for both records).
To send all subdomains to an IP address, you need to specify * as the "Subdomain name"
Example 2: You want the mail.mydomain.ru address to point to the same host as relay.highway.ru. To do this, enter "mail" in the 'Subdomain name' field, select the 'Record type' CNAME, and enter "relay.highway.ru." In the 'Data' field.
An example of DNS records for the mydomain.ru zone:
@ A 195.161.114.80 @ MX 10 relay.highway.ru. www A 195.161.114.80 ctrl CNAME ctrl.muse.highway.ru. ftp CNAME ftp.muse.highway.ru. mail CNAME relay.highway.ru. ssh CNAME ssh.muse.highway.ru.
See also: Yandex mail settings for a domain.
In order to attach a domain to an IP address, you need:
Now you need to wait until the changes take effect and your site will open from this IP address. This can take up to 72 hours.
The changes themselves to the DNS are made instantly. But due to the fact that providers cache DNS, the process of changing DNS around the world can take from a few minutes to 72 hours.
To obtain an IP address by domain name, you can use the following DNS servers:
Google:
8.8.8.8
4.4.4.4
Yandex:
77.88.8.8
77.88.8.1
Learn more about Yandex DNS and how to protect yourself from malicious sites using DNS at dns.yandex.ru
There are two types of queries to dns servers - recursive and non-recursive (iterative) . With a recursive request, the client turns to the preferred dns-server, and if it does not know the answer, it begins to poll the servers responsible for the zones one by one, starting with the root and then going down the hierarchy. An iterative query is less common. In it, the client itself polls dns servers in turn, starting with the root servers, etc. Of course, if it does not find the query results in its cache.
A clearly recursive query looks like this: (DNS servers of providers or unique servers like 8.8.8.8 work according to this scheme)
and non-recursive uses root servers and domain zone servers. these servers have very high loads
This concludes the overview of the basic principles of dns.
The vulnerability of DNS traffic is due to the fact that for the most part it is transmitted in the open, for malicious actions on the part of providers seeking to increase their revenues by embedding ads in content, government law enforcement agencies and censorship, as well as just criminals, The process of strengthening its protection, despite for the availability of various technologies such as DNSSEC / DANE, DNScrypt, DNS-over-TLS and DNS-over-HTTPS, stuck. And if server solutions, and some of them have been around for quite a long time, are widely known and available, their support from the client software leaves much to be desired.
However, at the end of 2010, the implementation of DNS-over-HTTPS (DoH) began.
The DNS or Domain Name System service is a basic service on the Internet, as well as other networks based on the TCP / IP protocol family, and is used to match a host name in a network to its corresponding digital address.
Despite such a simple description, DNS is perhaps the most complex network service in its structure and set of interactions, on the reliable operation of which reliable operation of everyone and everything depends.
The author has already touched upon the functioning of the DNS in a series of articles in the context of the most modern and topical practical issues of DNSSEC implementation . Let me remind you that DNSSEC provides the authentication of DNS records using digital signatures, which protects them from possible spoofing. However, at the same time, all data is always transmitted in clear text and is in no way protected from viewing during transit and, in the absence of a digital signature, if desired, can be easily modified for one purpose or another - from criminal to censorship.
This article is devoted to practical ways to protect DNS traffic.
Indeed, at the time of its creation more than 30 years ago, the issue of protecting information transmitted via DNS. Therefore, despite the obviousness of the problem, due to historical reasons, all data are still completely open in the transit process. For example, you can look at them using standard operating system tools, for example, the tcpdump utility.
root @ my: ~ # tcpdump -i tun0 -n -nn -ttt 'port 53' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type NULL (BSD loopback), capture size 262144 bytes 00: 00: 00.000000 IP 89.39.107.72.19058> 1.2.3.4.53: 19491% [1au] A? www.my.domain. (41) 00: 00: 00.016706 IP 1.2.3.4.53> 89.39.107.72.19058: 19491 * - 4/3/1 CNAME my.domain., RRSIG, A 46.4.120.253, RRSIG (435) 00: 01: 17.233741 IP 1.2.3.4.22679> 68.142.255.16.53: 28165% [1au] AAAA? ns4.yahoo.com. (42) 00: 00: 00.000054 IP 1.2.3.4.37567> 203.84.221.53.53: 32770% [1au] AAAA? ns5.yahoo.com. (42) 00: 00: 00.036409 IP 68.142.255.16.53> 1.2.3.4.22679: 28165 * - 0/1/1 (103) 00: 00: 00.002475 IP 1.2.3.4.63693> 68.142.254.15.53: 11422% [1au] AAAA? mta5.am0.yahoodns.net. (50) 00: 00: 00.029746 IP 68.142.254.15.53> 1.2.3.4.63693: 11422 * - 0/1/1 (120) 00: 00: 00.000387 IP 1.2.3.4.28336> 68.180.130.15.53: 16455% [1au] A? mta5.am0.yahoodns.net. (50) 00: 00: 00.029690 IP 68.180.130.15.53> 1.2.3.4.28336: 16455 * - 8/0/1 A 98.137.159.28, A 67.195.229.59, A 74.6.137.65, A 67.195.229.58, A 98.137.159.26 , A 98.137.159.27, A 98.136.102.55, A 74.6.137.63 (178) 00: 00: 00.001624 IP 1.2.3.4.50387> 68.142.254.15.53: 10530% [1au] AAAA? mta6.am0.yahoodns.net. (50) 00: 00: 00.028234 IP 68.142.254.15.53> 1.2.3.4.50387: 10530 * - 0/1/1 (120) 00: 00: 00.000280 IP 1.2.3.4.10490> 68.142.254.15.53: 26126% [1au] A? mta6.am0.yahoodns.net. (50) 00: 00: 00.022699 IP 203.84.221.53.53> 1.2.3.4.37567: 32770 * - 0/1/1 (103) 00: 00: 00.017178 IP 68.142.254.15.53> 1.2.3.4.10490: 26126 * - 8/0/1 A 66.218.85.52, A 74.6.137.64, A 67.195.229.59, A 67.195.229.58, A 98.137.159.24 , A 98.137.159.26, A 98.137.159.28, A 98.136.101.117 (178) 00: 00: 00.000915 IP 1.2.3.4.46574> 68.180.130.15.53: 14314% [1au] AAAA? mta7.am0.yahoodns.net. (50) 00: 00: 00.028844 IP 68.180.130.15.53> 1.2.3.4.46574: 14314 * - 0/1/1 (120) 00: 00: 00.000335 IP 1.2.3.4.7539> 68.142.254.15.53: 9379% [1au] A? mta7.am0.yahoodns.net. (50) 00: 00: 00.029458 IP 68.142.254.15.53> 1.2.3.4.7539: 9379 * - 8/0/1 A 98.137.159.27, A 98.136.102.54, A 66.218.85.52, A 98.137.159.25, A 98.136.102.55 , A 98.137.159.24, A 74.6.137.63, A 74.6.137.64 (178) 00: 00: 02.160590 IP 206.190.33.24.51154> 1.2.3.4.53: 19088% [1au] A? foo.my.domain. (41) 00: 00: 00.000106 IP 1.2.3.4.53> 206.190.33.24.51154: 19088 * - 2/3/3 A 1.2.3.4, RRSIG (367) 00: 00: 00.004227 IP 206.190.33.24.53589> 1.2.3.4.53: 47712% [1au] AAAA? foo.my.domain. (41) 00: 00: 00.000045 IP 1.2.3.4.53> 206.190.33.24.53589: 47712 * - 2/3/3 AAAA 2001: 470: 28: 26f :: 1, RRSIG (367) 00: 00: 00.054647 IP 206.190.33.24.55240> 1.2.3.4.53: 20459 [1au] TXT? key.kostikov.co.my.domain. (53) 00: 00: 00.000106 IP 1.2.3.4.53> 206.190.33.24.55240: 20459 * - 2/3/5 TXT "v = DKIM1; k = rsa; p =" "MII44lwAqHc4u" "zBz + o6bOj9LGn3Iel3MGVSfWhf" pdfUE3MGVSfWhr "pdfbo "Qdm6XWn + fygRDn / 4e0qCgY" "i + bBNZzQkgLWM0Y0LkEeSLhfaHd" "Y7EJeUIIsP8TJmnB1QCf2LyA" "dQIDAQAB", RRSIG (894) ...
Here, both requests to remote servers and their responses are perfectly visible.
With only this data, it is not difficult to get a complete picture of exactly which resources and for what purpose you turned. Also, this data can be tampered with if it is impossible to use DNSSEC for one reason or another, redirecting you, for example, to a fake website or blocking access to certain information for censorship reasons.
This DNS problem has long been widely known to the Internet community. As a solution, the two most common solutions were proposed for use - DNScrypt and DNS-over-TLS, which are the encapsulation of DNS traffic into an encrypted channel.
DNScrypt protocol is the first implemented solution to protect DNS traffic from viewing and deliberate modification during transit. In fact, it is a simplified version of TLS, where instead of a chain of trusted certificates, only one is used, which authenticates the server to which a secure connection is made.
DNScrypt can use the UPD and TCP network protocols, usually using port 443 which is also standard for HTTPS.
A detailed description of how it works is on the official website. In short, first, by the server name, a special DNS TXT record of the 2.dnscrypt-cert.domain.name format is accessed to obtain the current public certificate key. For example, for the cisco server, which is an alias for the OpenDNS service acquired by this company some time ago, it looks like this at the time of this writing.
root @ my: ~ # host -t txt 2.dnscrypt-cert.opendns.com
2.dnscrypt-cert.opendns.com descriptive text "DNSC \ 000 \ 001 \ 000 \ 000; \ 200 \ 196 \ 196 \ 240 \ 012 \ 002 \ 219 \ 217 \ 012 \ 192 \ 172 / \ 223 \ 024 \ 240on \ 171 \ 012 \ 209 \ 140d \ 128 \ 189 \ 211B \ 1962D {\ 1294j \ 006lg} \ 020 \ 178 \ 019a \ 210 @ \ 180 * a \ 004 \ 162 ^ \ 167 \ 165 \ 149: d \ 211 \ 157 \ 025 \ 228) \ 183 \ 1400 \ 007 $ \ 011 \ 017 \ 183 \ 173 \ 002 \ 250 \ 192b \ 133 \ 030 \ 136n \ 170D \ 231 \ 174 [\ 173 / \ 146 \ 031 \ 149wQM \ 226 & \ 213Rh6qNzimeuUZy \ 250 \ 165Zy \ 250 \ 165 \\ [.% "
Next, the corresponding exchange procedures and the generation of session keys are performed, and work with data in encrypted form begins.
The standard way to use DNScrypt is to install the special client dnscrypt-proxy, which is available for many platforms. It acts as a translator of standard DNS queries over a secure channel to DNScrypt-enabled servers (see the list of public servers).
Since this is a proxy, it does not have a request caching function, which can negatively affect the performance of all applications using the Internet. In this regard, it is advisable to use it in conjunction with a local caching DNS server.
Let's consider an example of such a setup in conjunction with the popular Unbound DNS server, which is already installed in the FreeBSD environment.
root @ my: ~ # uname -v
FreeBSD 11.1-RELEASE-p8 # 0: Tue Mar 13 17:07:05 UTC 2018 root@amd64-builder.daemonology.net: / usr / obj / usr / src / sys / GENERIC
root @ my: ~ # cd / usr / ports / dns / unbound /
root @ my / usr / ports / dns / unbound # make showconfig
===> The following configuration options are available for unbound-1.7.0:
DNSCRYPT = on: Enable dnscrypt support
DNSTAP = off: Enable dnstap logging support
DOCS = on: Build and / or install documentation
ECDSA = on: Enable ECDSA (elliptic curve) support (OpenSSL> = 1.0)
EVAPI = off: (Experimental) pluggable event based libunbound API support
FILTER_AAAA = off: Build with AAAA filter functionality (contrib)
GOST = off: Enable GOST support (requires OpenSSL> = 1.0)
LIBEVENT = on: Build against libevent
MUNIN_PLUGIN = off: Install Munin plugin
PYTHON = off: Python bindings or support
SUBNET = off: Enable client subnet support
TFOCL = on: Enable TCP Fast Open for client mode
TFOSE = on: Enable TCP Fast Open for server mode
THREADS = on: Threading support
Install the DNScrypt proxy server.
root @ my / usr / ports / dns / unbound # cd / usr / ports / dns / dnscrypt-proxy / root @ my: / usr / ports / dns / dnscrypt-proxy # make install clean ===> License MIT accepted by the user ===> dnscrypt-proxy-1.9.5_3 depends on file: / usr / local / sbin / pkg - found => dnscrypt-proxy-1.9.5.tar.gz doesn't seem to exist in / usr / ports / distfiles /. => Attempting to fetch http://distcache.FreeBSD.org/local-distfiles/dbaio/dnscrypt-proxy/dnscrypt-proxy-1.9.5.tar.gz dnscrypt-proxy-1.9.5.tar.gz 100% of 1624 kB 7160 kBps 00m00s ===> Fetching all distfiles required by dnscrypt-proxy-1.9.5_3 for building ===> Extracting for dnscrypt-proxy-1.9.5_3 => SHA256 Checksum OK for dnscrypt-proxy-1.9.5.tar.gz. ... root @ my: / usr / ports / dns / dnscrypt-proxy # sysrc dnscrypt_proxy_enable = YES root @ my: / usr / ports / dns / dnscrypt-proxy # sysrc dnscrypt_proxy_flags = "- a 127.0.0.1:8053" root @ my: / usr / ports / dns / dnscrypt-proxy # service dnscrypt-proxy start Starting dnscrypt_proxy. Sat Mar 24 21:41:33 2018 [INFO] Randomly chosen resolver: [d0wn-is-ns1] Sat Mar 24 21:41:33 2018 [INFO] + DNS Security Extensions are supported Sat Mar 24 21:41:33 2018 [INFO] + Provider supposedly doesn't keep logs root @ my: / usr / ports / dns / dnscrypt-proxy # cat /var/log/dnscrypt-proxy.log Sat Mar 24 21:41:33 2018 [NOTICE] Starting dnscrypt-proxy 1.9.5 Sat Mar 24 21:41:33 2018 [INFO] Generating a new session key pair Sat Mar 24 21:41:33 2018 [INFO] Done Sat Mar 24 21:41:33 2018 [INFO] Server certificate with serial # 1521918421 received Sat Mar 24 21:41:33 2018 [INFO] This certificate is valid Sat Mar 24 21:41:33 2018 [INFO] Chosen certificate # 1521918421 is valid from [2018-03-24] to [2018-03-25] Sat Mar 24 21:41:33 2018 [INFO] Server key fingerprint is BB32: C1B4: 04A3: D25F: A52C: CF36: CAC8: FAEE: B83C: D95D: 8A47: 96C3: BDDF: D58E: E745: 7B4B Sat Mar 24 21:41:33 2018 [NOTICE] Proxying from 127.0.0.1:8053 to 107.181.168.52:443
In this case, we will use a random DNScrypt server from the /usr/local/share/dnscrypt-proxy/dnscrypt-resolvers.csv list included in the proxy distribution kit. You can also force the preferred server by including the desired option in the /etc/rc.conf init file , for example the aforementioned OpenDNS server.
root @ my: ~ # sysrc dnscrypt_proxy_resolver = "cisco"
The service is running and available at the local address 127.0.0.1 using port 8053.
root @ my: / usr / ports / dns / dnscrypt-proxy # sockstat -46 | grep 53 unbound unbound 18404 3 udp6 :: 1: 53 *: * unbound unbound 18404 4 tcp6 :: 1: 53 *: * unbound unbound 18404 5 udp4 127.0.0.1:53 *: * unbound unbound 18404 6 tcp4 127.0.0.1:53 *: * _dnscrypt-proxy dnscrypt-p18375 7 udp4 127.0.0.1:8053 *: * _dnscrypt-proxy dnscrypt-p18375 9 tcp4 127.0.0.1:8053 *: *
Now let's redirect Unbound requests to a running DNScrypt proxy. To do this, you just need to add the address that uses the proxy as a forwarder in the forward-zone section of the /usr/local/etc/unbound/unbound.conf configuration file .
root @ my: / usr / ports / dns / dnscrypt-proxy # cat /usr/local/etc/unbound/unbound.conf
server:
...
do-not-query-localhost: no
...
forward-zone:
name: "."
forward-addr: 127.0.0.1@8053
...
Unbound has the ability to act as a server serving DNScrypt requests.
However, due to the relative complexity of working with DNScrypt keys, namely, the need to generate, rotate and control the validity of keys using the third-party dnscrypt-wrapper utility, the author does not see any point in using Unbound in this way.
For informational purposes only, we will mention that a special dnscrypt section in the Unbound configuration file is used for the corresponding settings.
root @ my: ~ # cat /usr/local/etc/unbound/unbound.conf
server:
...
interface: 0.0.0.0@5443
interface: :: 0 @ 5443
...
dnscrypt:
dnscrypt-enable: yes
dnscrypt-port: 443
dnscrypt-provider: 2.dnscrypt-cert.my.domain.
dnscrypt-secret-key: /usr/local/etc/unbound/1st.key
dnscrypt-secret-key: /usr/local/etc/unbound/2nd.key
dnscrypt-provider-cert: /usr/local/etc/unbound/1st.cert
dnscrypt-provider-cert: /usr/local/etc/unbound/2nd.cert
...
Here Unbound is open to serve DNScrypt requests on port 5443 (to avoid conflicts with an HTTP server using port 443) using two sets of keys with different expiration dates to avoid timeouts.
Another more modern way to protect DNS traffic is the DNS-over-TLS protocol described in the RFC7858 standard, which is an encapsulation of data in standard TLS. It is recommended to use port 853 for access.
As in the case of DNScrypt, it is assumed that the DNS client, which is usually the same local caching DNS, contacts remote servers that support DNS-over-TLS (see the current list).
The above-mentioned Unbound has built-in support for this protocol, so no additional software layer is required for use, as was the case with DNScrypt.
To work as a client, DNS-over-TLS Unbound only requires a list of servers in the same forward-zone section of the configuration file.
root @ my: ~ # cat /usr/local/etc/unbound/unbound.conf
server:
...
forward-zone:
name: "."
# Quad9
forward-addr: 9.9.9.9@853
forward-addr: 2620: fe :: fe @ 853
...
forward-ssl-upstream: yes
...
Setting up Unbound as a server serving DNS-over-TLS requests is also easy . To do this, you can use existing TLS certificates, for example from Let's Encrypt.
root @ my: ~ # cat /usr/local/etc/unbound/unbound.conf
server:
...
interface: 127.0.0.1
interface: :: 1
interface: 0.0.0.0@853
interface: :: 0 @ 853
tls-service-key: "/usr/local/etc/letsencrypt/live/my.domain/privkey.pem"
tls-service-pem: "/usr/local/etc/letsencrypt/live/my.domain/cert.pem"
tls-port: 853
...
In this case, Unbound by default serves standard unencrypted DNS queries on the local interface 127.0.0.1 and :: 1, but in this case it was necessary to specify this explicitly in the configuration. Now it is also available and for external requests is available exclusively via the DNS-over-TLS protocol on port 853.
root @ my: ~ # sockstat -46 | grep unbound unbound unbound 18533 3 udp4 127.0.0.1:53 *: * unbound unbound 18533 4 tcp4 127.0.0.1:53 *: * unbound unbound 18533 5 udp6 :: 1: 53 *: * unbound unbound 18533 6 tcp6 :: 1: 53 *: * unbound unbound 18533 7 udp4 *: 853 *: * unbound unbound 18533 8 tcp4 *: 853 *: * unbound unbound 18533 9 udp6 *: 853 *: * unbound unbound 18533 10 tcp6 *: 853 *: *
откуда корневые dns получаются информацию?
1)А в корневой сервер как попадает информация о домене?
1.1)берется информация из Whois строки NS? или эта не связанная информация?
1.2) или в рут сервера информация одновременно с информацией в Whois добавляется при регистрации домена?
2) мне интересно как первичный NS сервер участвует в DNS?.
3) в рут серверах наверное нет информации о конкретных доменах, есть ссылки только на ДНС корневых зон? или все есть? тогда зачем нужны ДНС сервера корневых зон?
4) когда используется рекурсивный и не рекурсивный днс запрос?
Comments
To leave a comment
Fundamentals of Internet and Web Technologies
Terms: Fundamentals of Internet and Web Technologies