New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DNS destination resolution failure when too many SRV records #2651
Comments
I haven't implemented the DNS code in Kamailio, but if you didn't find any define setting some limits in our C code and other external tools behave the same, then maybe the limit is from the libc dns resolving functions. |
Could it be a DNS over TCP issue? I remember testing with crazy size SRV record sets on SIPit and don't remember any issues. Just make sure your firewall supports DNS/TCP too. Things could have changed since then, so don't take for granted that it works today :-) |
Thanks for your appreciated replies! I do not think this is a firewall issue because when using
But of course it does not work when disallowing TCP retry mode and setting a 512 bytes buffer size Tests show clearly now a limit based on packet size (512 bytes) but I still do not know where it comes from precisely. |
@jklingenmeyer - have you had any time to dig in further? Is it libc/OS limitation after all, or something inside Kamailio code? |
No activity for long time and it may be a limitation coming from library functions, as commented above. When having new troubleshooting details, reopen. |
Description
DNS core resolver fails in returning a valid IP when there are too many SRV results in the DNS reply.
It acts like if no records were found, so request is not relayed and a 478 reply is generated instead (in the example of a DNS name in $ru or $du).
Troubleshooting
Reproduction
It is easy to reproduce with DNS failover + NAPTR enabled (cf parameters used far below)
and with such DNS records:
To reproduce, relay a request towards it, like:
$du="sip:ko.sip.provider.com"
Debugging data
One interesting thing is that Kamailio behaves exactly the same as the
sip-dig
tool.But
sip-dig
seems to be limited on the DNS reply size it can handle (cf my comment below about the RFC).Does Kamailio have this same kind of limitation regarding DNS resolution?
Log Messages
Failure example: with 9 SRV records
Comparison with a working example (only 3 SRV records)
Possible Solutions
I had a quick look inside the code and did not find any limitation about a maximum number of records.
There are some max defined in
dns_cache.c
but I did not found a relation between them and my issue.Could there be a limitation in result size? Here is what I got from my RFCs reading regarding that:
There is a RFC about how to deal with truncated messages:
Additional Information
Thanks
The text was updated successfully, but these errors were encountered: