Kamailio logs errors due to unsupported EDNS0 extension in DNS responses

[ffloimair]

Description

We are running Kamailio in a Microsoft Azure VM. Azure started adding EDNS0 support - in the form of OPT pseudo-records at the end of replies - a few weeks ago and since then we see a lot of ERROR entries in Kamailio log. These do however have no function impact.
From what I can see they are simply not handled in core/resolv.c (EDNS0 is type 41).
Version in use is latest 5.2 package from Kamailio repo on Debian 9 (Stretch).

Log entries provided below

Troubleshooting

None, as this has no functional impact aside from filling the logs.

Reproduction

I can provide pcap of DNS traffic that contains EDNS0 OPT pseudo-entries on request.

Debugging Data

(paste your debugging data here)

Log Messages

Oct  1 14:02:01 kamailio /usr/sbin/kamailio[78878]: ERROR: <core> [core/resolve.c:941]: get_record(): unknown type 41

These lines are seen repeatedly only differing in timestamp and PID of kamailio process. In total about 40% of log entries are like the one above.

SIP Traffic

not related to SIP, but to DNS

Possible Solutions

Add EDNS0 type 41 in core/resolv.c and don't fire an ERROR in the logs.

Additional Information

• Kamailio Version - output of kamailio -v

version: kamailio 5.2.4 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144 MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 6.3.0

• Operating System:

Debian 9.11
Linux kamailio 4.19.0-0.bpo.5-cloud-amd64 #1 SMP Debian 4.19.37-3~bpo9+1 (2019-05-18) x86_64 GNU/Linux

[henningw]

Thank you for the report. Could you try with the patch aeea940 on a azure VM? Should be also work for 5.2. If it fix the problem for you it could be backported.

Can you also check in the wireshark that the Azure DNS does not include something meaningful into the OPT record data?

[ffloimair]

Wow that was quick!
Thank you Henning!

Unfortunately your commit does not build and fails with

core/resolve.c: In function ‘get_record’:
core/resolve.c:940:9: error: ‘T_OPT’ undeclared (first use in this function)
    case T_OPT:
         ^~~~~
core/resolve.c:940:9: note: each undeclared identifier is reported only once for each function it appears in

I guess you need to use the lower level ns_t_opt instead of T_OPT

[ffloimair]

Additional info: I used the 5.2.4 tag + a cherry-pick of your commit for this build.

[henningw]

Ah, older glibc (< 2.25) did not contained the T_OPT type yet. I've added a small compatility define, please try again with commit 325d1e6

[ffloimair]

OK, this compiled. I will test thoroughly today and let you know the result ASAP.

[ffloimair]

Hi, Henning!
After running this for a few hours, I can confirm that the issue is fixed.
Therefore I will close this issue.
Thank you for your fast solution.

[henningw]

Ok, thanks for the confirmation. I will also backport it to stable branches.