DNS-субдомен (дочерний) NS-записи
это мой первый пост здесь, так что извините, если я не все опубликовал правильно.
в любом случае, мой вопрос касается файлов зон в родительском и детские зоны. если у нас есть example.com , мы бы настроили что-то вроде этого:
$ORIGIN example.com.
@ 1D IN SOA ns1.example.com. hostmaster.example.com. (
2002022401 ; serial
3H ; refresh
15 ; retry
1w ; expire
3h ; nxdomain ttl
)
IN NS ns1.example.com.
IN NS ns2.example.com.
, поскольку в родительской зоне .com. для example.com уже есть NS-запись. дочерняя зона и связующая запись для ns1.example.com. с какой целью мы снова указываем NS-записи в дочерней зоне?
а также нужно ли нам указывать A-запись для серверов имен в самой дочерней зоне?
надеюсь, вы понимаете мой вопрос.
спасибо в продвинутом.
Как это работает
Авторитетные записи NS находятся внутри самой зоны (и представлены в разделе ОТВЕТ при запросе полномочного сервера ), как и все другие записи, которые являются частью этой зоны.
Чтобы иметь возможность перемещаться по дереву, информация о переходах / делегировании / полномочиях ( NS и любой клей A / AAAA записи необходимы) также добавляется в родительскую зону.
Эта информация, однако, не рассматривается как «настоящий ответ», в ответе отсутствует флаг AA (авторитетный ответ), а записи NS находятся в AUTHORITY ], чтобы указать, что это просто информация о том, у кого есть реальный ответ.
Одно из следствий этого состоит в том, что если вы выполняете прямой поиск записей NS , вы будете следить за этой ссылкой и запрашивать авторитетный сервер, несмотря на то, что вы только что видели, что должно быть той же информацией.
] Почему было определено работать таким образом?
Предположительно, потому что считалось правильным / чистым / логичным, что все авторитетные записи находятся внутри зоны, к которой они принадлежат, и что авторитетные записи должны быть также для NS .
Могло ли это быть определено иначе?
Да. Посмотрите, например, как были определены записи DS , когда они были введены намного позже. В этом случае внутри дочерней зоны такой записи нет, вместо этого авторитетным является родитель.
Могу ли я сделать это по-другому?
Нет. Поскольку он был определен таким, каким был, и все программное обеспечение работает в соответствии с тем, как оно было определено, все будет ломаться (часто незаметно), если вы не сделаете это должным образом.dr
Вам нужны одинаковые записи NS как в вашей зоне, так и в качестве информации о делегировании в родительской зоне. Точно так же любые связующие A / AAAA записи также должны существовать как настоящие официальные записи.
Как бы мне ни не хотелось не соглашаться с моим уважаемым коллегой, записи NS в зоне действительно служат некоторым целям. Например, 1ary NS должен знать, кем являются все остальные NS, чтобы в случае обновления зоны он мог отправить им все DNS NOTIFY, чтобы они знали, что нужно выполнять передачу зоны. Эту информацию он получает из записей внутри зоны NS .
Что касается записей DS , не имеющих аналогов внутри зоны, то DS представляет собой простой дайджест записи KSK DNSKEY внутри зоны. Эта запись, как и записи NS , была бы зеркально отражена внутри и вне зоны, если бы не значительная длина записей KSK и влияние на производительность доменов с десятками миллионов дочерних записей, например, .com , для поддержки аналогичного количества записей произвольной длины. Таким образом, принято решение хранить только дайджест в родительской зоне - но они все равно являются той же записью, и копии внутри и вне зоны должны совпадать, как и с записями NS .
tl; доктор
Хакан прав; вам нужны эти внутризонные записи, и они действительно должны соответствовать внешним (приклеиваемым) копиям. Как правило, не нарушайте RFC, если вы действительно не знаете, что делаете.