Docker Embedded DNS returns truncated domain name when doing reverse ns lookup

creatldd1 creatldd1

4/17/24, 7:11 PM

I've been trying to setup domain name inside a container and check how the embedded Docker DNS deals with those settings. But I was surprised to see that I was only given a truncated domain name when doing reverse ns lookup.

I set the fqdn to be like ldec<i>.n18.org The command hostname --fqdn inside the container returned me ldec1.n18.org as expected, the ping ping ldec1.n18.org is working as expected with fqdn properly resolved.

But if I do a reverse ns lookup like dig -x <container_ip>, I am always returned with a truncated domain name like ldec3.n18 instead of 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

So why dig returns me a truncated domain name ?

To build the image

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

To start the 3 containers on the same network

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

156

1 + 2

domain-name-system

docker

creatldd1 creatldd1

4/17/24, 8:23 PM

To the person who down-voted, I would have appreciated a comment to point out the glaring mistake that justified it. I admit being a nube on anything dns related.

Patrick Mevzek

4/17/24, 11:50 PM

`dig` displays whatever the nameserver gave to it, so check the nameserver zonefile, you probably add an extra dot that made the name absolute, where removing it will make it relative again to the zone in which it sits.

Score:0

Server

creatldd1 creatldd1

5/2/24, 6:38 AM

To answer my own question, I tested with Podman V3 along with the dnsname plugin and with dnsmasq on the host and at last I got what I was expecting

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

So it seems Docker's internal DNS has a very specific/opinionated way of answering reverse DNS requests and if you need a more conventionnal DNS behavior, to test your ansible roles dealing with network configurations etc..., you might be better off using Podman V3 or trying to shunt Docker's internal DNS and use something like dnsmasq or bind9.

Check also this related thread on SO that explains: how-can-i-give-docker-containers-access-to-a-dnsmasq-local-dns-resolver-on-the-h.

EDIT2: Docker's Embedded DNS

Reverse DNS queries on hosts inside a custom networks is 'peculiar' and Docker won't let you disable their embedded DNS (dates back to 2017):

So in 2023, you are still left with workarounds with /etc/resolv and /etc/hosts or patching the code to disable the ES.

+ 0

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Docker Embedded DNS returns truncated domain name when doing reverse ns lookup

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.