Solved: DNS Issue: How to deal with RFC 1918 response from Internet for X.X.XX.XXX.in-addr.arpa warning messages ?
Today we will look at an interesting warning messages on our DNS server and found the requests are coming from some random source say, XXX.XX.X.XX.
1. Issue Details
named-security.log:11-Apr-2020 07:41:26.657 security: warning: client XXX.XX.X.X 9#10944: RFC 1918 response from Internet for 4.4.29.172.in-addr.arpa named-security.log:11-Apr-2020 07:43:16.935 security: warning: client XXX.XX.X.X 9#10165: RFC 1918 response from Internet for 4.4.29.172.in-addr.arpa named-security.log:11-Apr-2020 07:43:17.934 security: warning: client XXX.XX.X.X 9#10165: RFC 1918 response from Internet for 4.4.29.172.in-addr.arpa
2. Root Cause of this issue
Misconfigured named/bind server, there are no empty zones created for internal networks. Under internal networks are considered ones described in RFC 1918
3. Resolution
To resolve this issue, it is necessary to create empty zones for every set of private IP addresses used. We need to advise DNS Team to create the empty zone with this internal IP address XXX.XX.X.X9 to resolve this issue.
4. Further Information about this issue:
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.
The above partial data is taken from redhat knowledge base and is copyright with Redhat, view the complete article at: https://access.redhat.com/solutions/46558