How many TXT data before DNS queries don’t fit in a UDP packet

domain-name-system

I have a DNS domain with 3 TXT records:

$ORIGIN example.com.
@   IN TXT "thing one veryveryveryveryveryverylong"
@   IN TXT "thing two veryveryveryveryveryverylong"
@   IN TXT "thing three veryveryveryveryveryverylong"

When I do a DNS query (dig example.com. txt) the reply fits in a UDP packet because the payload is less than 512 bytes (resulting in a packet less than 576 bytes).

However I know that if the reply is long enough, it will be truncated and the DNS client will have to repeat the request using TCP, which has longer length limits.

How can I calculate whether or not I have exceeded the length limit without generating the DNS records and doing a query?

I assume that the formula is something like:

N: the number of TXT records on that label.
P: the number of bytes in all the TXT records.
S: the total number of text segments (TXT records can have multiple text segments per record)

UDP is required if N*a + P*b + S*c is more than 512

What are the values of a, b, and c?

(or am I going in the wrong direction?)

Best Answer

In practice, you should not be trying to pre-calculate the exact response size of your TXT records prior to implementing them. There are many variables in play, some of which you do not control. Most admins generalize based off the size of an existing TXT record response that they observe from their authoritative server and call it a day. Since the focus of your question is how to avoid generalizing, this answer is going to focus on why it is difficult to use precise calculations.

(This answer should not be taken as a statement for or against trying to stay inside of 512 bytes, it is a commentary on the approach used to do so.)

sDNSHeader + sQuestion + sAnswer + sAuthority + sAdditional
  • The query itself shows up in the question section of the reply packet, and must be taken into consideration.
  • As you surmised, the number of answers and their byte length must also be taken into consideration.
  • If the authoritative server is configured to list the nameservers in the authority section and the corresponding address records in the additional section, those have to be factored in as well.
  • If the request contained an EDNS0 pseudo-section inside the additional section, a compliant server will reply with its own pseudo-section. The query probably requested a message size of greater than 512 bytes if EDNS0 is in play, but it's still a consideration, particularly since network hardware in the communication path may incorrectly reject DNS packets >512 bytes as invalid and force the effective message limit back down to the original constraints.
  • RFC 1035 message compression is also a factor.

Can you write a program or script that will do all of this calculation for you? Sure. Is it a good use of time for the problem you're trying to solve? Probably not. Use an existing TXT record within the zone as your rough sizing guideline, and if growing over 512 bytes is a concern make sure you are familiar with any "include" functionality built into the relevant standard leveraging the TXT records. (SPF, etc.)