Bug 643619 - Preventing querying of private addresses also prevents forwarders to be queried.
Preventing querying of private addresses also prevents forwarders to be queried.
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Adam Tkac
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2010-10-16 08:43 EDT by Eddie Lania
Modified: 2013-04-30 19:47 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-09-08 16:15:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Eddie Lania 2010-10-16 08:43:42 EDT
Description of problem:

When I use the following directions:

# prevent "RFC 1918 response from Internet for"
# 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 {; };
        forward first;

zone "lania-intra.net" IN {
        type forward;
        forwarders {; };
        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):


How reproducible: Always

Steps to Reproduce:
1. See my explanation above.
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:
Comment 1 Adam Tkac 2010-10-22 04:40:47 EDT
I tested following setup:

Two interfaces, both are in different network:

lo:1      Link encap:Local Loopback  
          inet addr:  Mask:

lo:2      Link encap:Local Loopback  
          inet addr:  Mask:

I setup the first server (listening on 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 and everything works fine.

Please try following:

1. Manually query the forwarder via `dig` utility (dig @ -x 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.
Comment 2 Eddie Lania 2010-10-22 14:56:40 EDT

[root@ls2ka ~]# dig @ -x

; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> @ -x
; (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


;; ANSWER SECTION: 86400 IN	PTR	p3000fedora.lania-intra.net.

169.168.192.in-addr.arpa. 86400	IN	NS	ns1.lania-intra.net.

ns1.lania-intra.net.	86400	IN	A
ns1.lania-intra.net.	86400	IN	AAAA	fdf6:17b0:be3c::4

;; Query time: 55 msec
;; WHEN: Fri Oct 22 20:17:22 2010
;; MSG SIZE  rcvd: 149


[root@ls2ka sysconfig]# nslookup

** server can't find NXDOMAIN

There is nothing in the named.run related to the above query
Comment 3 Bug Zapper 2011-05-31 07:13:27 EDT
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: 

Note You need to log in before you can comment on or make changes to this bug.