
Я пытался настроить доменное имя внутри контейнера и проверить, как встроенный Docker DNS справляется с этими настройками. Но я был удивлен, увидев, что мне дали только усеченное доменное имя при выполнении обратного поиска ns.
Я установил полное доменное имя следующим образом: ldec<i>.n18.org
Команда hostname --fqdn
внутри контейнера вернула мне ldec1.n18.org
ожидаемый ответ, пинг ping ldec1.n18.org
работает ожидаемым образом, полное доменное имя разрешено правильно.
Но если я выполняю обратный поиск ns, например dig -x <container_ip>
, я всегда получаю укороченное доменное имя, например ldec3.n18
вместо ldec3.n18.org
.
root@ldec3:/# dig -x 172.18.0.4
; <<>> DiG 9.16.37-Debian <<>> -x 172.18.0.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21081
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;4.0.18.172.in-addr.arpa. IN PTR
;; ANSWER SECTION:
4.0.18.172.in-addr.arpa. 600 IN PTR ldec3.n18.
;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11)
;; WHEN: Mon Apr 17 18:59:38 UTC 2023
;; MSG SIZE rcvd: 87
Так почему же dig возвращает мне укороченное доменное имя?
Чтобы создать образ
docker build --tag=debian:11-lde - <<EOF
FROM debian:11
ARG DEBIAN_FRONTEND=noninteractive
ENV APT_CMD="apt-get install -y --no-install-recommends"
# SHELL ["/bin/bash", "-x", "-c"]
RUN echo "===> Add tools..." \
&& apt-get update \
&& apt-get install -y --no-install-recommends \
iputils-ping bind9-dnsutils lsof \
openssh-* \
wget curl \
iptables whois iproute2 net-tools \
vim less sudo bash-completion patch \
ca-certificates \
&& apt-get autoremove -y \
&& echo OK
EOF
Для запуска 3 контейнеров в одной сети
docker network create --driver=bridge n18 --subnet=172.18.0.0/24 || true
for i in $(seq 1 1 3)
do
docker rm -f "ldec${i}" || true
declare domain="n18.org"
docker run --interactive --tty --detach --rm --name "ldec${i}" \
--network=n18 --hostname="ldec${i}.${domain}" \
--dns="8.8.8.8" \
debian:11-lde
done
решение1
Чтобы ответить на свой вопрос, я протестировал Podman V3 вместе с плагином dnsname и dnsmasq на хосте, и наконец получил то, что ожидал.
...
;; QUESTION SECTION:
;4.0.5.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
4.0.5.192.in-addr.arpa. 0 IN PTR ldec3.newnet.podman.
...
Таким образом, похоже, что внутренний DNS Docker имеет очень специфический/упрямый способ ответа на обратные DNS-запросы, и если вам нужно более традиционное поведение DNS, чтобы протестировать роли Ansible, связанные с сетевыми конфигурациями и т. д., вам, возможно, лучше использовать Podman V3 или попытаться шунтировать внутренний DNS Docker и использовать что-то вроде dnsmasq или bind9.
Проверьте также эту связанную ветку на SO, которая объясняет:как-можно-предоставить-docker-контейнерам-доступ-к-dnsmasq-local-dns-resolver-на-h.
ПРАВКА2:Встроенный DNS Docker
Обратные DNS-запросы на хостах внутри пользовательских сетей «необычны», и Docker не позволит вам отключить их встроенный DNS (с 2017 года):
- https://github.com/moby/moby/issues/26298#issuecomment-339126461
- https://github.com/moby/moby/issues/19474#issuecomment-335253478
Таким образом, в 2023 году вам по-прежнему придется обходиться обходными путями с помощью /etc/resolv и /etc/hosts или вносить исправления в код для отключения ES.