Discussion:
[Dnsmasq-discuss] Reponse time is huge for big payload SRV record on dnsmasq servers
Harish Shetty
2018-05-07 12:57:55 UTC
Permalink
Hi All

I am facing some issue with dnsmasq. Currently I am using dnsmasq-2.48 ,
I am using this as my forwarder and caching sever. But my problem is, when
i query for a high payload SRV record (answer size is about 3500 bytes)
response time some times crosses 4000ms, and intermittently timeout.

I have tried enabling the logquries, but it didnt give much information to
me, Any suggestion on the debugging or more details will be helpful

Regards
Harish Shetty
Simon Kelley
2018-05-07 13:33:26 UTC
Permalink
That's large enough to need TCP.

What I'd expect top happen is that the upstream server returns an answer
with the truncated bit setin the header. This answer gets returned by
dnsmasq to the original requestor. The original requestor makes a TCP
connection to dnsmasq and re-sends the query. Dnsmasq makes a TCP
connection upstream and send the query, and gets the result. It then
send the result back down the TCP connection to the original requestor.

Anything blocking or distrupting TCP connections on port 53 is suspect.
An non-responsive upstream server will cause delays whilst the
connection times out.

Try running the query direct to the upstream servers using dig +vc

Cheers,

Simon.
Post by Harish Shetty
Hi All
I  am facing some issue with dnsmasq. Currently I am using dnsmasq-2.48
,  I am using this as my forwarder and caching sever. But my problem is,
when i query for a high payload SRV record  (answer size is about 3500
bytes) response time some times crosses 4000ms, and intermittently timeout.
I have tried enabling the logquries, but it didnt give much information
to me,  Any suggestion on the debugging or more details will be helpful
Regards
Harish Shetty
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Harish Shetty
2018-05-07 14:30:25 UTC
Permalink
Hi Simon

Thanks for the reply, Yes you are rite, Truncated bit is set in the
message. I am seeing ";; Truncated, retrying in TCP mode." in the answer.
But it is expected and answer is more than 512 bytes (which is size of UDB
packet). TCP port 53 is allowed , but DNS respone time from dnsmasq service
is more than 3 sec sometime 4 or 5 sec. When we query directly upstream
server we are seeing the response on avg of 100 to 200 ms.

Is there anyway we can make DNS query faster in dnsmasq server, because it
is making our application timeouts.

Regards
Harish Shetty
Post by Simon Kelley
That's large enough to need TCP.
What I'd expect top happen is that the upstream server returns an answer
with the truncated bit setin the header. This answer gets returned by
dnsmasq to the original requestor. The original requestor makes a TCP
connection to dnsmasq and re-sends the query. Dnsmasq makes a TCP
connection upstream and send the query, and gets the result. It then
send the result back down the TCP connection to the original requestor.
Anything blocking or distrupting TCP connections on port 53 is suspect.
An non-responsive upstream server will cause delays whilst the
connection times out.
Try running the query direct to the upstream servers using dig +vc
Cheers,
Simon.
Post by Harish Shetty
Hi All
I am facing some issue with dnsmasq. Currently I am using dnsmasq-2.48
, I am using this as my forwarder and caching sever. But my problem is,
when i query for a high payload SRV record (answer size is about 3500
bytes) response time some times crosses 4000ms, and intermittently
timeout.
Post by Harish Shetty
I have tried enabling the logquries, but it didnt give much information
to me, Any suggestion on the debugging or more details will be helpful
Regards
Harish Shetty
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Loading...