Я ни разу не нашел упоминания об этом в примерах настроек, в том числе в Bind ARM.
Тем не менее, я заметил, что мой авторитетный сервер получает запросы на передачу от IP-адресов, а не от их имен, которые на самом деле были частью набора некоторых корневых серверов - корня DNS.
Я собирался разрешить такие передачи в своей конфигурации и подумал о двойной проверке.
Если я прав, корень будет отвечать только за gTLD, а затем TLD только за свои соответствующие домены следующего уровня - делегирование. Но, если я понимаю иерархическую структуру DNS, каждый сервер должен предоставить всю имеющуюся у него информацию, а не предоставлять строгий минимум и направлять клиента в итеративный процесс. Так почему бы и нет, корневой сервер мог бы пожелать иметь возможность отвечать о моих зонах… что облегчило бы работу моих собственных серверов.
Итак, во-первых, почему корневой сервер (кажется) запрашивает мои зоны?
Неужели это нападение?
Или, если это нормально, остается риск того, что такой сервер - корневой или TLD - разрешит передачу для зон, которые он обрабатывает, хотя это может не быть нашей политикой - не доверяйте большой рыбке, чтобы всегда идеально управлять своими настройками.
Я предполагаю, что мы могли бы почувствовать себя по-разному в зависимости от того, аутентифицировали ли мы зоны с помощью DNSSEC, поскольку доверие корню для подписей DNSSEC не просто эквивалентно доверию корню для всего содержимого зоны.
И, кстати, если мы разрешаем переводы, мы также должны отправлять им уведомления об изменениях.
* Мне кажется, в этом вопросе также должны быть теги *
AXFR, зональный перенос и корневые серверы
РЕДАКТИРОВАТЬ (вот подсказка):
Я собирался из строк журнала, например
20-Jan-2016 20:33:30.581 security: error: client 192.134.4.83#51264: zone transfer 'MyZone.info/AXFR/IN' denied
так
dig +noall +answer +authority -x 192.134.4.83 @a.in-addr-servers.arpa.
192.in-addr.arpa. 86400 IN NS y.arin.net.
[...]
dig +noall +answer +authority -x 192.134.4.83 @y.arin.net.
134.192.in-addr.arpa. 172800 IN NS ns3.nic.fr.
[...]
dig +noall +answer -x 192.134.4.83 @ns3.nic.fr.
83.4.134.192.in-addr.arpa. 172800 IN PTR zonemaster.rd.nic.fr.
dig +noall +authority SOA zonemaster.rd.nic.fr. @ns3.nic.fr.
rd.nic.fr. 3600 IN SOA ns2.rd.nic.fr. hostmaster.nic.fr. 2015111706 21600 3600 3600000 3600
И хорошо…
В те дни я играл с онлайн-проверками DNS, в том числе с французскими TLD zonemaster.fr. Кстати, довольно подробный.
Таким образом, запрос AXFR был лишь частью запущенных тестов. :-)
Моя ошибка.
Спасибо за ответы.
А на самом деле...
Возможно может случиться так, что по крайней мере один корневой сервер имен (скажем, ради аргумента, что он будет называться L) на самом деле представляет собой набор из сотен серверов, распределенных по всему миру. И может случиться так, что какая-то организация заинтересована в тестировании настроек зон DNS, и эта организация может иметь доступ к этому набору машин. Тогда было бы довольно удобно использовать эти машины для запуска тестов, поскольку это дало бы информацию о том, как все работает, из разных мест. Кроме того, одним из тестов может быть отправка AXFR запрос не для фактического получения информации, а для того, чтобы узнать, будет ли это разрешено или запрещено.
По крайней мере, я мог слышать.
По большей части, хотя я бы согласился с мнением о том, что нельзя доверять большой рыбе всегда управлять своими настройками. Поскольку на самом деле нет (прямой) прибыли от запуска DNS (давайте проигнорируем OpenDNS / Google и т. Д.). Я всегда считал, что серверы корневого домена, скорее всего, управляются очень-очень компьютерными парнями, которые хорошо разбираются в том, что они делают. Просто потому, что плохое управление этими серверами будет иметь катастрофические последствия для Интернета в целом. Я думаю, что в целом вы можете доверять основам сети, потому что управление находится подальше от них!
Сказав это, нет никаких причин, по которым сервер корневой зоны будет запрашивать AXFR у полномочного сервера домена. Эти очень загруженные машины (кластеры) представляют дополнительную нагрузку на случайные запросы передачи зон. Просто нет логической причины, по которой это могло бы произойти. Следовательно, я был бы почти уверен, что это какая-то атака.
Единственные серверы, которым нужен доступ AXFR, - это серверы вторичной зоны, все остальное может использовать стандартные протоколы DNS, как и предполагалось!