How to prevent bind server resolving private IP addresses and leaking them to external network?

Solution Verified - Updated -

Environment

  • Red Hat Enterprise Linux 4
  • Red Hat Enterprise Linux 5
  • Red Hat Enterprise Linux 6
  • bind

Issue

  • In /var/log/messages will be logged messages as below
named[6181]: 11-Feb-2011 09:49:56.024 security: warning: client 127.0.0.1#47583: RFC 1918 response from Internet for xx.xx.xx.xx.in-addr.arpa

Resolution

Solution 1

  • It is necessary to create empty zones for every set of private IP addresses used

  • An example is shown below:

zone "10.IN-ADDR.ARPA" {  
type master;  
file "empty";  
};

zone "16.172.IN-ADDR.ARPA" {  
type master;  
file "empty";  
};

(..snip..)

zone "31.172.IN-ADDR.ARPA" {  
type master;  
file "empty";  
};

zone "168.192.IN-ADDR.ARPA" {  
type master;  
file "empty";  
};

empty:  
@ 10800 IN SOA . . (  
          1 3600 1200 604800 10800 )  
          @ 10800 IN NS .

Solution 2

  • Specifically on environments where IPA is setup and it doesn't provide flexibility to add zones manually as above
  • Bind can automatically create these empty zones by enabling empty-zones-enable yes; in named.conf.
  • Here is the upstream document
  • This option works with IPA and normal bind setup.

Root Cause

  • Misconfigured named/bind server, there are no empty zones created for internal networks. Under internal networks are considered ones described in RFC 1918

  • From bind9.net-FAQ:

Q:What does "RFC 1918 response from Internet for 0.0.0.10.IN-ADDR.ARPA" mean?

A: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.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments