Red Hat Bugzilla – Bug 643619
Preventing querying of private addresses also prevents forwarders to be queried.
Last modified: 2013-04-30 19:47:28 EDT
Description of problem: When I use the following directions: # prevent "RFC 1918 response from Internet for 0.0.0.10.IN-ADDR.ARPA" # If the IN-ADDR.ARPA name covered refers to a internal address space you are # using then you have failed to follow RFC 1918 usage rules and are leaking # queries to the Internet. You should establish your own zones for these # addresses to prevent you querying the Internet's name servers for these # addresses. Please see http://as112.net/ for details of the problems you are # causing and the counter measures that have had to be deployed. # If you are not using these private addresses then a client has queried for # them. You can just ignore the messages, get the offending client to stop # sending you these messages as they are most probably leaking them or setup # your own zones empty zones to serve answers to these queries. And I have in named.conf: zone "10.in-addr.arpa" { type master; file "named.empty"; }; zone "16.172.in-addr.arpa" { type master; file "named.empty"; }; zone "31.172.in-addr.arpa" { type master; file "named.empty"; }; zone "168.192.in-addr.arpa" { type master; file "named.empty"; }; But I also have a forwarder for DNS resolution from a different subnet: zone "169.168.192.in-addr.arpa" { type forward; forwarders { 192.168.169.4; }; forward first; }; zone "lania-intra.net" IN { type forward; forwarders { 192.168.169.4; }; forward first; }; I noticed that querying the forwarder for this forward zone also doesn't work anymore. That should still be possible. Version-Release number of selected component (if applicable): bind-9.7.1-2.P2.fc13.i686 How reproducible: Always Steps to Reproduce: 1. See my explanation above. 2. 3. Actual results: Preventing querying of private space addresses also prevents private space forwarders to be queried. Expected results: Preventing querying of private space addresses should still allow for private space forwarders to be queried. Additional info:
I tested following setup: Two interfaces, both are in different network: lo:1 Link encap:Local Loopback inet addr:192.168.1.1 Mask:255.255.255.0 lo:2 Link encap:Local Loopback inet addr:192.168.2.1 Mask:255.255.255.0 I setup the first server (listening on 192.168.1.1) as primary for "2.168.192.in-addr.arpa" and set forward zone for "2.168.192.in-addr.arpa" on the second server (listenning on 192.168.2.1) and everything works fine. Please try following: 1. Manually query the forwarder via `dig` utility (dig @192.168.169.4 -x 192.168.169.1) to ensure it responds correctly. 2. Start your server which can't forward queries with "-d3" parameter (add it to /etc/sysconfig/named), perform a query for <X>.169.168.192.in-addr.arpa record and attach /var/named/data/named.run file. Make sure you have something like logging { channel default_debug { file "data/named.run"; severity dynamic; }; }; in your named.conf to ensure all debugging data ends in /var/named/data/named.run file. Thank you in advance.
1. [root@ls2ka ~]# dig @192.168.169.4 -x 192.168.169.233 ; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> @192.168.169.4 -x 192.168.169.233 ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44567 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; QUESTION SECTION: ;233.169.168.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 233.169.168.192.in-addr.arpa. 86400 IN PTR p3000fedora.lania-intra.net. ;; AUTHORITY SECTION: 169.168.192.in-addr.arpa. 86400 IN NS ns1.lania-intra.net. ;; ADDITIONAL SECTION: ns1.lania-intra.net. 86400 IN A 192.168.169.4 ns1.lania-intra.net. 86400 IN AAAA fdf6:17b0:be3c::4 ;; Query time: 55 msec ;; SERVER: 192.168.169.4#53(192.168.169.4) ;; WHEN: Fri Oct 22 20:17:22 2010 ;; MSG SIZE rcvd: 149 2. [root@ls2ka sysconfig]# nslookup 192.168.169.233 Server: 127.0.0.1 Address: 127.0.0.1#53 ** server can't find 233.169.168.192.in-addr.arpa.: NXDOMAIN There is nothing in the named.run related to the above query
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping