DNS TXT record size

[hani-n]

I am currently running into an issue where dns browse command from a Thread End device (nrf52840) will only print instance name as shown below

> srp client autostart enable
Done
> dns browse _service._udp.default.service.arpa
DNS browse response for _service._udp.default.service.arpa.
mmb_instance

This is due to the desired service having a TXT record size of 414 bytes (DNS allows for up to 65535 bytes split into 0-255 strings), while in src/cli/cli.cpp we only allocate a 255 byte buffer for the entire record

void Interpreter::HandleDnsBrowseResponse(otError aError, const otDnsBrowseResponse *aResponse)
{
    char             name[OT_DNS_MAX_NAME_SIZE];
    char             label[OT_DNS_MAX_LABEL_SIZE];
    uint8_t          txtBuffer[255];

In this case, otDnsBrowseResponseGetServiceInfo will return error since it calls a

VerifyOrExit(GetLength() <= aTxtBufferSize, error = kErrorNoBufs);

(where GetLength() is the TXT record size, and aTxtBufferSize is the size of the 255 byte buffer we allocate) and OutputDnsServiceInfo will not be reached.

Understanding that we are operating in a constrained environment and cannot provide a 65535 byte buffer to cover all possible DNS services, would it make sense to increase that size to 512 to cover more devices ? or at least still print the host name / address and only omit TXT records ?

[jwhui]

Thanks for raising this discussion. I agree that the current behavior is not ideal. I see a couple of enhancements we can make:

1. Add a build config that allows for specifying the buffer size.
2. Print as much as possible, but when the buffer size is insufficient, indicate that the output was truncated and maybe provide the total length of the output.

Thoughts?

[hani-n]

I am more inclined towards option 1 as it would provide more flexibility for users who have enough resources, and know what size records to expect

[jwhui]

The options are not mutually exclusive. We can implement both we think that's valuable.

[hani-n]

I think implementing both would be great, providing the user with all relevant info (truncated message, data remaining ...) as well as the config option to manage it.

[abtink]

• Submitted PR [dns] allow partial read of TXT data and add config for max size in CLI #8232
• It should take care of both.

[jwhui]

• This PR has been merged: [dns] allow partial read of TXT data and add config for max size in CLI #8232