Bug 643619 - Preventing querying of private addresses also prevents forwarders to be queried.
Summary: Preventing querying of private addresses also prevents forwarders to be queried.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: bind
Version: 15
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Adam Tkac
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-10-16 12:43 UTC by Eddie Lania
Modified: 2013-04-30 23:47 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2011-09-08 20:15:01 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Eddie Lania 2010-10-16 12:43:42 UTC
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:

Comment 1 Adam Tkac 2010-10-22 08:40:47 UTC
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.

Comment 2 Eddie Lania 2010-10-22 18:56:40 UTC
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

Comment 3 Bug Zapper 2011-05-31 11:13:27 UTC
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


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