| Summary: | WKS records cannot be parsed with bind-chroot installed | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Dan Astoorian <djast> | ||||
| Component: | bind | Assignee: | Petr Menšík <pemensik> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Petr Sklenar <psklenar> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 6.7 | CC: | pemensik, psklenar, thozza | ||||
| Target Milestone: | rc | Keywords: | 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: | |||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1392362 | ||||||
| Attachments: |
|
||||||
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; };
};
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 |
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).