I recently experienced some delays during DNS host resolution on OS X 10.8. To test it I started a simple script which tries to repeatedly resolve the same hostname 20 times:

for i in `seq 20`; do
    time -p dig www.google.com @ | grep "^;; Query time:"

Most request take about the same time as the latency to the name server:

;; Query time: 49 msec
real 0.05

However, as soon as I enable the firewall in Mountain Lion (all incoming requests are allowed, stealth mode is not enabled), some of the dig requests take exactly 5 seconds plus the latency to the name server:

;; Query time: 25 msec
real 5.03

Most requests are still fast, but around every 10th to 15th requests has a delay of exactly 5 seconds even through dig still reports a short query time. It makes no difference if I use dig or host for testing, or if I use a local DNS server or a public one like in the example above. When the firewall is turned off the delay never happens.

Does the firewall of OS X enforce some kind of rate limiting for requests, or is there anything else I'm missing?

  • I tested your script and have the exact same behavior. I also think the firewall is doing something here... but since the 5 second pauses look kind of random I have no idea what happens inside. I will investigate it a little more. – cyphorious Feb 1 '13 at 13:38
  • There's now a related Serverfault thread with the same problem (which also links back here): serverfault.com/questions/526668/… – skrause Aug 2 '13 at 23:01

You are right. I diagnose the same rate limiting at the firewall level on MacOS X 10.7.4 (Lion).

Moreover, if you look at

/usr/bin/sudo tcpdump -i en0 udp port 53

You will notice that the round trip time to get a reply from is much lower then the 40 msec displayed by the server.

On a long test run I had:

;; Query time: 44 msec

and an average roundtrip time of 26 msec:

09:36:14.360564 IP me.53866 > google-public-dns-a.google.com.domain: 9943+ A? www.google.com. (32)
09:36:14.386302 IP google-public-dns-a.google.com.domain > me.53866: 9943 5/0/0 A, A, A, A, A (112)

(386302 - 360564 = 26 msec)

To understand this protection mechanism (against basic DOS), look at:

/usr/bin/sudo pfctl -i en0 -s timeouts

The full documentation of this complex command is pfctl(8) Mountain Lion reference manual

Beware this is a powerfull but highly dangerous command. You may easily break your network access (Where is my backup?).

| improve this answer | |

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .