How is truncation performed in DNS according to RFC 1035?

Question

I'm trying to implement my own DNS server from scratch. However, I'm having difficulty understanding how RFC 1035 recommends truncation to be performed.

Section 6.2 says:

When a response is so long that truncation is required, the truncation should start at the end of the response and work forward in the datagram. Thus if there is any data for the authority section, the answer section is guaranteed to be unique.

I can't really understand what this means. I assume "forward" means away from the header. But what does that have to do with the authority section? And it says "end of the response" which I assume means end of answer section? What if the whole answer section doesn't fit in the message?

Could somebody explain this algorithm better?

I also found Section 9 of RFC 2181 which says:

The TC bit should be set in responses only when an RRSet is required as a part of the response, but could not be included in its entirety. The TC bit should not be set merely because some extra information could have been included, but there was insufficient room. This includes the results of additional section processing. In such cases the entire RRSet that will not fit in the response should be omitted, and the reply sent as is, with the TC bit clear. If the recipient of the reply needs the omitted data, it can construct a query for that data and send that separately.

Where TC is set, the partial RRSet that would not completely fit may be left in the response. When a DNS client receives a reply with TC set, it should ignore that response, and query again, using a mechanism, such as a TCP connection, that will permit larger replies.

Answer 1

TL;DR

If TC is set, the choice of records in the answer (if any) do not really matter much as the client is supposed to just discard the message and retry over TCP, anyway.

---

First of all, I will just note that if this implementation is for learning purposes, then that is of course an excellent way of getting a deep understanding. I would recommend Hello DNS as supplementary reading.
If it's for production use, I would strongly recommend considering using some existing DNS implementation as the framework of your solution to help provide correct behavior; there is a lot to it when you start looking into the expectations of a modern DNS server.

Regarding your question about the very brief note of truncation in RFC1035 (do note the age of this document, it doesn't really hold up in terms of clear language), I also find their explanation of TC rather oddly phrased.

However, I do believe what is alluded to there is essentially that the order of the sections in a DNS message aligns with the "importance" of the data.

The regular query/response messages have these sections (from section 4.1):

+---------------------+
|        Header       |
+---------------------+
|       Question      | the question for the name server
+---------------------+
|        Answer       | RRs answering the question
+---------------------+
|      Authority      | RRs pointing toward an authority
+---------------------+
|      Additional     | RRs holding additional information
+---------------------+

I believe what they are saying is essentially just that you should start dropping stuff starting from the end (prefer to drop stuff from additional, then authority, ...). This approach then leads up to them noting what I believe is supposed to say that if there is anything in eg the authority section you know that the answer section is intact.

All that said, I really think the relevant section in RFC2181 is much more helpful (and more clear, which is very much the purpose of RFC2181).

As is noted there (paraphrasing):
If there is any optional data (data other than what is strictly required to minimally answer the question, ie generally the full RRSet that matches the question) that you were considering adding to response, then that optional data can simply be dropped without having to set TC.
If you have to remove something that is essential to the answer TC must be set, and if TC was set the client must discard the response and retry over TCP (which largely makes the somewhat convoluted reasoning in RFC1035 irrelevant for well-behaved clients, they will not use the truncated answer for anything).