Разъяснение того, почему файлы зоны DNS требуют записей NS

Насколько мне известно, №

'zpool copy' создает избыточные биты, как вы знаете, и, насколько я помню, предполагается, что он пытается отодвинуть эти избыточные биты как можно дальше географически насколько возможно, но я не считаю, что это жесткое и быстрое требование, как для зеркальных битов в зеркальном vdev; нехватка места, другие движущиеся части, как я могу подумать, могут привести к сценарию, когда копия №2 все еще находится на том же диске. Если это произойдет хотя бы один раз, то потеря диска из такой конфигурации будет проблемой с точки зрения сохранения данных.

И это не то, что административные команды пула должны обрабатывать так же, как они обрабатывают зеркальные vdev. Кроме того, рабочий процесс ZFS не предназначен для обработки так же, как зеркальные или четные vdevs - если вы потеряли диск из пула, в котором несколько дисков были vdev верхнего уровня, даже если у вас было copy = 2 или выше установленный прямо с первого дня, я ожидал, что ZFS будет сильно жаловаться и, возможно, начнет возвращать ошибки при доступе к данным.

Я не ожидал, что copy = 2 (или более) будет действовать как RAID 1E. Однако, если вы создали несколько разделов на своих дисках и настроили их в соответствующих зеркальных vdev, вы, вероятно, могли бы воспроизвести идею RAID 1E с ZFS. Если у вас было 3 диска, каждый с 2 ​​разделами, и вы настроили зеркальные vdevs таким образом, чтобы каждая пара разделов не принадлежала к одному диску, то полученный пул может пережить потерю одного диска. Однако эксплуатационные характеристики такого пула s данных и только кэш корневой зоны (который используется для начальной загрузки процесса разрешения имен), сначала он будет перемещен в . , затем com. . Серверы com ответят ответом раздела раздела , который в основном говорит: «Я не знаю, но ищите здесь кого-нибудь, кто знает», так же, как серверы для . делать о ком . Этот ответ на запрос не является авторитетным и не включает заполненный раздел ответов. Он может также включать так называемый дополнительный раздел , который дает сопоставления адресов для любых имен хостов, о которых знает конкретный сервер (либо из связанных записей, либо, в случае рекурсивных преобразователей, из ранее кэшированных данных). Резолвер примет этот ответ делегирования, при необходимости разрешите имя хоста записи NS и перейдите к запросу DNS-сервера, которому были делегированы полномочия. Этот процесс может повторяться несколько раз, если у вас есть глубокая иерархия делегирования, но в конечном итоге приводит к ответу на запрос с установленным флагом «авторитетный ответ» .

Важно отметить, что преобразователь (обычно , надеюсь) не будет пытаться разбить решаемое имя хоста, чтобы спросить об этом по частям, а просто отправит его целиком на «лучший» сервер, о котором он знает. Поскольку средний авторитетный сервер имен в Интернете не является авторитетным для подавляющего большинства действительных DNS-имен, ответом будет неавторизованный ответ делегирования, указывающий на какой-то другой DNS-сервер.

Теперь сервер не '' t должен быть назван в записях делегирования или полномочий где-либо, чтобы быть полномочным для зоны. Рассмотрим, например, частный главный сервер; в этом случае существует авторитетный DNS-сервер, о котором знают только администраторы подчиненных DNS-серверов зоны. DNS-сервер является авторитетным для зоны, если, по его мнению, с помощью какого-либо механизма он имеет полное и точное знание данной зоны. Обычно авторитетный DNS-сервер может, например, стать неавторизованным, если настроенный главный сервер (-ы) не может быть достигнут в течение срока, определенного как время истечения срока в записи SOA.

Только авторитетные ответы следует считать правильным запросом. ответы; все остальное либо делегирование, либо какая-то ошибка. Делегирование неавторизованному серверу называется " с обратными зонами DNS, особенно для больших динамических диапазонов IP-адресов) или когда список серверов имен различается между родительской зоной и рассматриваемой зоной (что, скорее всего, является ошибкой, но также может быть выполнено намеренно).

Вы можете видеть как это работает, более подробно с использованием dig и его функций + norec (не запрашивать рекурсию) и @ спецификатора сервера. Ниже приводится иллюстрация того, как работает реальный разрешающий DNS-сервер. Запросите запись A для unix.stackexchange.com , начиная, например, с a.root-servers.net :

$ dig unix.stackexchange.com. A @a.root-servers.net. +norec

Внимательно посмотрите на флаги ], а также количество разделов. qr - это ответ на запрос, а aa - авторитетный ответ. Обратите внимание, что вас делегируют только серверам com . Вручную выполните это делегирование (в реальной жизни рекурсивный преобразователь будет использовать IP-адрес из дополнительного раздела, если он предоставлен, или инициировать отдельное разрешение имен одного из именованных серверов имен, если в ответе на делегирование не указаны IP-адреса, но мы пропустите эту часть и просто вернитесь к обычному преобразователю операционной системы для краткости примера):

$ dig unix.stackexchange.com. A @a.gtld-servers.net. +norec

Теперь вы видите, что stackexchange.com делегирован (среди прочего) ns1.serverfault. com , и вы все еще не получаете авторитетного ответа. Снова следуем за делегацией:

$ dig unix.stackexchange.com. A @ns1.serverfault.com. +norec
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35713
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;unix.stackexchange.com. IN A

;; ANSWER SECTION:
unix.stackexchange.com. 300 IN A 198.252.206.16

Бинго! Мы получили ответ, потому что установлен флаг aa , и он содержит IP-адрес, который мы и надеялись найти. Кстати, это ' Стоит отметить, что, по крайней мере, на момент написания этой статьи списки серверов имен с делегированными и указанными полномочиями различаются, показывая, что эти два сервера не обязательно должны быть идентичными. То, что я привел в качестве примера выше, в основном является работой, выполняемой любым преобразователем, за исключением того, что любой практический преобразователь также будет кэшировать ответы на этом пути, поэтому ему не нужно каждый раз обращаться к корневым серверам.

Как вы можете видеть из приведенного выше примера. , записи делегирования и связки служат цели, отличной от записей полномочий и адресов в самой зоне.

Кэширующий, разрешающий сервер имен также обычно выполняет некоторые проверки работоспособности возвращаемых данных для защиты от заражения кешем. Например, он может отказать в кэшировании ответа с указанием авторитетных серверов для com из источника, отличного от того, который уже был назван родительской зоной как удаленный для com . Детали зависят от сервера, но цель состоит в том, чтобы кэшировать как можно больше, не открывая дверь сарая, позволяя любому серверу случайных имен в Интернете отменять записи делегирования для чего-либо, официально не находящегося под его «юрисдикцией».