Регистрация Войти
Рейтинг:0
tegtmeye avatar Ubuntu

Ubuntu 20.04 разрешил ожидание отказа в результате IPV6 с помощью dnsmasq

флаг cn
tegtmeye

TL;DR

Мои DNS-запросы выполняются медленно, потому что systemd-resolved успешно запрашивает DNS-сервер по IPv4, но повторно запрашивает IPv6 после того, как DNS-сервер отвечает REFUSED. Это разрешенный конфиг выдан? Проблема с dnsmasq? или ошибка?

У меня есть стандартная установка ubuntu 20.04, подключенная к dnsmasq, работающему на устройстве с воздушным зазором (повсеместный краевой маршрутизатор) с доменом верхнего уровня «bar» (помните, с воздушным зазором, но это не похоже, не имеет значения, что это такое - т.е. .com и т. д.) . Запросы DNS быстро разрешаются через клиентов Mac и Windows. Для ubuntu DNS-запросы занимают около 5 секунд. Поискав вокруг, проблемы Ubuntu DNS обсуждаются во многих местах, но основное поведение, которое я вижу, мне неизвестно.

Проблема верхнего уровня: если я пингую машину с помощью Ubuntu, для возврата ответов требуется около 5 секунд:

$ пинг фу
# проходит около 5 секунд
PING foo.bar (10.2.1.132) 56(84) байт данных.
64 байта из foo.bar (10.2.1.132): icmp_seq=1 ttl=63 time=1,10 мс
64 байта из foo.bar (10.2.1.132): icmp_seq=2 ttl=63 time=1,02 мс
...

Что кажется очевидной проблемой тайм-аута. Хотя, что интересно, решается. Бег статус разрешения дает мне стандартный результат, включая то, что DNS предоставляется арендой DHCP, выданной dnsmasq.

$ статус разрешения

...
много вещей
...

Ссылка 3 (enp0s25)
      Текущие области: DNS     
Настройка DefaultRoute: да     
       Настройка LLMNR: да     
Настройка MulticastDNS: нет      
  Настройка DNSOverTLS: нет      
      Настройка DNSSEC: нет      
    Поддерживается DNSSEC: нет      
         DNS-серверы: 10.1.1.1
          DNS-домен: ~.      
                      бар

Остановка разрешена и запуск в режиме отладки показывает проблему. Машина с Ubuntu запрашивает DNS-сервер через IPv4 и немедленно получает ответ. Затем он повторно запрашивает через IPv6, на что DNS-сервер отвечает REFUSED, пока не истечет время ожидания.

$ sudo systemctl остановить systemd-разрешено
$ sudo SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-разрешено
...
много журналов запуска
...
Получил пакет запроса UDP-заглушки DNS для идентификатора 40457
Поиск RR для foo.bar IN A.
Переключение на DNS-сервер 10.1.1.1 для интерфейса enp0s25.
Промах кеша для foo.bar IN A
Транзакция 42924 для DNS области <foo.bar IN A> на enp0s25/*.
Использование уровня функций UDP+EDNS0 для транзакции 42924.
Использование DNS-сервера 10.1.1.1 для транзакции 42924.
Отправка пакета запроса с идентификатором 42924.
Обработка запроса...
Получил пакет запроса UDP-заглушки DNS для идентификатора 59119
Поиск RR для foo.bar IN AAAA.
Промах кеша для foo.bar IN AAAA
Транзакция 21734 для домена области <foo.bar IN AAAA> на enp0s25/*.
Использование уровня функций UDP+EDNS0 для транзакции 21734.
Использование DNS-сервера 10.1.1.1 для транзакции 21734.
Отправка пакета запроса с идентификатором 21734.
Обработка запроса...
Обработка входящего пакета по транзакции 42924 (rcode=SUCCESS).
Подтверждено, что мы получаем ответ на уровне функций UDP+EDNS0 от DNS-сервера 10.1.1.1.
Добавлена ​​положительная запись кэша без проверки подлинности для foo.bar IN A 7200s на enp0s25/INET/10.1.1.1.
Транзакция 42924 для <foo.bar IN A> в области dns на enp0s25/* теперь завершена с <success> из сети (без знака).
Отправка ответного пакета с идентификатором 40457 на интерфейс 1/AF_INET.
Освобождение транзакции 42924.
Обработка входящего пакета по транзакции 21734 (rcode=REFUSED).
Сервер вернул REFUSED, переключение серверов и повторная попытка.
Повторная попытка транзакции 21734.
Промах кеша для foo.bar IN AAAA
Транзакция 21734 для домена области <foo.bar IN AAAA> на enp0s25/*.
Использование уровня функций UDP+EDNS0 для транзакции 21734.
Отправка пакета запроса с идентификатором 21734.
Обработка входящего пакета по транзакции 21734 (rcode=REFUSED).
Сервер вернул REFUSED, переключение серверов и повторная попытка.
...
повторяется в течение ~ 5 секунд
...
Транзакция 44267 для <foo.bar IN AAAA> в dns области на enp0s25/* теперь завершена с <количество попыток-макс-достигнуто> из сети (без знака).
Освобождение транзакции 44267.

Также предполагая, что это проблема:

$ nslookup foo
Сервер: 127.0.0.53
Адрес: 127.0.0.53#53

Неавторитетный ответ:
Имя: foo.bar
Адрес: 10.2.1.132
...
проходит около 5 секунд
...
;; время соединения истекло; нет доступа к серверам

# это немедленно возвращается
$ nslookup -query=A foo
Сервер: 127.0.0.53
Адрес: 127.0.0.53#53

Неавторитетный ответ:
Имя: foo.bar
Адрес: 10.2.1.132

# время ожидания истекает примерно через 5 секунд.
$ nslookup -query=AAAA foo
;; время соединения истекло; нет доступа к серверам

Вопросы:

  1. Если DNS-сервер предоставлял хороший ответ IPv4, почему машина с Ubuntu ждала бы, неоднократно безуспешно пытаясь получить ответ IPv6?

  2. Это проблема конфигурации Ubuntu или проблема dnsmasq?

Заранее спасибо.

387
0 + 2
DNS
tegtmeye avatar
флаг cn
tegtmeye
Кстати, я нашел кого-то, кто опубликовал аналогичную проблему в списке рассылки dnsmasq: https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2019q2/013094.html.
0
Ответить
tegtmeye avatar
флаг cn
tegtmeye
Некоторый дополнительный контент, который заставляет меня думать, что существует проблема как с решенным, так и с dsnmasq. Тот факт, что dnsmasq возвращает REFUSED, кажется ошибкой (см. RFC 4074 «Общее неправильное поведение в отношении DNS-запросов для адресов IPv6»). Если он не знает, что такое адрес IPv6, он должен вернуть пустой ответ в соответствии с RFC, но, возможно, я неправильно истолковываю. Тем не менее, разрешенный не должен повторно стучать по DNS-серверу после того, как он отказался вам отвечать. Смотрите также: https://lists.isc.org/pipermail/bind-users/2018-April/100056.html https://bugs.centos.org/view.php?id=16317
0
Ответить
Рейтинг:0
mendaxca avatar Ubuntu
флаг jp
mendaxca

Я столкнулся с точно такой же проблемой при настройке systemd-разрешение и dnsmasq.

Что касается вашего вопроса 1, я не могу понять, почему systemd-разрешение запрос на АААА записывать повторно, пока нет ответа от dnsmasq.

По вопросу 2, dnsmasq неправильно настроен для добавления записи для foo.bar. Вы только добавляете А запись для этого доменного имени, в то время как systemd-разрешение запрос для обоих А и АААА записывать одновременно. dnsmasq понятия не имеет в АААА запись для этого домена, поэтому он перенаправляет этот запрос на вышестоящий сервер. Я не знаю, что будет дальше, но dnsmasq не дает ожидаемого ответа.

Вы не упомянули, как вы настраиваете dnsmasq. В моем тесте любая конфигурация ниже будет работать как положено. Обратите внимание, что есть разница между 1 и 2, 3.

  1. адрес=/foo.bar/10.2.1.132/
  2. местный=/бар/, addn-hosts=/tmp/hosts и добавить 10.2.1.132 foo.bar к /tmp/хост
  3. хост-запись = foo.bar, 10.2.1.132 и местный=/бар/

От dnsmasq справочная страница для опции --местный

Также разрешен флаг -S, который дает домен, но не IP-адрес; это сообщает dnsmasq, что домен является локальным и может отвечать на запросы от /etc/hosts или DHCP, но никогда не должен перенаправлять запросы в этом домене на какие-либо вышестоящие серверы. --local является синонимом --server, чтобы сделать файлы конфигурации более понятными в этом случае.

0 + 0
флаг Moldova
Admin
Этот вопрос на других языках:

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.