1

When running bind in chroot, the mysql dlz driver cannot resolve the hostname of the mysql server (rds). Using amazon ami (centos based) in VPC.

Aug 25 10:22:27 paper named-sdb[6812]: Loading 'Mysql zone' using driver mysql
Aug 25 10:23:48 paper named-sdb[6812]: mysql driver failed to create database connection after 4 attempts
Aug 25 10:23:48 paper named-sdb[6812]: SDLZ driver failed to load.
Aug 25 10:23:48 paper named-sdb[6812]: DLZ driver failed to load.
Aug 25 10:23:48 paper named-sdb[6812]: loading configuration: failure
Aug 25 10:23:48 paper named-sdb[6812]: exiting (due to fatal error)

Installed Packages
bind.x86_64                32:9.8.2-0.30.rc1.38.amzn1  @amzn-updates
bind-chroot.x86_64         32:9.8.2-0.30.rc1.38.amzn1  @amzn-updates
bind-libs.x86_64           32:9.8.2-0.30.rc1.38.amzn1  @amzn-updates
bind-sdb.x86_64            32:9.8.2-0.30.rc1.38.amzn1  @amzn-updates
bind-utils.x86_64          32:9.8.2-0.30.rc1.38.amzn1  @amzn-updates

I can see it trying to connect to localhost instead of the amazon dns server to resolve the hostname. Note it is a udp connection:

# netstat -nputwc |grep named
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name   
udp        0      0 127.0.0.1:41551             127.0.0.1:53                ESTABLISHED 5531/named-sdb

I can resolve and connect directly the the mysql server via the command line. And if I configure bind not to use chroot, bind starts correctly. You can see bind with a successful tcp connection to the rds server.

Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name 
tcp        0      0 10.33.1.20:41700            10.33.42.9:3306             ESTABLISHED 5381/named-sdb      
tcp        0      0 10.33.1.20:41711            10.33.42.9:3306             ESTABLISHED 5381/named-sdb

Contents of /etc/resolv.conf

; generated by /sbin/dhclient-script
search us-west-2.compute.internal
nameserver 10.33.0.2

Previous research indicated that the issue is due the chroot being able to perform resolution. I've symlinked /etc/resolv.conf into the chroot /var/named/chroot/etc/resolv.conf, as well as copied the recommended libraries for performing the resolution without success.

/var/named/chroot/dev
/var/named/chroot/etc
/var/named/chroot/lib64
/var/named/chroot/usr
/var/named/chroot/var
/var/named/chroot/dev/null
/var/named/chroot/dev/random
/var/named/chroot/dev/zero
/var/named/chroot/etc/localtime
/var/named/chroot/etc/named
/var/named/chroot/etc/pki
/var/named/chroot/etc/resolv.conf
/var/named/chroot/etc/pki/dnssec-keys
/var/named/chroot/lib64/ld-linux-x86-64.so.2
/var/named/chroot/lib64/libgcc_s.so.1
/var/named/chroot/lib64/libnsl-2.17.so
/var/named/chroot/lib64/libnsl.so.1
/var/named/chroot/lib64/libnss_compat-2.17.so
/var/named/chroot/lib64/libnss_compat.so.2
/var/named/chroot/lib64/libnss_db-2.17.so
/var/named/chroot/lib64/libnss_db.so.2
/var/named/chroot/lib64/libnss_dns-2.17.so
/var/named/chroot/lib64/libnss_dns.so.2
/var/named/chroot/lib64/libnss_files-2.17.so
/var/named/chroot/lib64/libnss_files.so.2
/var/named/chroot/lib64/libnss_hesiod-2.17.so
/var/named/chroot/lib64/libnss_hesiod.so.2
/var/named/chroot/lib64/libnss_nis-2.17.so
/var/named/chroot/lib64/libnss_nis.so.2
/var/named/chroot/lib64/libnss_nisplus-2.17.so
/var/named/chroot/lib64/libnss_nisplus.so.2
/var/named/chroot/lib64/libresolv-2.17.so
/var/named/chroot/lib64/libresolv.so.2
/var/named/chroot/usr/lib64
/var/named/chroot/usr/lib64/bind
/var/named/chroot/usr/lib64/libevent-1.4.so.2
/var/named/chroot/usr/lib64/libevent-1.4.so.2.1.3
/var/named/chroot/usr/lib64/libevent-2.0.so.5
/var/named/chroot/usr/lib64/libevent-2.0.so.5.1.6
/var/named/chroot/usr/lib64/libevent.so
/var/named/chroot/usr/lib64/libevent_core-1.4.so.2
/var/named/chroot/usr/lib64/libevent_core-1.4.so.2.1.3
/var/named/chroot/usr/lib64/libevent_core-2.0.so.5
/var/named/chroot/usr/lib64/libevent_core-2.0.so.5.1.6
/var/named/chroot/usr/lib64/libevent_core.so
/var/named/chroot/usr/lib64/libevent_extra-1.4.so.2
/var/named/chroot/usr/lib64/libevent_extra-1.4.so.2.1.3
/var/named/chroot/usr/lib64/libevent_extra-2.0.so.5
/var/named/chroot/usr/lib64/libevent_extra-2.0.so.5.1.6
/var/named/chroot/usr/lib64/libevent_extra.so
/var/named/chroot/usr/lib64/libevent_openssl-2.0.so.5
/var/named/chroot/usr/lib64/libevent_openssl-2.0.so.5.1.6
/var/named/chroot/usr/lib64/libevent_openssl.so
/var/named/chroot/usr/lib64/libevent_pthreads-2.0.so.5
/var/named/chroot/usr/lib64/libevent_pthreads-2.0.so.5.1.6
/var/named/chroot/usr/lib64/libevent_pthreads.so
/var/named/chroot/usr/lib64/libnsl.so
/var/named/chroot/usr/lib64/libnss3.so
/var/named/chroot/usr/lib64/libnss_compat.so
/var/named/chroot/usr/lib64/libnss_db.so
/var/named/chroot/usr/lib64/libnss_dns.so
/var/named/chroot/usr/lib64/libnss_files.so
/var/named/chroot/usr/lib64/libnss_hesiod.so
/var/named/chroot/usr/lib64/libnss_nis.so
/var/named/chroot/usr/lib64/libnss_nisplus.so
/var/named/chroot/usr/lib64/libnssckbi.so
/var/named/chroot/usr/lib64/libnssdbm3.chk
/var/named/chroot/usr/lib64/libnssdbm3.so
/var/named/chroot/usr/lib64/libnsspem.so
/var/named/chroot/usr/lib64/libnsssysinit.so
/var/named/chroot/usr/lib64/libnssutil3.so
/var/named/chroot/usr/lib64/libresolv.so
/var/named/chroot/usr/lib64/libssl.so.1.0.1k
/var/named/chroot/usr/lib64/libssl.so.10
/var/named/chroot/usr/lib64/libssl3.so
dandan
  • 158
  • 7

1 Answers1

0

Solution:

Can't use a symlink inside the chroot.

Add to your rc.local, to run in boot: $ cp /etc/resolv.conf /var/named/chroot/etc/resolv.conf

This ensures that chrooted bind can use the name servers amazon assigns during cloud init. It will have no problem resolving dns within the chroot.

dandan
  • 158
  • 7