Я пытаюсь реализовать собственный DNS-сервер с нуля. Однако мне сложно понять, как RFC 1035 рекомендует выполнить усечение.
Раздел 6.2 говорит:
Когда ответ настолько длинный, что требуется усечение, усечение должно начинаться в конце ответа и продвигаться вперед в дейтаграмме. Таким образом, если есть какие-либо данные для раздела полномочий, раздел ответов гарантированно будет уникальным.
Я не понимаю, что это значит. Я предполагаю, что «вперед» означает от заголовка. Но при чем здесь авторитетный раздел? И там написано «конец ответа», что, как я полагаю, означает конец раздела ответа? Что делать, если весь раздел ответа не помещается в сообщении?
Может ли кто-нибудь лучше объяснить этот алгоритм?
Я также нашел Раздел 9 из RFC 2181 который говорит:
Бит TC должен быть установлен в ответах только тогда, когда RRSet требуется как часть ответа, но не может быть включен полностью. Бит TC не следует устанавливать только потому, что могла быть включена некоторая дополнительная информация, но места было недостаточно. Сюда входят результаты дополнительной обработки сечения. В таких случаях следует опустить весь набор RRSet, который не подходит для ответа, и отправить ответ как есть, с очищенным битом TC. Если получателю ответа нужны пропущенные данные, он может составить запрос для этих данных и отправить его отдельно.
Если установлен TC, в ответе можно оставить частичный RRSet, который не подходит полностью. Когда DNS-клиент получает ответ с установленным TC, он должен проигнорировать этот ответ и запросить еще раз, используя механизм, такой как TCP-соединение, которое разрешит более крупные ответы.
Если TC установлен, выбор записей в ответе (если они есть) на самом деле не имеет большого значения, так как клиент в любом случае должен просто отбросить сообщение и повторить попытку по TCP.
Прежде всего, я просто замечу, что если эта реализация предназначена для учебных целей, то это, конечно, отличный способ получить глубокое понимание. я бы порекомендовал Привет, 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 неактуальными для клиентов с хорошим поведением, они не будут использовать усеченный ответ ни для чего).