0
задан 8 July 2020 в 18:09

1 ответ

Я собираюсь ответить на ваши вопросы не по порядку, потому что они все немного отличаются, но также потому, что ответы на один помогут вам понять ответы на другой и т. Д.

Ответ на вопрос № 2: как работают DNS-серверы в вашей системе, и частичный ответ на вопрос № 3 о том, что делает resolv.conf

Если в вашей системе используется несколько DNS-серверов, они запрашиваются по порядку. Так что если мой resolv.conf имеет:

nameserver 1.2.3.4
nameserver 5.6.7.8
nameserver 10.10.1.0
nameserver 127.0.0.53

... тогда все, что запрашивает запись DNS в вашей системе, сначала попытается 1.2.3.4. Если 1.2.3.4 отвечает, то это конец (включает ответы об ошибках SERVFAIL и ответы NXDOMAIN, оба из которых являются «действительными ответами»). Однако, если в ответе истекает время ожидания и ответ не возвращается, он пытается выполнить следующий сервер - 5.6.7.8. Если 5.6.7.8 отвечает, то на этом останавливается. Если он не отвечает, затем он продолжает пытаться 10.10.1.0. Это продолжается до тех пор, пока один из серверов, перечисленных в порядке, не выдаст ответ, или пока не истечет время ожидания. Это сделано по замыслу DNS, так как «первым, кто на самом деле ответит, является тот, который мы обрабатываем»

Это происходит потому, что он идет в порядке поиска по первичным, вторичным, третичным, четвертичным и т. Д. Первый ответ останавливает цепочку поиска.

Последний в вашем списке и в списке примеров здесь, 127.0.0.53, переходит к вашей заглушке SystemD ResolveD, где находится ответ на вопрос №3.

Ответ к # 3: Чем это отличается от ваших настроек графического интерфейса?

Короче говоря, resolv.conf используется для определения настроек приоритета вашего DNS-сервера. НОРМАЛЬНО в 18.04 он просто укажет на 127.0.0.53 , который является вашим системно-разрешенным обработчиком.

Ваш обработчик systemd-resolved будет, в свою очередь, получать настройки вашего графического интерфейса администратора сети, которые ваши DNS-серверы будут использовать для своих рекурсивных запросов. Это пример настроек, введенных моими настройками графического интерфейса пользователя в systemd-resolved для моего соединения Wi-Fi:

$ systemd-resolve --status
  ....
    Link 2 (wlp59s0)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 10.10.1.0
          DNS Domain: ~.

Что происходит, когда ваша система получает запрос DNS и передает его 127.0.0.53, который будет проверьте его локальный кэш DNS, чтобы увидеть, есть ли уже известная запись. Затем, в случае сбоя, он запрашивает DNS-серверы, указанные в системе. В этом случае, если предположить, что мой resol.conf является базовой системой и выглядит следующим образом:

$ cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "systemd-resolve --status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53

... приведет к поиску google.com для перехода к локальный системно-разрешенный экземпляр , и если у него нет кэшированной записи DNS, он перейдет к 10.10.1. 0 с DNS-запросом изнутри разрешен .

Однако в вашей системе поведение будет отличаться для ответа № 2, поскольку в вашем resolv.conf есть несколько других ревизий, которые прервут этот процесс. .

Ответ на вопрос 1. Что это за адреса?

Кто-то или что-то изменило вашу систему resolv.conf для добавления этих дополнительных адресов.

Это делали вы или Докер. 10.0.0.10 может быть другим экземпляром Docker или другим прослушивателем Docker через dnsmasq или иным образом, или какой-либо другой сетью в вашей среде, добавившей это.

К сожалению, мы не можем дать никакого представления о 10.0.0.10, поскольку это может быть что угодно. Мы можем идентифицировать 172.17.0.1, потому что вы сказали, что это Docker, и 127.0.0.53, потому что это SystemD ResolveD.

127.0.0. 53, как я сказал в ответе на № 2 и № 3 выше, это ваш системно-разрешенный , которому задаются настройки DNS вашего графического интерфейса.

Ответ на # 4: Как сделать изменение постоянным?

Если вы не удалите символическую ссылку, файл будет предоставлен resolvconf . Если ваш resolvconf не настроен иначе, это будет символическая ссылка. Единственный способ сделать постоянное изменение - это разорвать символическую ссылку, а затем просто получить статический файл. Итак, чтобы использовать ваш Docker DNS, а затем системный DNS, у вас будет статический файл для /etc/resolv.conf , который будет иметь следующее:

# THIS IS NOT FED BY resolvconf, any changes here are PERMANENT.
nameserver 172.17.0.1
nameserver 127.0.0.53

Это будет постоянная настройка конфигурации. до тех пор, пока вы не измените его или что-то еще, не установите resolv.conf обратно на символическую ссылку.

К сожалению, однако, если не считать удаления символической ссылки и замены статическим файлом,

2
ответ дан 30 July 2020 в 22:11

Другие вопросы по тегам:

Похожие вопросы: