Це канонічне запитання щодо того, чи слід передавати роздільну здатність DNS для власних доменів

На даний момент у мене є провайдер, що надає DNS для мого домену, але вони обмежують додавання записів. Тому я думаю про запуск власного DNS.

Ви віддаєте перевагу розміщення власного DNS, або краще, щоб ваш провайдер це робив?

Чи є альтернативи, на які я можу розглянути?

Я б не запускав власний сервер DNS - у моєму випадку компанія, що розміщує хостинг, розміщує мій веб-сайт, надає безкоштовну послугу DNS. Є також альтернативи, компанії, які не роблять нічого, окрім DNS-хостингу ( DNS Made Easy приходить на думку, але є багато інших), які є тими речами, на які, напевно, слід звернути увагу.

Причиною цього я не став би сам те, що DNS повинен бути досить надійним, і якщо ви не маєте власну географічно розподілену мережу серверів, ви б клали всі яйця в один кошик, так би мовити. Крім того, там є багато виділених серверів DNS, достатньо, щоб вам не потрібно було запускати новий.

Ми завжди розміщуємо власний DNS (бажано також і зворотного DNS). Це дозволяє нам вносити надзвичайні зміни, не покладаючись на сторону. Якщо у вас є більше одного місця, легко встановити доступний рівень надмірності для ваших серверів DNS.

Якщо у вас немає декількох сайтів, я б розглядав когось, хто спеціально займається хостингом DNS (НЕ ваш провайдер) із веб-інтерфейсом для змін. Подивіться також на підтримку 24x7 та гідні угоди SLA.

Для гарного, надійного налаштування DNS для вашого домену (ів), ви повинні мати ...

• Мінімум два авторизовані DNS-сервери для вашого домену;
• Сервери DNS повинні бути підключені до різних фізичних мереж та джерел живлення;
• Сервери DNS повинні знаходитися в різних географічних районах.

Оскільки навряд чи у вас є доступ до вищевказаної мережевої інфраструктури, вам краще вибрати надійного постачальника хостингу DNS (як рекомендували інші), який має вищевказану мережеву інфраструктуру.

Протягом багатьох років я керував власними серверами DNS за допомогою BIND (версії 8 та 9) без особливих клопотів. Я зберігав свої конфігурації в режимі контролю версій за допомогою перевірок після фіксації, які підтверджували б файли зон, а потім мої сервери DNS перевіряли файли зон регулярно. Проблема завжди полягала в тому, щоб серійний номер SOA оновлювався з кожною комісією, яку виштовхували, інакше сервери кешування не оновлюються.

Роками пізніше я працював з djbdns, оскільки формат був ідеальним для автоматизованих скриптів для управління зонами і не страждав від тієї ж проблеми серійного номера SOA, з якою мені довелося мати справу з використанням BIND. Однак у нього були свої проблеми з необхідністю форматування певних наборів записів ресурсів, щоб їх прийняти.

Оскільки я виявив, що більша частина мого трафіку була DNS і мені потрібно підтримувати як основний, так і вторинний DNS-сервер, щоб задовольнити реєстраторів, з яких я перейшов на використання EasyDNS для моїх потреб DNS. Їх веб-інтерфейс простий в управлінні і дає мені гнучкість для управління наборами RR. Я також виявив, що працювати з цим легше, ніж ті, які надаються деякими постачальниками послуг хостингу, як-то 1 та 1, які обмежують доступні набори RR, які ви можете ввести, або навіть реєстратори домену, такі як Network Solutions, який працює лише у тому випадку, якщо ви використовуєте Windows для управління своїм DNS.

Для моїх особистих доменів (і деяких доменів друзів, з якими я допомагаю) ми розміщуємо власний DNS, а мій реєстратор (Gandi) надає вторинну DNS. Або друг у іншій мережі надає другорядне. Ганді не оновлює зони одразу, вони, здається, перевіряють один раз кожні 24 години, але зміни дуже рідкі; працює досить добре для нас, і їх сервер, ймовірно, набагато надійніший за наш.

На моїй роботі ми займаємося власним DNS, а наш постачальник мереж надає вторинну DNS. Однак ми - університет, і 99% наших користувачів знаходяться на місці; якщо локальна мережа не працює, значення DNS не має. Крім того, у нас є повний клас B (/ 16) з приблизно 25 к. DNS-записів (плюс 25 к.с. зворотних записів DNS, звичайно), що здається трохи незручним для управління через веб-інтерфейс. Наші локальні сервери DNS - це високодоступні та досить швидкі.

Я зробив і те, і інше. При влаштуванні власного хостингу можуть бути переваги: ​​ви, безумовно, дізнаєтесь багато про те, як працює DNS, коли ваш начальник запитує вас, чому його потрібно так довго. Крім того, ви набагато більше контролюєте свої зони. Це не завжди настільки потужно, як це повинно бути, значною мірою завдяки ієрархічному розподіленому характеру DNS - але це раз у раз стає корисним. Удвічі так, якщо ви можете змусити свого постачальника призначити вас як SOA для зворотного DNS вашого IP-блоку, якщо припустити, що він є.

Однак усі коментарі вище про те, як вам справді повинно бути вбудовано багато стійкості до відмов, наведені вище. Сервери в різних центрах обробки даних в різних географічних районах є важливими. Вдавшись через потужне відключення електроенергії на Північному Сході в 2003 році, ми всі дізналися, що наявність коробки в двох різних центрах обробки даних в одному місті, або навіть провінції чи штаті - не обов'язково є достатньою захистом. Захоплення, яке виникає, коли ви розумієте свої акумулятори, а потім дизельні генератори, врятували ваш зад, швидко замінюється страхом, викликаним усвідомленням того, що ви зараз їдете на запасній шині.

Однак я завжди запускаю наш внутрішній DNS-сервер для локальної мережі. Це може бути дуже зручно мати повний контроль над DNS, який ваша мережа використовує внутрішньо, - і якщо живлення вимкнеться у вашому офісі, ваш внутрішній DNS-сервер через наявність серверної стійки, ймовірно, на акумуляторі або акумуляторі та дизелі, поки ваші ПК не будуть - значить, ваші клієнти будуть офлайн задовго до того, як сервер буде.

Я читаю всі ці рішення з деяким розвагою, тому що нам вдалося випадково вписатись у всі ці "вимоги", розмістивши наш основний DNS поза статичною лінією DSL, і з допомогою реєстратора (який був на іншому континенті) надавати вторинну DNS на набагато серйозніший і надійний зв’язок. Таким чином, ми отримуємо всю гнучкість використання bind та встановлення всіх записів, при цьому, будучи обґрунтованою впевненістю, що вторинник оновлюється для відображення цих змін і буде доступний у випадку попадання каналізаційного люка, щоб цитувати одне подія.

Це ефективно відповідає:
"Мінімум два авторитетні DNS-сервери для вашого домену;"
"Сервери DNS повинні бути підключені до різних фізичних мереж та джерел живлення;"
"Сервери DNS повинні бути в різних географічних районах."

Погляньте на Dyn.com ; у них є всі види послуг, пов’язаних з DNS, такими як хостинг DNS, динамічний DNS, MailHop тощо, тощо.

Це залежить.

Я керував власним DNS для своїх різних завдань з кінця 80-х (BSD 4.3c). Для роботи я завжди розміщував власний DNS, але в мене завжди було декілька локацій центрів обробки даних, або я міг обмінятись вторинним DNS з партнером. Наприклад, на моїй останній роботі ми зробили вторинну DNS для іншої .EDU (вони були в MN, ми в CA), і вони зробили те саме для нас. Географічне та мережеве різноманіття.

Або на моїй теперішній роботі у нас є власні центри обробки даних східного та західного узбережжя (США). Хостинг власних DNS дозволяє нам вводити будь-які незвичні записи DNS, які нам можуть знадобитися (SVR, TXT тощо), які можуть не підтримуватися деякими послугами GUI DNS. І ми можемо змінювати TTL, коли завгодно; ми маємо велику гнучку гнучкість, ціною зробити це самостійно.

Для домашніх речей я це робив обома способами. У деяких областях, де я займаюся незвичними речами або потрібна велика гнучкість, я все ще запускаю власні "приховані" майстер-сервери DNS та обмінююсь публічними службами DNS з іншими, хто робить те саме. Я використовую RCS для файлів зон управління версіями для управління конфігурацією, так що я можу побачити всю історію змін зони назад до початку часу. Для таких простих речей, як домен з одним блогом або загальними веб-серверами (один запис A або один CNAME), просто простіше використовувати службу DNS-реєстраторів домену, коли вона доступна, і тепер переживайте за CM.

Це компроміс. Кінцевий контроль та гнучкість пов'язані з власною керуванням різноманітністю, запуском декількох серверів, вирішенням несправностей з апаратним / програмним забезпеченням і т.д. вирішити свою проблему, ймовірно, за меншими загальними витратами.

Як уже згадувалося в цій темі, існує кілька спеціальних випадків з DNS, найбільш суттєва різниця - між авторитетними та кешуючими розгортаннями серверів імен.

1. Якщо вам потрібен DNS-сервер для вирішення ресурсів Інтернету, мудрий вибір деяких безкоштовних DNS-рішень для готівки. Я особисто використовую рекурсор PowerDNS (pdns-recursor) в Linux.

2. Для обслуговування вашої зовнішньої інфраструктури, наприклад веб-сайтів або MX, я б не використовував внутрішні NSes (якщо ми говоримо про SOHO тут). Скористайтеся хорошим, надійним, бездоганним сервісом, таким як DNSmadeasy . Я використовую їх бізнес-пакет, і він хитається, будучи дуже доступним.

Я використовував Zonedit або роки. Це дешево (або безкоштовно), і я додав багато записів CNAME, A, MX, TXT, SRV та інших записів.

Нещодавно ми привели в дім наш загальнодоступний DNS, коли ми принесли всі наші послуги вдома. Це дозволяє нам оновлювати все так швидко, як нам потрібно. На даний момент географічно розподілений DNS для нас не є вимогою, оскільки веб-сервери знаходяться на одному сайті.

У мене найкраще з обох світів.

Я розміщую свій загальнодоступний DNS для своїх веб-сайтів і своїх MX-записів "десь ще". Це надійно, це безпечно, працює, я можу його змінити за бажанням. Я плачу за послугу і задоволений ціною.

Але вдома я запускаю власний DNS-сервер кешування, а не покладаюся на свій провайдер. У мого провайдера є звичка втрачати DNS, мати повільний DNS, недійсний DNS, а іноді вони хочуть перекрутити DNS, щоб невдачі потрапляли в місця, які, на мою думку, можуть мені зацікавити. Мені не цікаво використовувати DNS мого провайдера. Тож у мене є власні кешування DNS-серверів і робити це самостійно. Налаштувати було трохи зусиль на початку (можливо, 2 години), але це чисто і у мене надійний DNS. Раз на місяць робота cron допитує кореневі сервери та оновлює таблицю підказок. Можливо, раз на рік мені доводиться поспілкуватися з цим, як-от відправити doubleclick.com на 127.0.0.1 чи подібне. Крім цього, він не потребує втручання, і він чудово працює.

Якщо ви вирішили розмістити свій власний DNS для любові до бога, у вас є два сервери dns на сайті. Один для вашого зовнішнього DNS, безпосередньо прикріпленого до брандмауера, щоб світ знайшов вас. І окремий у вашій мережі для вашого будинку dns.

Я поки не можу коментувати, але я роблю те саме, що і freiheit. Ми запускаємо наш основний DNS тут, в нашому DMZ, і наш Інтернет-провайдер має декілька підлеглих DNS-серверів по всій країні, які оновлюються негайно після внесення змін у основний DNS.

Це дає найкраще з обох світів; негайний контроль плюс скорочення.

У кожного підходу є плюси і мінуси, але я, безумовно, віддаю перевагу внутрішньому розміщенню вашого внутрішнього DNS. Перелік речей, на які ви покладаєтесь в основних мережевих послугах, якщо ви розміщуєте їх зовнішньо, - це неприємно. Генеральний директор може подумати, що розумно економити гроші на серверах DNS, розміщуючи зовнішньо хостинг, але що він думатиме, коли не зможе отримати свою електронну пошту, якщо посилання в Інтернеті знизиться?

З досвіду, якщо ви хочете привернути атаку відмови в службі, розмістіть власну DNS. І власний веб-сайт.

Я віруюча людина, є деякі речі, які ви не повинні робити самі. DNS-хостинг - одна з них. Як багато хто казав, вам знадобляться зайві сервери, з'єднання та фізичні місця, і ви все одно не підходите до стійкості навіть менших хостинг-компаній.

Найбільшою перевагою для розміщення власного DNS є те, що зміни можна вносити відразу. Потрібно скоротити свої TTL для майбутньої міграції? Можливо, ви могли б написати сценарій, який робить це на власних серверах; для розміщеного DNS може знадобитися увійти та змінити записи вручну, або ще гірше, зателефонувати провайдеру, пройти 3 рівні підтримки, поки ви нарешті не досягнете певного, який може писати DNS, просто щоб вони повідомили, що вони надішлють змінюється через 2-3 дні.

Я запускаю власний DNS за допомогою BIND на серверах Linux. В даний час у мене є чотири, розташовані в Лондоні, Великобританії, Майамі, Флоріда, Сан-Хосе, Каліфорнія та Сінгапурі. Чудово працює, і я маю повний контроль. Стабільність центру обробки даних є дуже важливою, тому я вибрав хороші постійні токи для запуску серверів (не залежать від ISP або іншої "невідомої" інфраструктури). Я можу налаштувати DNS-сервери та інші служби в будь-якій точці світу, використовуючи DC світового класу, які я вибираю на основі суворих критеріїв. Солідний DNS важливий для електронної пошти та веб-служб, які я запускаю.

Чи слід розміщувати власних серверів імен?

Так, і ви також повинні використовувати одну руду більше великих постачальників DNS сторонніх розробників. Гібридне рішення, ймовірно, є найбезпечнішим довгостроковим підходом з декількох причин, особливо якщо ви є бізнесом, який має будь-яку садибу угоди про Угоди або договірні вимоги до своїх клієнтів. Тим більше, що ти b2b.

Якщо ваш головний DNS-сервер (прихований або загальнодоступний) є вашим джерелом істини, тоді ви захищаєте себе оперативно від замикання в конкретних можливостях постачальника. Після того, як ви почнете використовувати їх чудові функції, що виходять за рамки базового DNS, ви можете виявити, що переключення на іншого постачальника або розміщення власного DNS є проблематичним, тому що вам доведеться повторити ці можливості. Прикладами можуть бути перевірки стану сайту та відмова від DNS, які надають Dyn та UltraDNS. Ці риси чудові, але їх слід вважати одноразовими, а не залежними. Ці функції також не дуже добре повторюються від постачальника до постачальника.

Якщо у вас є лише сторонні постачальники, то на їх тривалість може вплинути час, коли вони опиняться під цільовою атакою DDoS. Якщо у вас є лише власні DNS-сервери, то, коли ви будете об'єктом DDoS-атаки, це може вплинути на тривалість роботи.

Якщо у вас є один або більше DNS-провайдерів і власні розподілені DNS-сервери, які підпадають на приховані головні DNS-сервери, якими ви керуєте, тоді ви переконаєтесь, що ви не заблоковані у конкретного постачальника, а також будете постійно контролювати свої зони і що атаки повинні знищувати як ваші сервери, так і одного або декількох основних постачальників, які підкоряються вашим серверам. Все, що не буде цим, буде погіршенням обслуговування та критичним відключенням.

Ще однією перевагою наявності власних основних (ідеально прихованих, неопублікованих) серверів є те, що ви можете створювати власний API та оновлювати їх у будь-якій садибі відповідно до потреб вашого бізнесу. З сторонніми постачальниками DNS вам потрібно буде адаптуватися до їх API. У кожного продавця є свій; або в деяких випадках просто має веб-інтерфейс.

Крім того, якщо ваш господар знаходиться під вашим контролем і у постачальника виникають проблеми, то будь-який з ваших рабовласницьких серверів, який все ще може дістатися до вашого господаря, отримає оновлення. Це те, що ви хотіли б мати після того, як ви зрозуміли, що мати третьої сторони як свого господаря було помилкою під час великого інциденту DDoS, і ви не можете змінити жоден сервер провайдерів, які не атакуються.

З юридичної точки зору, запобігання блокуванню постачальників може також бути важливим для вашого бізнесу. Наприклад, Dyn потенційно купується Oracle. Це ставить їх в унікальне становище для збору статистики DNS для всіх клієнтів Dyn. Існують конкурентні аспекти цього, які можуть спричинити юридичний ризик. Це сказало, що я не юрист, тому вам слід проконсультуватися зі своїми юридичними та PR-групами з цього приводу.

До цієї теми є багато інших аспектів, якщо ми хотіли копати бур’яни.

[Редагувати] Якщо це лише для невеликого особистого / хобі-домену, то 2 ВМ, які не знаходяться в одному центрі обробки даних, як один для одного, для роботи невеликого демона DNS більш ніж достатньо. Я роблю це для власних особистих доменів. Мені було не ясно, чи означає ваш домен бізнес чи просто для хобі. Що б найменшого VM ви не могли отримати, більш ніж достатньо. Я використовую rbldnsd для своїх доменів; використовуючи дуже високий вміст TTL у своїх записах, оскільки він займає 900 КБ оперативної пам’яті і може справлятися з будь-якими зловживаннями, які люди на нього кидають.

Подумайте про хостинг DNS як основу для ваших публічних служб. У моєму випадку електронна пошта має важливе значення для нашого бізнесу. Якщо ви розміщуєте свій DNS всередині мережі, а підключення до Інтернету не вдається зникнути, ваші записи DNS можуть стати черсткими, що змушує ваш домен бути недоступним.

Тож у моєму випадку, якщо запису MX неможливо знайти для нашого домену, електронний лист одразу відхиляється.

Отже, у нас DNS розміщується зовні.

Якщо запис MX доступний, але наше з'єднання з Інтернетом відключено, пошта буде продовжувати чергуватися на серверах, які намагаються надсилати електронну пошту на наш домен.

Це залежить. ™

Я керував власними серверами та керував доменами щонайменше з 2002 року.

Я часто використовував DNS-сервер свого провайдера.

Кількість випадків, коли мій сервер під час моєї IP був доступний, але мій DNS не був, було декілька занадто багато.

Ось мої історії війни:

• Один постачальник юг в Москві (один з перших на VZ) бачив мій VPS в дешевому "значенні" постійного струму, але їх DNS знаходився в преміальному стані постійного струму з дорогим трафіком, за два різні / 24 підмережі, як того вимагали деякі TLD на той час . Одного разу потрапило в аварію (можливо, відключення електроенергії 2005 року? ), І їхній дорогий постійний струм відключився в автономному режимі, і на мій сайт (все ще в Москві, але в "величині" DC) можна було отримати доступ лише за його IP-адресою.

  Цікаво, що ще до яких - або інцидентів, я добре пам'ятаю робити traceroute, і, помітивши той же DC для обох ns1і ns2мого провайдера, з проханням перенести одну в «мій» DC, також, для гео-резервування; вони відкинули ідею про надмірність гео, оскільки сервери вже були в найпремісніших можливих DC.

• У мене був ще один провайдер (один із перших на базі ISP-систем), де вони мали одну службу на місці, а іншу за кордоном. Якщо коротко сказати, ціла настройка була смішно баггі, і сервер "за кордоном" часто не міг підтримувати свої зони, тому мій домен фактично мав додаткову точку збою і не був би доступний, навіть якщо весь мій сервер все ще працював безперебійно.

• У мене був реєстратор, який керував власною мережею. Він знижувався раз у раз, навіть не дивлячись на те, що мої сервери поза межами сайту піднімалися. Мій DNS не працює.

• Я нещодавно використовував кілька великих хмарних провайдерів для вторинних, де я сам запускав прихованого майстра. Обидва провайдери принаймні один раз змінили налаштування; ніколи з будь-якими публічними оголошеннями; деякі мої домени припинили вирішення. Сталося і з моїм другом, з одним із тих самих постачальників. Це трапляється частіше із сторонніми послугами, ніж люди хочуть визнати себе на публіці.

Одним словом, http://cr.yp.to/djbdns/third-party.html абсолютно правильний по темі.

Витрати, що турбуються з сторонніми DNS, часто не мають переваг.

Негативи наявності сторонніх DNS часто несправедливо не враховуються.

Я б сказав, що якщо ваш домен вже не використовує сторонні сервіси (наприклад, для Інтернету, пошти, голосу чи тексту), то додавання сторонніх DNS майже завжди буде контрпродуктивним, і ні в якому разі не є найкращою практикою за будь-яких обставин. .