Expected behavior
After starting a container with port 53 published, host is able to aim DNS queries at localhost and have them go through the container.
Actual behavior
Queries never reach the container.
Information
MacBook Pro OS X Yosemite Version 10.10.5
docker version
Client:
Version: 1.12.0-rc3
API version: 1.24
Go version: go1.6.2
Git commit: 91e29e8
Built: Sat Jul 2 00:09:24 2016
OS/Arch: darwin/amd64
Experimental: true
Server:
Version: 1.12.0-rc3
API version: 1.24
Go version: go1.6.2
Git commit: 876f3a7
Built: Tue Jul 5 02:20:13 2016
OS/Arch: linux/amd64
Experimental: true
Steps to reproduce the behavior
-
Build image using this Dockerfile
FROM ubuntu:16.04
RUN apt-get update
RUN apt-get install -y dnsmasq
tcpdump
RUN echo “user=root” >> /etc/dnsmasq.conf -
Launch container using this docker-compose.yml
version: '2’
services:
dnsmasq:
image: port53_test
tty: true
ports:- “53:53/udp"
entrypoint: [”/bin/sh", “-c”, “dnsmasq && bin/bash”]
- “53:53/udp"
-
Run tcpdump on container in separate terminal window
$ docker exec -it <container_ID> /bin/bash
root@23d1ee3599b2:/# tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes -
dig or other dns query tool from the host machine
$ dig @localhost google.com
; <<>> DiG 9.8.3-P1 <<>> @localhost google.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 4060
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;google.com. IN A
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Wed Jul 13 13:45:43 2016
;; MSG SIZE rcvd: 28
I expect to see a result here, and if not, at least some output from tcpdump on the container. I see neither. Additionally, trying this with any other port (changing the line in the docker-compose.yml to - “54:53/udp” for example) and then doing dig @localhost -p 54 google.com produces the expected result (both an answer to the dns query and activity on tcpdump).
This was working as expected for me from about 6/28/16 to 7/8/16 but when I tried my (untouched) setup after the weekend it gave the behavior I described here.