Bug 1297562

Summary: WKS records cannot be parsed with bind-chroot installed
Product: Red Hat Enterprise Linux 6 Reporter: Dan Astoorian <djast>
Component: bindAssignee: Petr Menšík <pemensik>
Status: CLOSED ERRATA QA Contact: Petr Sklenar <psklenar>
Severity: medium Docs Contact:
Priority: low    
Version: 6.7CC: pemensik, psklenar, thozza
Target Milestone: rcKeywords: Patch
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: bind-9.8.2-0.59.rc1.el6 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1392362 (view as bug list) Environment:
Last Closed: 2017-03-21 10:06:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1392362    
Attachments:
Description Flags
named.wks none

Description Dan Astoorian 2016-01-11 21:30:04 UTC
Description of problem:
With bind-chroot installed, zone files containing WKS records are rejected with "unknown protocol" errors.

Version-Release number of selected component (if applicable):
bind-chroot-9.8.2-0.37.rc1.el6_7.5.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Add a WKS record to an existing zone file; /var/named/named.localhost will do.  E.g., 
    echo -e '\tWKS 127.0.0.1 TCP (smtp)' >> /var/named/named.localhost
2. yum install bind-chroot
3. service named start

Actual results:
Starting named: 
Error in named configuration:
dns_rdata_fromtext: named.localhost:11: near 'TCP': unknown protocol
zone localhost.localdomain/IN: loading from master file named.localhost failed: unknown protocol
zone localhost.localdomain/IN: not loaded due to errors.
_default/localhost.localdomain/IN: unknown protocol
dns_rdata_fromtext: named.localhost:11: near 'TCP': unknown protocol
zone localhost/IN: loading from master file named.localhost failed: unknown protocol
zone localhost/IN: not loaded due to errors.
_default/localhost/IN: unknown protocol
zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0
zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
zone 0.in-addr.arpa/IN: loaded serial 0
                                                           [FAILED]


Expected results:
Starting named:                                            [  OK  ]


Additional info:
Note that if the bind-chroot package is removed, named will start up successfully.

The problem is caused by the inability of the chroot'd environment to look up protocols and services (in /etc/protocols and /etc/services, respectively).

It appears that for 64-bit systems, creating the directory /var/named/chroot/lib64/ and changing:

ROOTDIR_MOUNT='/etc/named /etc/pki/dnssec-keys /var/named /etc/named.conf /etc/named.dnssec.keys /etc/named.rfc1912.zones /etc/rndc.conf /etc/rndc.key /usr/lib64/bind /usr/lib/bind /etc/named.iscdlv.key /etc/named.root.key'

to:

ROOTDIR_MOUNT='/etc/named /etc/pki/dnssec-keys /var/named /etc/named.conf /etc/named.dnssec.keys /etc/named.rfc1912.zones /etc/rndc.conf /etc/rndc.key /usr/lib64/bind /usr/lib/bind /etc/named.iscdlv.key /etc/named.root.key /etc/services /etc/protocols /lib64/libnss_files.so.2'

in /etc/rc.d/init.d/named may be sufficient to allow named to launch.  (This probably presumes the user is using the default NSS backend for protocols and services; if /etc/nsswitch.conf has been customized, the adjustments may not be as straightforward.)

A similar issue may exist in Red Hat Enterprise Linux 7 (I first encountered it in CentOS 7; I do not have an installed RHEL7 system to test against).

Comment 5 Petr Menšík 2016-10-26 15:25:09 UTC
Created attachment 1214323 [details]
named.wks

Minimal zone to reproduce failure. With bind-chroot installed, it will prevent bind from starting.
Save it to /var/named
Just yum install -y bind-chroot

and add to named.conf

zone "wks.localdomain" IN {
        type master;
        file "named.wks";
        allow-update { none; };
};

Comment 14 errata-xmlrpc 2017-03-21 10:06:23 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2017-0651.html