Я не уверен, как ведут себя рекурсивные решения, когда его кеш содержит часть ответа. В частности, предположим, что сначала я выполнил этот поисковый запрос:
dig example.com @8.8.8.8
Насколько я понимаю, после процесса разрешения следующие записи будут кэшироваться на этом общедоступном преобразователе (8.8.8.8)
example.com. 17834 IN NS a.iana-servers.net.
example.com. 17834 IN NS b.iana-servers.net.
example.com. 18662 IN A 93.184.216.34
Во-вторых, предположим, что я выполнил еще один запрос на поиск, как показано ниже (до истечения срока жизни указанных выше записей):
dig sub.example.com @8.8.8.8
Теперь, поскольку записи NS, необходимые для разрешения домена вершины, уже находятся в кеше, использует ли рекурсивный преобразователь эту кэшированную информацию для прямого запроса одной из этих записей NS для записи A для (sub.example.com)? Если да, откуда он знает, как разбить запрос?
Я получил представление о том, как запуск распознавателя начинается с вершины иерархии, то есть с корня (.), Если у него нет ответа в кеше. Однако меня смутило то, что если в кеше есть частичные ответы (в этом примере это NS-запись для домена вершины), как преобразователь использует эти кешированные ответы?
Рекурсивный кэширующий сервер имен будет использовать всю информацию, которую он имеет локально, чтобы выполнять как можно меньше запросов, поэтому для "использует ли рекурсивный преобразователь эту кэшированную информацию для прямого запроса одной из этих NS-записей для записи A для (sub.example. com) "ответ положительный, если срок хранения содержимого в кеше, конечно, не истек.
Если да, откуда он знает, как разбить запрос?
Весь процесс документируется на §4.3.2 RFC 1034. См. Также §5.3.3.
Будет ли он разбивать запрос (sub.example.com) и идентифицировать домен вершины (example.com), а затем находить попадание в кеш для записи NS для (example.com)? Или он будет рекурсивно разрешать (sub.example.com), начиная с корня, и полностью игнорировать любой предыдущий кеш для (example.com)?
Согласно приведенному выше алгоритму, поиск начинается с корня для конкретного (имя, тип) желаемого. Обратите внимание, что тип учитывается. На любом этапе, если данная информация (имя, тип) уже находится в локальном кеше и срок ее действия не истек, она будет использоваться.
dig - полезный инструмент для устранения проблем с DNS, но если вы используете +trace вы можете увидеть, как работает типичный рекурсивный сервер имен (но без кеша), и увидеть каждый шаг и то, как разрешение начинается с корня. В противном случае вы можете установить любой рекурсивный сервер имен, например bind или unbound, сделайте подробный журнал, а затем прочитайте файлы журнала, чтобы понять, что происходит ...