ещё раз про DNS

[Olej]

Эта тема в продолжение DNS сервер:
- там слишком много было (интересных) разбирательств...
- и многое поменялось за прошедшие несколько лет.

[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

[Olej]

Инструменты наблюдение и проверки работоспособности 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 терминал - потерян).

[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.

[Olej]

Но с некоторых пор (я не знаю от когда, не отследил) кэширующая 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).
...

[Olej]

Это нововведение радикально меняет многолетнюю стратегию использования кэширующих 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

[Olej]

с некоторых пор (я не знаю от когда, не отследил) кэширующая 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 года назад

[Olej]

Это нововведение радикально меняет многолетнюю стратегию использования кэширующих DNS.

Порядок разрешения имён на сейчас установлен:

Код: Выделить всё

olej@R420:~$ cat /etc/nsswitch.conf | grep hosts
hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname

[Olej]

Инструменты наблюдение и проверки работоспособности 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

[Olej]

А вот как срабатывает кэширующий сервер 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