根據 RFC 1035 如何在 DNS 中執行截斷？
我正在嘗試從頭開始實現我自己的 DNS 伺服器。但是，我很難理解RFC 1035如何建議執行截斷。
第 6.2 節說：
當響應太長以至於需要截斷時，截斷應該從響應的末尾開始，並在數據報中向前推進。因此，如果權威部分有任何數據，則保證答案部分是唯一的。
我真的無法理解這意味著什麼。我認為“前進”意味著遠離標題。但這與權限部分有什麼關係？它說“響應結束”，我認為這意味著答案部分的結束？如果整個答案部分不適合消息怎麼辦？
有人可以更好地解釋這個算法嗎？
僅當需要 RRSet 作為響應的一部分但不能全部包含在內時，才應在響應中設置 TC 位。不應僅僅因為可能包含一些額外資訊而設置 TC 位，但沒有足夠的空間。這包括附加部分處理的結果。在這種情況下，不適合響應的整個 RRSet 應該被忽略，並且按原樣發送響應，同時清除 TC 位。如果回复的接收者需要省略的數據，它可以為該數據構造一個查詢並單獨發送。
在設置了 TC 的情況下，不完全適合的部分 RRSet 可能會留在響應中。當 DNS 客戶端收到帶有 TC 設置的回复時，它應該忽略該響應，並使用允許更大回复的機制（例如 TCP 連接）再次查詢。
TL;博士
如果
TC設置了，則答案中的記錄選擇（如果有）並不重要，因為客戶端應該只是丟棄消息並通過 TCP 重試，無論如何。首先，我只想指出，如果這個實現是為了學習目的，那麼這當然是一種深入理解的好方法。我會推薦Hello DNS作為補充閱讀。
如果它用於生產用途，我強烈建議考慮使用一些現有的 DNS 實現作為解決方案的框架，以幫助提供正確的行為；當您開始研究現代 DNS 伺服器的期望時，會有很多事情要做。
關於您關於 RFC1035 中非常簡短的截斷註釋的問題（請注意本文件的年齡，它在清晰的語言方面並沒有真正成立），我還發現他們對 TC 的解釋相當奇怪。
但是，我確實相信這裡提到的本質上是 DNS 消息中各部分的順序與數據的“重要性”一致。
正常查詢/響應消息具有以下部分（來自第 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 +---------------------+我相信他們所說的本質上只是你應該從頭開始丟棄東西（更喜歡從額外的東西，然後是權威……）。然後，這種方法使他們注意到我認為應該說的是，如果在例如權威部分中有任何內容，您就知道答案部分是完整的。
綜上所述，我真的認為 RFC2181 中的相關部分更有幫助（而且更清晰，這正是 RFC2181 的目的）。
如那裡所述（釋義）：
如果有任何您正在考慮添加到響應中的可選數據（除了最低限度回答問題所嚴格要求的數據，即通常與問題匹配的完整 RRSet），那麼該可選數據可以簡單地刪除而無需設置
TC.如果您必須刪除對
TC必須設置的答案至關重要的內容，並且如果TC設置了客戶端必須丟棄響應並通過 TCP 重試（這在很大程度上使得 RFC1035 中有些複雜的推理與行為良好的客戶端無關，他們不會對任何事情都使用截斷的答案）。