https://bugzilla.redhat.com/show_bug.cgi?id=1128208
--- Comment #16 from Bill C. Riemers <briemers(a)redhat.com> ---
Writing the rules, fairly trivial:
In the container:
iptables -t nat -I PREROUTING -p tcp -d 127.0.0.1/8 --dport 53 -j DNAT
--to-destination 172.17.42.1:53
iptables -t nat -I PREROUTING -p udp -d 127.0.0.1/8 --dport 53 -j DNAT
--to-destination 172.17.42.1:53
On the host:
iptables -t nat -I PREROUTING -p tcp -d 172.17.42.1 --dport 53 -j DNAT
--to-destination 127.0.0.1:53
iptables -t nat -I PREROUTING -p udp -d 172.17.42.1 --dport 53 -j DNAT
--to-destination 127.0.0.1:53
Presumably one also needs to set the kernel flags that allow loopback traffic
to be routed...
The challenge here is the firewall rules would need to be set-up without the
container doing any iptables calls. Presumably one would want a configuration
option to selectively enable or disable this feature as well, as otherwise it
would be impossible for a container to run it's own DNS server. I think right
now it is possible just difficult because you can't update the /etc/resolv.conf
file to use the containers DNS server...
I doubt docker-io has the infrastructure to specify custom firewall rules for
the container, so a brand new framework would need to be added. That is
probably well beyound the what shoud be done to address this particular issue.
I think actually the patch you found will address 99% of the use cases for a
niche condition that only effects 1% of the users. So I would personally
consider anything beyond the patch you found as an enhancement. It is probably
higher priority to address issues like being able to resize /dev/shm than it is
to work on niche loopback DNS scenarios.
Like most docker-io problems there are workarounds, it is just a question if
the workaround is sufficient short term and long term.
Bill
--
You are receiving this mail because:
You are on the CC list for the bug.