[dns-operations] Name servers returning incorrectly truncated UDP responses

[Viktor Dukhovni]

On Fri, Jul 29, 2022 at 05:04:28PM -0400, Puneet Sood via dns-operations wrote:

> $ dig m.email.sonyentertainmentnetwork.com. TXT @e.ns.email.sonyentertainmentnetwork.com
> ;; Warning: Message parser reports malformed message packet.
> ;; Truncated, retrying in TCP mode.

Indeed this response is truncated to just the question without adjusting
the answer count accordingly (tshark decode):

    Domain Name System (response)
        Transaction ID: 0x7189
        Flags: 0x8600 Standard query response, No error
            1... .... .... .... = Response: Message is a response
            .000 0... .... .... = Opcode: Standard query (0)
            .... .1.. .... .... = Authoritative: Server is an authority for domain
            .... ..1. .... .... = Truncated: Message is truncated
            .... ...0 .... .... = Recursion desired: Don't do query recursively
            .... .... 0... .... = Recursion available: Server can't do recursive queries
            .... .... .0.. .... = Z: reserved (0)
            .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
            .... .... ...0 .... = Non-authenticated data: Unacceptable
            .... .... .... 0000 = Reply code: No error (0)
        Questions: 1
        Answer RRs: 1
        Authority RRs: 0
        Additional RRs: 0
        Queries
            m.email.sonyentertainmentnetwork.com: type TXT, class IN
                Name: m.email.sonyentertainmentnetwork.com
                [Name Length: 36]
                [Label Count: 4]
                Type: TXT (Text strings) (16)
                Class: IN (0x0001)
    [Malformed Packet: DNS]
        [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
            [Malformed Packet (Exception occurred)]
            [Severity level: Error]
            [Group: Malformed]

    0020                                71 89 86 00 00 01             q.....
    0030  00 01 00 00 00 00 01 6d 05 65 6d 61 69 6c 18 73   .......m.email.s
    0040  6f 6e 79 65 6e 74 65 72 74 61 69 6e 6d 65 6e 74   onyentertainment
    0050  6e 65 74 77 6f 72 6b 03 63 6f 6d 00 00 10 00 01   network.com.....

Another interesting factor is that the nameserver responded to an EDNS0
query without either returning FORMERR or returning an OPT pseudo-RR.

EDNS0 is also ignored over TCP, only this time the response is not
truncated:

    $ dig +nocmd +vc +norecur m.email.sonyentertainmentnetwork.com. TXT @e.ns.email.sonyentertainmentnetwork.com
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12793
    ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;m.email.sonyentertainmentnetwork.com. IN TXT

    ;; ANSWER SECTION:
    m.email.sonyentertainmentnetwork.com. 3600 IN TXT "v=spf1 a mx ... ~all"

    ;; Query time: 7 msec
    ;; SERVER: 207.251.96.133#53(207.251.96.133)
    ;; WHEN: Fri Jul 29 17:35:05 EDT 2022
    ;; MSG SIZE  rcvd: 542

That said, an earlier case observed internally today trucated to 512
bytes in the middle of an RR, but did adjust the counts, so that
response had extra bytes at the end of the packet, while this one is
missing a promised RR.

So perhaps there's more than one problem implementation, though both
simply ignore EDNS and respond sans FORMERR or OPT.

It is looking like truncation is implemented poorly more often than one
might like...

-- 
    Viktor.