No activity for long time and it may be a limitation coming from library
functions, as commented above.
When having new troubleshooting details, reopen.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kam
Closed #2651.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2651#event-4678242020___
Kamailio (SER) - Development Mailing List
sr-dev@l
@jklingenmeyer - have you had any time to dig in further? Is it libc/OS
limitation after all, or something inside Kamailio code?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/265
Thanks for your appreciated replies!
I do not think this is a firewall issue because when using `dig` command I get
no issues. Tried with two different sets of options:
* `dig +bufsize=512` : got `Truncated, retrying in TCP mode` then a correct
reply received through TCP
* or simple `dig` : in t
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 :-)
--
You are receiving this be
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.
--
You are receiving this because you are subscribed to this thread.
Reply
### 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
Rep
