0

My firewall identifies an unusual amount of traffic to 8.8.4.4 from host 192.168.76.22 (a Mac OS X Server). Within that server, the network connections are defined with a primary DNS pointing to my ISP's DNS server and the secondary address pointing to the Google Public DNS at 8.8.8.8. None of the settings in this system have been set to use 8.8.4.4.

Another post at Forensics - trace back DNS query origin on host? suggests that I might have to change the resolver in order to find the guilty processes.

I have checked a similar question for assistance, but found no useful answers there as to checking the source. I have run netstat and not identified any communication to 8.8.4.4 listed on the output.

I am wondering:

1) If there is a system log that would allow me to identify the necessary information

2) If there is an easier method than replacing the system's DNS resolver

3) How to replace the resolver (if this is absolutely necessary)

System Info:

OS: Mac OS X 10.10.5

Server Application Version: 5.0.3

Firewall: Watchguard XTM 505

  • Are you aware that 8.8.4.4 is a Google DNS server? – schroeder Sep 21 '15 at 20:54
  • 1
    I would run a packet capture to correlate the firewall logs with the traffic from the server. Remember that Google DNS uses anycast routing for their 2 IPs. – schroeder Sep 21 '15 at 21:02
  • 2
    I am not sure that Google running anycast would make a difference on the destination IP but definitely, the first step is to run packet capture. What may be happening is if you ISP provider is using 8.8.4.4 and is forwarding requests for your lookups. – Brett Littrell Sep 21 '15 at 21:35
  • If I run a packet capture, I confirm that the packet traffic that I have viewed at the firewall is the same at the host. I am pretty confident that this confirmation will be successful, but I will do it anyway. The firewall is logging traffic before it gets to external forwarding parties, and the internal traffic is being directed toward 8.8.4.4, so I'd like to rule out the ISP forwarding as the cause of the issue. The question then is, what do I gain from confirming the same information at the host that I have confirmed at the firewall? – Jared Clemence Sep 22 '15 at 21:48
  • 1
    I see now what I gain. By doing the packet capture on the local machine I was able to open the packet and view the contents, which my firewall does not permit me to do. Most of the traffic that was being sent to 8.8.4.4 was to resolve the domain name p12-ckdatabase.icloud.com.akadns.net or a similar domain (p12-ckdevice.icloud.com, p08-ckdatabase-current.edge.icloud.apple-dns.net, etc.). One was particularly strange to me, because it was searching for h.lax.rtcfront.ftw.jiveip.net. This is from our phone providers, and I imagine that the phones are querying the DNS record of this apple ... – Jared Clemence Sep 22 '15 at 22:07
1

@schroeder and @Brett Littrell provided the most useful suggestion. They suggested that I run a packet capture on the host machine.

  1. I ran the capture using WireShark and learned the names that were being queried.
  2. The names of the domains suggested that the packets were being forwarded from the DNS server running on the host.
  3. I repeated my inspection of the Network Settings both in the Network Settings panel and the Server settings for the DNS and found that I had made a mistake and overlooked the domain 8.8.4.4 in the permitted forwarding addresses.
  4. Removing the entry in the Server App stopped the unwanted traffic.

Knowing now that the traffic is from a legitimate program performing proper operations, I can safely change the firewall settings to allow more frequent traffic from the affected host to the DNS forwarding servers without worrying about the effect on the safety of the system.

0

Assuming the traffic indeed comes from 192.168.76.22 (a packet capture in the host is indeed an easy way to confirm), I would suspect that a program there is hardcoded to ask 8.8.4.4 for dns resolution. If it's not the system's DNS resolver (check!), I don't see ho changing the system DNS would change/fix the issue.

You would need to monitor the running programs when it is happening. The Network panel of the Activity Monitor could be a basic starting point.

  • This sounds tedious, but it is the only solution that sounds reasonable to me at this point. Thank you for the suggestion. – Jared Clemence Sep 22 '15 at 21:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.