Assistance with DNS - RFC 1918 response from internet

Question

Level 1

0 points

Assistance with DNS - RFC 1918 response from internet

Hello - I recently noticed some errors in my DNS log. I looked into the errors and it seems that I do not have any empty zones setup. Everything is right in SA, however it does not seem to be correct in the actual config. files. The following is a sample of my log. Does anyone have an idea what's going on/what i need to do to resolve this issue. Any help is greatly appreciated.

15-Mar-2010 09:19:49.130 client 192.168.89.254#3054: view com.apple.ServerAdmin.DNS.public: RFC 1918 response from Internet for 10.141.168.192.in-addr.arpa
15-Mar-2010 09:19:49.183 client 192.168.42.143#64936: view com.apple.ServerAdmin.DNS.public: RFC 1918 response from Internet for 143.42.168.192.in-addr.arpa
15-Mar-2010 09:19:50.779 client 192.168.90.164#53186: view com.apple.ServerAdmin.DNS.public: RFC 1918 response from Internet for 115.42.168.192.in-addr.arpa
15-Mar-2010 09:19:56.864 client 192.168.89.254#3072: view com.apple.ServerAdmin.DNS.public: RFC 1918 response from Internet for 32.44.168.192.in-addr.arpa
15-Mar-2010 09:19:57.968 client 192.168.89.254#3075: view com.apple.ServerAdmin.DNS.public: RFC 1918 response from Internet for 62.144.168.192.in-addr.arpa
15-Mar-2010 09:19:58.085 client 192.168.90.164#61319: view com.apple.ServerAdmin.DNS.public: RFC 1918 response from Internet for 138.42.168.192.in-addr.arpa
15-Mar-2010 09:19:58.306 client 192.168.89.254#3081: view com.apple.ServerAdmin.DNS.public: RFC 1918 response from Internet for 2.50.168.192.in-addr.arpa
15-Mar-2010 09:20:03.593 client 192.168.89.254#3090: view com.apple.ServerAdmin.DNS.public: RFC 1918 response from Internet for 1.109.168.192.in-addr.arpa
15-Mar-2010 09:20:06.830 client 192.168.89.254#3093: view com.apple.ServerAdmin.DNS.public: RFC 1918 response from Internet for 100.1.254.10.in-addr.arpa
15-Mar-2010 09:20:10.162 client 192.168.42.116#61482: view com.apple.ServerAdmin.DNS.public: RFC 1918 response from Internet for 116.42.168.192.in-addr.arpa
15-Mar-2010 09:20:12.379 client 192.168.42.116#52028: view com.apple.ServerAdmin.DNS.public: RFC 1918 response from Internet for 116.42.168.192.in-addr.arpa

MacBook, Mac OS X (10.6.2)

Posted on Mar 15, 2010 7:27 AM

Reply

Answer 1

Camelot

Level 9

58,563 points

Mar 15, 2010 8:26 AM in response to MITTech

The message is fairly simple to understand, the fix may or may not be depending on your network.

15-Mar-2010 09:19:49.130 client 192.168.89.254#3054: view com.apple.ServerAdmin.DNS.public: RFC 1918 response from Internet for 10.141.168.192.in-addr.arpa

Translated, this means that the client at 192.168.89.254 performed a name lookup on 192.168.141.10 but this server doesn't know anything about 192.168.141.10 so tried to resolve the address, but failed because 192.168.x.x, by definition, is a private subnet.

The only real issue is why the client tried to resolve that address. Is 192.168.141.x a subnet that you use in your network? What about 10.254.1.x (the other address requested by another client)?

If those are your subnets then your reverse DNS is not set correctly. Since Server Admin tries to manage reverse DNS automatically, I doubt that's the case, which leaves a client-side issue.
In each case the client is trying to reverse lookup a private IP address. If those subnets are the ones the respective users use in their home networks then it could be as simple as that - the machine is trying to lookup a device (printer, maybe?) that is on the home network.

Reply

Answer 2

MITTech Author

Level 1

0 points

Mar 15, 2010 9:19 AM in response to Camelot

Thanks for your response. I am new to troubleshooting DNS. I will try to provide more information on our config. 192.168.89.254 is our firewall/web filtering device. We have RADIUS setup on our server to allow transfer of LDAP info. All of the 192.168.x.x are our private addresses. I am not sure where the 10.x.x.x address came from. We do have secondary DNS Server w/ Secondary Zones setup. On the Main DNS Server allow zone transfer is checked for Primary & Reverse zones. DNS is giving a green light, but i am still not convinced. This may help - when i go to term and run cat /etc/hosts i get

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0 localhost

Shouldn't I see an entry for my DNS server here, like 192.x.x.x x.x.org?

Thanks again for your assistance.

Reply

Answer 3

Camelot

Level 9

58,563 points

Mar 15, 2010 10:56 AM in response to MITTech

All of the 192.168.x.x are our private addresses.

You are using all of 192.168.x.x… 192.168.0.x 192.168.1.x, 192.168.2.x, 192.168.3.x, etc.? That's 65 thousand IP addresses. Most people only use a small subset such as 192.168.1.x, or 192.168.10.x, not the entire 192.168.x.x range.

I am not sure where the 10.x.x.x address came from

I think you're missing the point.

The point is not that these addresses exist in your network, nor that they exist in your DNS. The sole point is that some client on your network tried to resolve that address.

The question is whether these addresses should be on your network or not. If they should be and you are using all those addresses, then your DNS isn't configured correctly. If they should not, then it's nothing to worry about - the client is looking up an address that is not valid.

when i go to term and run cat /etc/hosts i get

/etc/hosts is irrelevant. It isn't used for 99% of what you're talking about here. The only thing that's relevant from a client standpoint is the DNS server(s) that it's using, which would be recorded in /etc/resolv.conf

Reply

Answer 4

MITTech Author

Level 1

0 points

Mar 16, 2010 5:12 AM in response to Camelot

Okay, I see your point. The addresses in the log are from computers in our network. We use several subnets in 192.168.x.x - I was trying to say that the IP's listed in the log are from our network. If I am reading the log right, our clients are querying a root server when they should be querying the local DNS. Maybe my assumption is incorrect. I have no idea where to troubleshoot, or what would cause this. I believe it is a setting in DNS that is incorrect, or was written by the OS incorrectly - I just don't know where to start.

Reply

Answer 5

Camelot

Level 9

58,563 points

Mar 16, 2010 11:14 AM in response to MITTech

No, you're still not (quite) getting it.

The addresses in the log are from computers in our network

You mean the client address, right? not the address of the host that was being looked up.

. If I am reading the log right, our clients are querying a root server when they should be querying the local DNS

No, that's not what it's saying.

Given the log line:

15-Mar-2010 09:19:49.130 client 192.168.89.254#3054: view com.apple.ServerAdmin.DNS.public: RFC 1918 response from Internet for 10.141.168.192.in-addr.arpa

This means that the client (on your network) at 192.168.89.254 asked your server for the reverse DNS lookup for 192.168.141.10.
Since your server doesn't know anything about 192.168.141.10 it queried the root server and got back an RFC1918 response (because no public server should ever respond to a query for a 192.168.x.x address).

The point is that your server queried the root server, not the client on the network. This is exactly the same as if the client requested a name lookup for a domain that the server didn't know about - it would query the root servers to find out where to get the answer. At no point, though, does the client query the root server and, indeed, since you're seeing this log entry it means the client is correctly configured.

I have no idea where to troubleshoot,

What's to troubleshoot? As long as you don't expect to be authoritative for 192.168.141.x there's no issue here (other than maybe why the client requested that address in the first place). In short, this kind of thing happens all the time and I wouldn't think twice about it as long as 192.168.141.x is not one of your networks. If it is then clearly your machine isn't setup to handle that zone which might be something to address. You haven't yet stated whether you expect to resolve 192.168.141.x addresses or not.

Reply