Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 26 replies
  • Subscribers 2 subscribers
  • Views 13706 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Slow DNS queries with parallel requests and ipv6

sarabanjina
Hi,

We observe slow dns answers from Sophos dns proxy since the introduction of parallel requests in glibc 2.9. When I take a network trace on the firewall with tcpdump, I can see that Sophos answers only to the first request (ipv4). 5 seconds later, the client sends 2 other requests (sequentially) and Sophos answers to the 2 requests. Here is a trace when I launch "telnet www.sophos.com 80" on a client with a recent glibc : 
19:40:15.103081 IP 192.168.23.1.35888 > 192.168.23.254.53: 40569+ A? www.sophos.com. (32)
19:40:15.103131 IP 192.168.23.1.35888 > 192.168.23.254.53: 62436+ AAAA? www.sophos.com. (32)
19:40:15.104087 IP 192.168.23.254.53 > 192.168.23.1.35888: 40569 3/8/8 CNAME www.sophos.com.edgekey.net., CNAME e6203.b.akamaiedge.net., A 172.229.195.18 (393)
19:40:20.107695 IP 192.168.23.1.35888 > 192.168.23.254.53: 40569+ A? www.sophos.com. (32)
19:40:20.122838 IP 192.168.23.254.53 > 192.168.23.1.35888: 40569 3/8/8 CNAME www.sophos.com.edgekey.net., CNAME e6203.b.akamaiedge.net., A 2.21.3.18 (393)
19:40:20.126727 IP 192.168.23.1.35888 > 192.168.23.254.53: 62436+ AAAA? www.sophos.com. (32)
19:40:20.127196 IP 192.168.23.254.53 > 192.168.23.1.35888: 62436 2/1/0 CNAME www.sophos.com.edgekey.net., CNAME e6203.b.akamaiedge.net. (163)


I found a workaround by adding these line in /etc/resolv.conf on the client : 
options single-request
 or 
options single-request-reopen
.

But I would like to find a generic solution to apply on the firewall (I have the same problem on multiple firewalls with different customers).

I wonder why I'm the only one to speak about this problem (I didn't find any thread speaking about this problem).

Thanks,
Nicolas


This thread was automatically locked due to age.
Parents
  • 0
    Will keep you informed.

    I think at least the quick solution would be to disable connection tracking for UDP to port 53 of the UTM.
    I'm not into netfilter that much, but don't see that this will be a big (security) problem. I mean, it's UDP. It's stateless anyway.

    I'm installing a new internal DNS based on PowerDNS at the moment (which is amazing btw.) and found this one in their docs:
    A Recursor under high load puts a severe stress on any stateful (connection tracking) firewall, so much so that the firewall may fail.

    Specifically, many Linux distributions run with a connection tracking firewall configured. For high load operation (thousands of queries/second), It is advised to either turn off iptables completely, or use the 'NOTRACK' feature to make sure DNS traffic bypasses the connection tracking.
    Source: 4. PowerDNS Recursor performance
Reply
  • 0
    Will keep you informed.

    I think at least the quick solution would be to disable connection tracking for UDP to port 53 of the UTM.
    I'm not into netfilter that much, but don't see that this will be a big (security) problem. I mean, it's UDP. It's stateless anyway.

    I'm installing a new internal DNS based on PowerDNS at the moment (which is amazing btw.) and found this one in their docs:
    A Recursor under high load puts a severe stress on any stateful (connection tracking) firewall, so much so that the firewall may fail.

    Specifically, many Linux distributions run with a connection tracking firewall configured. For high load operation (thousands of queries/second), It is advised to either turn off iptables completely, or use the 'NOTRACK' feature to make sure DNS traffic bypasses the connection tracking.
    Source: 4. PowerDNS Recursor performance
Children
No Data
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?