Вопрос или проблема
Извините, не знаю, является ли это проблемой Docker или проблемой dig на Rocky Linux 9. Все работает, как ожидалось, на Rocky Linux 8.
У меня есть файл docker-compose.yml ниже с сервисом под именем https. Это позволяет контейнеру ссылаться на хостнейм https. Хотя ping https работает, по какой-то причине dig https (DiG 9.16.23-RH) не работает на Rocky Linux 9. Он работает на Rocky Linux 8 (DiG 9.11.36-RedHat-9.11.36-16.el8_10.2). Если я изменю имя сервиса на httpsx, то dig httpsx будет работать.
services:
https:
image: "rockylinux:${RL_VERSION}"
command: bash -c "yum install -y iputils bind-utils && echo '=====dig version output====' && dig -v && echo '=====ping https output====' && ping -c 3 https && echo '=====dig https output====' && dig +short https"
environment:
- RL_VERSION
Работающий 8:
% RL_VERSION=8 docker-compose up
Подключение к https-1
https-1 | Rocky Linux 8 - AppStream 5.7 MB/s | 11 MB 00:01
...
https-1 | Завершено!
https-1 | =====dig version output====
https-1 | DiG 9.11.36-RedHat-9.11.36-16.el8_10.2
https-1 | =====ping https output====
https-1 | PING https (172.21.0.2) 56(84) байт данных.
https-1 | 64 байта от c3f0c7a6613c (172.21.0.2): icmp_seq=1 ttl=64 время=0.558 мс
https-1 | 64 байта от c3f0c7a6613c (172.21.0.2): icmp_seq=2 ttl=64 время=0.051 мс
https-1 | 64 байта от c3f0c7a6613c (172.21.0.2): icmp_seq=3 ttl=64 время=0.040 мс
https-1 |
https-1 | --- статистика ping для https ---
https-1 | 3 пакета передано, 3 получено, потерь пакетов 0%, время 2025мс
https-1 | rtt min/avg/max/mdev = 0.040/0.216/0.558/0.241 мс
https-1 | =====dig https output====
https-1 | 172.21.0.2
Неудача 9:
% RL_VERSION=9 docker-compose up
[+] Запуск 1/1
✔ Контейнер testhttps-https-1 Пересоздан 0.2s
Подключение к https-1
https-1 | Rocky Linux 9 - BaseOS 2.4 MB/s | 2.4 MB 00:00
...
https-1 | Завершено!
https-1 | =====dig version output====
https-1 | DiG 9.16.23-RH
https-1 | =====ping https output====
https-1 | PING https (172.21.0.2) 56(84) байт данных.
https-1 | 64 байта от 4a2841b5dac9 (172.21.0.2): icmp_seq=1 ttl=64 время=0.404 мс
https-1 | 64 байта от 4a2841b5dac9 (172.21.0.2): icmp_seq=2 ttl=64 время=0.117 мс
https-1 | 64 байта от 4a2841b5dac9 (172.21.0.2): icmp_seq=3 ttl=64 время=0.088 мс
https-1 |
https-1 | --- статистика ping для https ---
https-1 | 3 пакета передано, 3 получено, потерь пакетов 0%, время 2009мс
https-1 | rtt min/avg/max/mdev = 0.088/0.203/0.404/0.142 мс
https-1 | =====dig https output====
https-1 | c.root-servers.net.
https-1 | l.root-servers.net.
https-1 | e.root-servers.net.
https-1 | d.root-servers.net.
https-1 | i.root-servers.net.
https-1 | b.root-servers.net.
https-1 | g.root-servers.net.
https-1 | m.root-servers.net.
https-1 | a.root-servers.net.
https-1 | f.root-servers.net.
https-1 | h.root-servers.net.
https-1 | j.root-servers.net.
https-1 | k.root-servers.net.
Это не проблема Rocky и не проблема Docker, а особенность dig; я вижу ту же проблему на Debian 12.
То, что вы видите, является результатом того, как dig разбирает командную строку. Обычно синтаксис (в простом виде) можно считать dig name [type], но он также принимает dig [type] name.
Так что, если вы сделаете что-то вроде dig cname foobar, он будет искать ресурсную запись CNAME для foobar, так же, как если бы вы сделали dig foobar cname.
Если вы не укажете домен, то тип всей запроса станет dig . ns.
Теперь https был добавлен как тип RR, тогда как в более старой версии это не было.
И это то, что вызывает у вас проблему, потому что в новых версиях dig https также будет выглядеть так, как будто не передается доменное имя, и поэтому будет выполнен запрос . ns.
И мы можем увидеть это, взглянув на вывод:
% dig https
; <<>> DiG 9.16.23-RH <<>> https
;; глобальные параметры: +cmd
...
;; СЕКЦИЯ ВОПРОСА:
;. IN NS
Ответ состоит в том, чтобы поставить перед запросом -q. Теперь
% dig -q https
...
;; СЕКЦИЯ ВОПРОСА:
;https. IN A
Ответ или решение
На ваш вопрос относительно проблемы с командой dig в контейнере Docker в окружении Rocky Linux 9, можно ответить с точки зрения анализа изменения в поведении утилиты dig и её интерпретации аргументов.
Проблема: Не удается разрешить имя контейнера "https"
Вы упомянули, что при выполнении команды ping https все работает корректно, но dig https не возвращает ожидаемого результата в Rocky Linux 9, в то время как в Rocky Linux 8 это работает. При использовании dig в версии 9.16.23-RH он возвращает ответ от корневых DNS-серверов, что говорит о том, что запрос не может быть правильно разрешён.
Анализ поведения dig:
-
Отличия в версиях
dig: Утилитаdigв Rocky Linux 8 (9.11.36) и Rocky Linux 9 (9.16.23-RH) имеет несовпадающее поведение. В версии 9.16.23 были внесены изменения в то, какdigобрабатывает имя, которое вы передаёте в качестве аргумента. В частности, начиная с этой версии,digможет интерпретировать строкуhttpsкак тип записи DNS, а не как имя хоста, что изменяет его поведение. -
Направление запроса: Поскольку
digосуществляет запросы к DNS-серверам, в ситуации, когда не указан явный тип записи,digможет попытаться выполнить запрос к DNS на уровне корня, интерпретируяhttpsкак потенциальное имя записи DNS. Это подтверждается выводом в вашем случае, гдеdig httpsприводит к запросу на наличие NS-записей в корне DNS. -
Решение: Для того чтобы явно указать
dig, что вы хотите выполнить запрос к A-записи для данного хоста, вы можете использовать ключ-qперед именем:dig -q httpsТаким образом, вы удалите неоднозначность в том, что
digдолжен искать запись A для имени "https", а не пытаться разрешить его как тип записи.
Заключение:
Таким образом, проблема не является ошибкой в Docker или Rocky Linux 9, а скорее результатом изменения в том, как dig обрабатывает аргументы в своей более новой версии. Путем использования флага -q вы сможете решить описанную вами проблему.
Если вам необходимо, чтобы ваши команды работали консистентно между версиями, всегда полезно проверять изменения в документации для утилит, которые вы используете, особенно когда переходите на новые версии операционных систем или программного обеспечения.