Страница 1 из 2
ещё раз про DNS
Добавлено: 03 сен 2021, 13:24
Olej
Эта тема в продолжение
DNS сервер:
- там слишком много было (интересных) разбирательств...
- и многое поменялось за прошедшие несколько лет.
Re: ещё раз про DNS
Добавлено: 03 сен 2021, 14:20
Olej
Инструменты наблюдение и проверки работоспособности DNS (и конкретного сервера DNS) - запрос на разрешение:
Код: Выделить всё
olej@R420:~$ nslookup rus-linux.net 1.1.1.1
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
Name: rus-linux.net
Address: 178.208.83.36
Код: Выделить всё
olej@R420:~$ host rus-linux.net 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases:
rus-linux.net has address 178.208.83.36
rus-linux.net mail is handled by 10 mx2.rus-linux.net.
rus-linux.net mail is handled by 10 mx1.rus-linux.net.
Код: Выделить всё
olej@R420:~$ dig @1.1.1.1 rus-linux.net
; <<>> DiG 9.16.1-Ubuntu <<>> @1.1.1.1 rus-linux.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6433
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;rus-linux.net. IN A
;; ANSWER SECTION:
rus-linux.net. 408 IN A 178.208.83.36
;; Query time: 16 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Пт сен 03 14:19:18 EEST 2021
;; MSG SIZE rcvd: 58
Re: ещё раз про DNS
Добавлено: 03 сен 2021, 14:25
Olej
Olej писал(а): ↑03 сен 2021, 14:20
Инструменты наблюдение и проверки работоспособности DNS (и конкретного сервера DNS) - запрос на разрешение:
В некоторых встраиваемых боксах на Linux (TV-box, спутниковые тюнеры, ...) приходилось видеть
отсутствие клиентов запросов DNS.
Там работоспособность (настроек) разрешения DNS и как - можно контролировать с помощью:
Код: Выделить всё
olej@R420:~$ ping -c2 rus-linux.net
PING rus-linux.net (178.208.83.36) 56(84) bytes of data.
64 bytes from s30.h.mchost.ru (178.208.83.36): icmp_seq=1 ttl=56 time=48.6 ms
64 bytes from s30.h.mchost.ru (178.208.83.36): icmp_seq=2 ttl=56 time=46.8 ms
--- rus-linux.net ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 46.816/47.706/48.597/0.890 ms
P.S. Рекомендую именно явно указывать число ICMP запросов (-c2), потому как в таких embedded реализациях вариант ping может не останавливаться по ^C и "играет" до бесконечности (и serial или SSH терминал - потерян).
Re: ещё раз про DNS
Добавлено: 03 сен 2021, 14:36
Olej
Множество книг и публикаций за многие году (лет 40) было посвящено
кэширующим DNS.
Но с некоторых пор (я не знаю от когда, не отследил) кэширующая DNS-служба введена в состав systemd - systemd-resolved.service
(Как и многие другие вещи, не имеющие, вообще то, прямого отношения к сервисам и их активации - сокетная активация вместо inetd/xinetd и др.)
Код: Выделить всё
olej@R420:~$ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2021-09-02 15:27:34 EEST; 5h 54min ago
Docs: man:systemd-resolved.service(8)
https://www.freedesktop.org/wiki/Software/systemd/resolved
https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
Main PID: 1080 (systemd-resolve)
Status: "Processing requests..."
Tasks: 1 (limit: 115834)
Memory: 15.8M
CGroup: /system.slice/systemd-resolved.service
└─1080 /lib/systemd/systemd-resolved
сен 02 15:27:34 R420 systemd[1]: Starting Network Name Resolution...
сен 02 15:27:34 R420 systemd-resolved[1080]: Positive Trust Anchors:
сен 02 15:27:34 R420 systemd-resolved[1080]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
сен 02 15:27:34 R420 systemd-resolved[1080]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa
сен 02 15:27:34 R420 systemd-resolved[1080]: Using system hostname 'R420'.
сен 02 15:27:34 R420 systemd[1]: Started Network Name Resolution.
По дефаулту, если ничего не настраивать от себя, кэширующий DNS сервер работает на локальном IP 127.0.0.53 :
Код: Выделить всё
olej@R420:~$ nslookup linux-ru.ru 127.0.0.53
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: linux-ru.ru
Address: 185.200.243.3
Это нововведение радикально меняет многолетнюю стратегию использования кэширующих DNS.
Re: ещё раз про DNS
Добавлено: 03 сен 2021, 14:40
Olej
Olej писал(а): ↑03 сен 2021, 14:36
Но с некоторых пор (я не знаю от когда, не отследил) кэширующая DNS-служба введена в состав systemd - systemd-resolved.service
Код: Выделить всё
olej@R420:~$ man systemd-resolved
SYSTEMD-RESOLVED.SERVICE(8) systemd-resolved.service SYSTEMD-RESOLVED.SERVICE(8)
NAME
systemd-resolved.service, systemd-resolved - Network Name Resolution manager
SYNOPSIS
systemd-resolved.service
/lib/systemd/systemd-resolved
DESCRIPTION
systemd-resolved is a system service that provides network name resolution to local applications. It implements a caching and validating
DNS/DNSSEC stub resolver, as well as an LLMNR and MulticastDNS resolver and responder. Local applications may submit network name
resolution requests via three interfaces:
• The native, fully-featured API systemd-resolved exposes on the bus. See the API Documentation[1] for details. Usage of this API is
generally recommended to clients as it is asynchronous and fully featured (for example, properly returns DNSSEC validation status and
interface scope for addresses as necessary for supporting link-local networking).
• The glibc getaddrinfo(3) API as defined by RFC3493[2] and its related resolver functions, including gethostbyname(3). This API is
widely supported, including beyond the Linux platform. In its current form it does not expose DNSSEC validation status information
however, and is synchronous only. This API is backed by the glibc Name Service Switch (nss(5)). Usage of the glibc NSS module nss-
resolve(8) is required in order to allow glibc's NSS resolver functions to resolve host names via systemd-resolved.
• Additionally, systemd-resolved provides a local DNS stub listener on IP address 127.0.0.53 on the local loopback interface. Programs
issuing DNS requests directly, bypassing any local API may be directed to this stub, in order to connect them to systemd-resolved. Note
however that it is strongly recommended that local programs use the glibc NSS or bus APIs instead (as described above), as various
network resolution concepts (such as link-local addressing, or LLMNR Unicode domains) cannot be mapped to the unicast DNS protocol.
The DNS servers contacted are determined from the global settings in /etc/systemd/resolved.conf, the per-link static settings in
/etc/systemd/network/*.network files (in case systemd-networkd.service(8) is used), the per-link dynamic settings received over DHCP, user
request made via resolvectl(1), and any DNS server information made available by other system services. See resolved.conf(5) and
systemd.network(5) for details about systemd's own configuration files for DNS servers. To improve compatibility, /etc/resolv.conf is read
in order to discover configured system DNS servers, but only if it is not a symlink to /run/systemd/resolve/stub-resolv.conf,
/usr/lib/systemd/resolv.conf or /run/systemd/resolve/resolv.conf (see below).
...
Re: ещё раз про DNS
Добавлено: 03 сен 2021, 14:55
Olej
Olej писал(а): ↑03 сен 2021, 14:36
Это нововведение радикально меняет многолетнюю стратегию использования кэширующих DNS.
Как всегда, одно из лучших описаний - в сообществе ArchLinux
systemd-resolved (Русский)
Совет: Узнать, какие серверы systemd-resolved использует в данный момент, можно командой resolvectl status.
Код: Выделить всё
olej@R420:~$ resolvectl status
...
Link 4 (docker0)
Current Scopes: none
DefaultRoute setting: no
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 3 (eno2)
Current Scopes: DNS
DefaultRoute setting: yes
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Current DNS Server: 192.168.1.3
DNS Servers: 192.168.1.3
1.1.1.1
8.8.8.4
DNS Domain: ~.
Link 2 (eno1)
Current Scopes: DNS
DefaultRoute setting: yes
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Current DNS Server: 192.168.1.3
DNS Servers: 192.168.1.3
1.1.1.1
8.8.8.4
DNS Domain: ~.
...
Автоматически
systemd-resolved работает "из коробки" с сетевыми менеджерами, использующими файл /etc/resolv.conf. Никаких дополнительных настроек не требуется, поскольку systemd-resolved будет автоматически обнаружен при переходе по символической ссылке /etc/resolv.conf. Во всяком случае, это работает для systemd-networkd и NetworkManager.
...
Переходим на systemd-resolved
12/13/2016
Установка и первичная настройка настройка systemd-resolved
Разбираемся с локальными DNS
20 марта 2019
Re: ещё раз про DNS
Добавлено: 03 сен 2021, 15:17
Olej
Olej писал(а): ↑03 сен 2021, 14:36
с некоторых пор (я не знаю от когда, не отследил) кэширующая DNS-служба введена в состав systemd
https://www.freedesktop.org/wiki/Softwa ... /resolved/
resolved
systemd 229 and newer include a fully featured DNS resolver implementation in the systemd-resolved service. This is a small daemon that provides DNS and LLMNR based host name resolution and caching. Since it acts as DNSSEC validating stub resolver it is suitable for retrieving DNS certificate and SSH fingerprint resource records.
https://github.com/systemd/systemd/releases/tag/v229
released this on Mar 12, 2017
т.е. 4 года назад
Re: ещё раз про DNS
Добавлено: 03 сен 2021, 15:28
Olej
Olej писал(а): ↑03 сен 2021, 14:36
Это нововведение радикально меняет многолетнюю стратегию использования кэширующих DNS.
Порядок разрешения имён на сейчас установлен:
Код: Выделить всё
olej@R420:~$ cat /etc/nsswitch.conf | grep hosts
hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
Re: ещё раз про DNS
Добавлено: 03 сен 2021, 15:49
Olej
Olej писал(а): ↑03 сен 2021, 14:20
Инструменты наблюдение и проверки работоспособности DNS (и конкретного сервера DNS) - запрос на разрешение:
Время выполнения запроса DNS (главный показатель!) от определённого сервера можно определить, например, так:
Код: Выделить всё
olej@R420:~$ dig @1.1.1.1 linux-ru.ru | grep time
;; Query time: 16 msec
olej@R420:~$ dig @8.8.8.8 linux-ru.ru | grep time
;; Query time: 64 msec
olej@R420:~$ dig @192.168.1.3 linux-ru.ru | grep time
;; Query time: 16 msec
Это время является основным параметром оптимизации выбора сервера DNS! - см.
DNS сервер +
выбор оптимальных DNS серверов
А вот как срабатывает кэширующий сервер systemd-resolved (несколько последовательных запросов через короткие интервалы времени):
Код: Выделить всё
olej@R420:~$ dig @127.0.0.53 linux-ru.ru | grep time
;; Query time: 220 msec
olej@R420:~$ dig @127.0.0.53 linux-ru.ru | grep time
;; Query time: 0 msec
olej@R420:~$ dig @127.0.0.53 linux-ru.ru | grep time
;; Query time: 4 msec
Re: ещё раз про DNS
Добавлено: 03 сен 2021, 16:14
Olej
Olej писал(а): ↑03 сен 2021, 15:49
А вот как срабатывает кэширующий сервер systemd-resolved (несколько последовательных запросов через короткие интервалы времени):
Код: Выделить всё
olej@R420:~$ dig @127.0.0.53 linux-ru.ru | grep time
;; Query time: 220 msec
Меня несколько смущает вот эта
первая задержка при запросах.
Возможно из-за того, что кэширующая служба использует какие-то "дальние" DNS.
Смотрю:
Код: Выделить всё
olej@R420:~$ cat /etc/systemd/resolved.conf
...
[Resolve]
#DNS=
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#DNSOverTLS=no
#Cache=no-negative
#DNSStubListener=yes
#ReadEtcHosts=yes
Пробую перенастроить:
Код: Выделить всё
olej@R420:~$ cat /etc/systemd/resolved.conf | grep ^DNS
DNS=192.168.1.3 1.1.1.1 8.8.8.4
Потом:
Код: Выделить всё
root@R420:/etc/systemd# systemctl restart systemd-resolved
root@R420:/etc/systemd# systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2021-09-03 16:12:38 EEST; 4s ago
Docs: man:systemd-resolved.service(8)
https://www.freedesktop.org/wiki/Software/systemd/resolved
https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
Main PID: 45446 (systemd-resolve)
Status: "Processing requests..."
Tasks: 1 (limit: 115834)
Memory: 4.8M
CGroup: /system.slice/systemd-resolved.service
└─45446 /lib/systemd/systemd-resolved
сен 03 16:12:38 R420 systemd[1]: Starting Network Name Resolution...
сен 03 16:12:38 R420 systemd-resolved[45446]: Positive Trust Anchors:
сен 03 16:12:38 R420 systemd-resolved[45446]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
сен 03 16:12:38 R420 systemd-resolved[45446]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20>
сен 03 16:12:38 R420 systemd-resolved[45446]: Using system hostname 'R420'.
сен 03 16:12:38 R420 systemd[1]: Started Network Name Resolution.
Код: Выделить всё
olej@R420:~$ dig @127.0.0.53 qnx.org.ru | grep time
;; Query time: 148 msec
olej@R420:~$ dig @127.0.0.53 qnx.org.ru | grep time
;; Query time: 0 msec