авторитетная архитектура сервера имен в отношении зон и дочерних узлов (лучшие практики)

Я ищу переделку архитектуры dns среднего размера (corp), и я искал здесь и icann.org + google (конечно), но я не могу найти наилучшую практику в отношении записей сервера имен и зон / дочерних узлов.

Итак, давайте, допустим, у нас есть 10+ DNS-серверов:
затем мы говорим happy.example.com
и затем у нас есть:
A Records
- ns1.happy.example.com 222.222 .222.222
- ns2.happy.example.com 333.333.333.333
- ns3.happy.example.com 444.444.444.444
- NS Records
- happy.example.com ns1.happy.example .com
- happy.example.com ns2.happy.example.com
- happy.example.com ns3.happy.example.com

ТОГДА у нас есть sad.example.com:
- A Records
- ns1.sad.example.com 222.222.222.222
- ns2.sad.example.com 333.333.333.333
- ns3.sad .example.com 444.444.444.444
- NS Records
- sad.example.com ns1.sad.example.com
- sad.example.com ns2.sad.example.com
- sad .example.com ns3.sad.example.com

У меня вопрос, есть ли в этом какие-то преимущества?
Не лучше ли просто сделать:
- Запись
- ns1.example.com 222.222.222.222
- ns2.example.com 333.333. 333.333
- ns3.example.com 444.444.444.444

Затем выполните:
- NS Records
- happy.example.com ns1.example.com
- happy.example.com ns2.example.com
- happy.example.com ns3.example. ru
- sad.example.com ns1.example.com
- sad.example.com ns2.example.com
- sad.example.com ns3.example.com


person Travis    schedule 30.07.2015    source источник


Ответы (1)


Мое эмпирическое правило - оптимально 3-5 респондентов. Обычно я бы предпочел, чтобы респондент выполнял функции балансировщика нагрузки перед как минимум двумя серверами, но это личное предпочтение в сочетании с доступностью оборудования.

Что касается иерархии доменов, только ваши серверы имен являются авторитетными? или также рекурсивный? Сколько клиентов? Сколько зон?

Что касается вашего конкретного вопроса, если ваши домены не являются абсолютно огромными, не должно быть причин, по которым одни и те же серверы не могут быть авторитетными для обоих, и да, лучше разместить серверы имен в домене более высокого уровня. В противном случае вам также придется включать записи GLUE.

person Rick Buford    schedule 30.07.2015