misc/74314: DNS resolver broken under certain jail conditions
Juan Pablo Villa
juan at datafull.com
Tue Nov 23 22:50:22 PST 2004
>Synopsis: DNS resolver broken under certain jail conditions
>Arrival-Date: Wed Nov 24 06:50:21 GMT 2004
>Originator: Juan Pablo Villa
FreeBSD XXXXXX.datafull.com 4.9-RELEASE-p13 FreeBSD 4.9-RELEASE-p13 #0: Sat Nov 20 22:57:03 ART 2004 root@:/usr/obj/usr/src/sys/GENERIC i386
Also tested this with 4.10-RELEASE, 4.9-RELEASE, and 4.10-STABLE this one built on Nov 19 2004 (approx.). I've enjoyed my weekend rebuilding world like crazy, looking to avoid this bug without any results.
When creating new jails for mi internal network, I hit the following:
I have 2 ethernet interfaces, lets say dc0 and dc1.
dc0 has an ip public address, connected to the internet thru a default gw
dc1 has a private ip address (i.e. 10.3.2.102)
If I start the jail env with an aliased ip from dc0, everything works ok, just as usual.
However, using aliases from dc1, things are a little bit different, because the resolver seems broken from inside the jail.
Netcat and UDP traffic in general to host/outside seems ok in both ways, but DNS lookups don't work anymore.
Dig lookups from inside the jail result in the following:
; <<>> DiG 8.3 <<>> freebsd.org
;; res options: init recurs defnam dnsrch
;; res_nsend: Operation timed out
or a similar res_nsend error.
Looking on the internet, a similar case is described on: http://archive.pilgerer.org/mharc/html/freebsd-questions/2004-04/msg02948.html
I guess that using jail aliases within the same net as the default gw works, and the rest of aliases don't (the rest don't have a default gw on the same net, of course). Just guessing.
1) Create a jail env, as explained on jail(8)
2) Create an alias on dc1 for the jail (i.e. ifconfig dc1 -alias 10.3.2.11 netmask 255.255.255.255). dc1 must not be your main interface
3) Copy a working /etc/resolv.conf from host to jail
4) Initialize jail with that previous ip alias (i.e. jail /usr/jail/ jail.datafull.com 10.3.2.11 /bin/sh)
5) dig freebsd.org
6) nc -u YOUR_DNS.com 53
Just guessing here: If normal UDP traffic is possible (as shown by netcat), then a temporary workaround would be to install a recursive dns like dnscache (on host, or could be on the jail too). Haven't tried yet.
More information about the freebsd-bugs