7.18.1 DNS Bug

woodych · May 27, 2025, 2:27pm

Hi

I am chasing down an issue which causes the DNS resolver process of some SIP devices to crash. I narrowed it down to the crash happening when the DNS Service on a Mikrotik is queried and finally managed to trace a DNS query - and especially the reply which caused the resolver on this specific patton SIP gateway with latest firmware to crash.

I suspect the Microtik DNS does not return a correct reply.

Frame 139: 147 bytes on wire (1176 bits), 147 bytes captured (1176 bits)
Ethernet II, Src: PattonEl_0d:ae:f0 (00:a0:ba:0d:ae:f0), Dst: Routerbo_76:78:d0 (cc:2d:e0:76:78:d0)
Internet Protocol Version 4, Src: 172.29.255.10, Dst: 192.168.57.1
User Datagram Protocol, Src Port: 64306 (64306), Dst Port: domain (53)
Domain Name System (query)
    Transaction ID: 0xf163
    Flags: 0x0100 Standard query
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 0
    Queries
        _sip._udp.dev-cpereg.devtel.imp.ch: type SRV, class IN
    [Response In: 142]

Frame 142: 626 bytes on wire (5008 bits), 626 bytes captured (5008 bits)
Ethernet II, Src: Routerbo_76:78:d0 (cc:2d:e0:76:78:d0), Dst: PattonEl_0d:ae:f0 (00:a0:ba:0d:ae:f0)
Internet Protocol Version 4, Src: 192.168.57.1, Dst: 172.29.255.10
User Datagram Protocol, Src Port: domain (53), Dst Port: 64306 (64306)
Domain Name System (response)
    Transaction ID: 0xf163
    Flags: 0x8180 Standard query response, No error
    Questions: 1
    Answer RRs: 2
    Authority RRs: 13
    Additional RRs: 13
    Queries
        _sip._udp.dev-cpereg.devtel.imp.ch: type SRV, class IN
    Answers
        _sip._udp.dev-cpereg.devtel.imp.ch: type SRV, class IN, priority 0, weight 0, port 5060, target dev-sbc01.devtel.imp.ch
        _sip._udp.dev-cpereg.devtel.imp.ch: type SRV, class IN, priority 0, weight 0, port 5060, target dev-sbc02.devtel.imp.ch
    Authoritative nameservers
        <Root>: type NS, class IN, ns i.root-servers.net
        <Root>: type NS, class IN, ns k.root-servers.net
        <Root>: type NS, class IN, ns m.root-servers.net
        <Root>: type NS, class IN, ns f.root-servers.net
        <Root>: type NS, class IN, ns a.root-servers.net
        <Root>: type NS, class IN, ns g.root-servers.net
        <Root>: type NS, class IN, ns l.root-servers.net
        <Root>: type NS, class IN, ns b.root-servers.net
        <Root>: type NS, class IN, ns e.root-servers.net
        <Root>: type NS, class IN, ns d.root-servers.net
        <Root>: type NS, class IN, ns c.root-servers.net
        <Root>: type NS, class IN, ns h.root-servers.net
        <Root>: type NS, class IN, ns j.root-servers.net
    Additional records
        i.root-servers.net: type A, class IN, addr 192.36.148.17
        k.root-servers.net: type A, class IN, addr 193.0.14.129
        m.root-servers.net: type A, class IN, addr 202.12.27.33
        f.root-servers.net: type A, class IN, addr 192.5.5.241
        a.root-servers.net: type A, class IN, addr 198.41.0.4
        g.root-servers.net: type A, class IN, addr 192.112.36.4
        l.root-servers.net: type A, class IN, addr 199.7.83.42
        b.root-servers.net: type A, class IN, addr 170.247.170.2
        e.root-servers.net: type A, class IN, addr 192.203.230.10
        d.root-servers.net: type A, class IN, addr 199.7.91.13
        c.root-servers.net: type A, class IN, addr 192.33.4.12
        h.root-servers.net: type A, class IN, addr 198.97.190.53
        j.root-servers.net: type A, class IN, addr 192.58.128.30
    [Request In: 139]

Why the heck, is the Microtik DNS sending back all the authoritative DNS Servers as additional RR? There is no reason to do so, probably this is more then the allocated DNS reply memory of very simple resolver like in SIP phones can handle and cause them to crash.

When using BIND as a DNS server, I could not reproduce the issue.

-Benoît-

spippan · May 27, 2025, 2:32pm

what does the response look like when DNS server is a BIND DNS ?

woodych · May 27, 2025, 2:50pm

Query:

Frame 141: 147 bytes on wire (1176 bits), 147 bytes captured (1176 bits)
Ethernet II, Src: PattonEl_0d:ae:f0 (00:a0:ba:0d:ae:f0), Dst: Routerbo_76:78:d0 (cc:2d:e0:76:78:d0)
Internet Protocol Version 4, Src: 172.29.255.10, Dst: 157.161.57.1
User Datagram Protocol, Src Port: 64306 (64306), Dst Port: domain (53)
Domain Name System (query)
    Transaction ID: 0xf163
    Flags: 0x0100 Standard query
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 0
    Queries
        _sip._udp.dev-cpereg.devtel.imp.ch: type SRV, class IN
    [Response In: 143]

Response:

Frame 143: 293 bytes on wire (2344 bits), 293 bytes captured (2344 bits)
Ethernet II, Src: Routerbo_76:78:d0 (cc:2d:e0:76:78:d0), Dst: PattonEl_0d:ae:f0 (00:a0:ba:0d:ae:f0)
Internet Protocol Version 4, Src: 157.161.57.1, Dst: 172.29.255.10
User Datagram Protocol, Src Port: domain (53), Dst Port: 64306 (64306)
Domain Name System (response)
    Transaction ID: 0xf163
    Flags: 0x8180 Standard query response, No error
    Questions: 1
    Answer RRs: 2
    Authority RRs: 0
    Additional RRs: 3
    Queries
        _sip._udp.dev-cpereg.devtel.imp.ch: type SRV, class IN
    Answers
        _sip._udp.dev-cpereg.devtel.imp.ch: type SRV, class IN, priority 0, weight 0, port 5060, target dev-sbc01.devtel.imp.ch
        _sip._udp.dev-cpereg.devtel.imp.ch: type SRV, class IN, priority 0, weight 0, port 5060, target dev-sbc02.devtel.imp.ch
    Additional records
        dev-sbc01.devtel.imp.ch: type A, class IN, addr 157.161.23.249
        dev-sbc02.devtel.imp.ch: type A, class IN, addr 157.161.23.248
        dev-sbc02.devtel.imp.ch: type AAAA, class IN, addr 2001:4060:1:8e11::23:248
    [Request In: 141]

This makes sense, the next query the resolver would send is for the A/AAAA records of the SRV targets. So sending them as additional reponses makes the additional query obsolete.

woodych · May 27, 2025, 2:54pm

Oh, and something else:

DNS [RFC1035] maximal usable UDP size => 512 bytes.

The reply sent from the microtik DNS is larger than that.

Larger packets (EDNS0) are allowed but as I understand the client has to set some kind of flag (pseudo option) to indicate it supports EDNS0.

https://datatracker.ietf.org/doc/html/rfc2671

woodych · June 2, 2025, 8:37am

Hi

I can now confirm, this DNS bug (sending replies > 512 bytes to clients not supporting EDNS0) causes some resolver clients (Known: Patton SIP Gateway and Mitel/Aastra SIP Phones) to crash with a segmentation fault (probably because of writes past the allocated buffer).

Is anyone @Mikrotik looking into this issue? Can I open a case for this issue?

-Benoît-

jaclaz · June 2, 2025, 11:00am

Not until you open a ticket at support, while the Mikrotik guys do from time to time use the forum, cases like yours are request for bug fix/new feature (like a setting for - say - RFC1035-max-bytes=512|unlimited) and have to go through the official channel:
https://mikrotik.com/support

R1CH · June 3, 2025, 12:42am

I would open a support case with your SIP phone manufacturer too, if a single UDP packet can cause a buffer overflow then the devices are terribly insecure!

spippan · June 3, 2025, 9:56pm

same thought here.
but a good new checkpoint for “testing” networks, i added to my list

woodych · June 6, 2025, 2:39pm

Thanks for pointing me the right direction. Opened a case and replied I don’t want to open a case with the Distributor nor hire a paid consultant to have him fix the bug as I believe it’s Mikrotik’s dev team’s duty.

woodych · June 6, 2025, 2:41pm

That is already under way. Patton R&D team is on it and constantly asking me for more details how to reproduce sigh

Mitel PSIRT Team confirmed they had other reports pointing in the same direction and just sent me a ‘development’ firmware and asked me to reproduce and send them the debug output.