Я хотел бы знать, может ли корневой сервер делегировать разные подзоны зоны разным серверам имен, а остальные - серверу имен по умолчанию.
Например. У меня есть зоны "вещь.", "Кое-что.", "Что-нибудь", "i.do.some.thing.", "I.do.any.thing.". Как должен выглядеть файл корневой зоны, если мне нужно следующее поведение:
Каждый запрос к "i.do.some.thing" и "* .i.do.some.thing" отправляется на сервер имен a
Каждый запрос к "i.do.any.thing" и "* .i.do.any.thing" переходит на сервер имен b
Оставшиеся запросы к "some.thing" и "* .some.thing" переходят на сервер имен c
Остальные запросы к "any.thing" и "* .any.thing" переходят на сервер имен d
Остальные запросы к "thing" и "* .thing" переходят на сервер имен e
Возможно ли это для корневого сервера имен или это может сделать только авторитетный сервер имен?
Нет, корневая зона не может делегировать дальше по дереву то, что уже было делегировано в другом месте. По крайней мере, без нарушения протокола и создания странных несоответствий.
Полномочный сервер для каждой зоны может делегировать любые поддомены, создавая новые зоны, которые могут находиться в другом месте.
Пример того, как это работает:
Корень (.) делегаты зоны example. к ns.example.
example. делегаты зоны foo.example. к ns.foo.example.
foo.example. делегаты зоны bar.foo.example. к ns.bar.foo.example.
и т.п.
Если бы вместо этого у вас была ситуация, когда корневая зона предоставляла бы авторитетную информацию для чего-то, что уже было делегировано в другом месте (чего нет!), Например:
Корень (.) делегаты зоны example. к ns.example.
Корень (.) делегаты зоны foo.example. к ns.foo.example.
Тогда вы окажетесь в ситуации, когда сервер распознавателя с разогретым кешем будет искать foo.example. может уже знать, что example. Я сидел ns.example. и затем начал бы запрос с этой точки (и, возможно, получил бы совершенно другой ответ), в то время как сервер-преобразователь с холодным кешем начал бы запрос в корне и получал бы информацию о делегировании оттуда (делегирование, которое не должно быть в состоянии сосуществовать с первой делегацией).
Вышесказанное не является тем, чего вы должны ожидать, но я полагаю, что с программным обеспечением с ошибками, которое нарушает протокол, или при какой-либо злонамеренной атаке такие ответы теоретически могут произойти. (DNSSEC решит некоторые из таких проблем, когда дело доходит до атаки.)
Делегирование зоны - это основная функция DNS
В файле корневой зоны вы должны описать хосты и подзоны.
$ORIGIN thing. ; root domain
@ IN NS ns.thing. ; who is responsible for root domain
ns IN A 11.22.33.44 ; It's me itself so I have to add the "glue record"
$ORIGIN any.thing. ; subdomain
@ IN NS ns.any.thing. ; who is responsible for subdomain
ns IN A 22.33.44.55 ; address of the ns.any.thing
$ORIGIN some.thing. ; subdomain
@ IN NS ns.some.thing. ; who is responsible for subdomain
ns IN A 33.44.55.66 ; address of the ns.some.thing
Затем вы можете делать все, что захотите, на NS-серверах поддомена, все запросы будут обрабатываться их подзонами.