Чи може хтось із того ж сервера DNS, що й я, викрав мої домени?

Коли я реєструю новий домен, я надсилаю його своєму провайдеру хостингу, присвоюючи йому його сервери доменних імен у налаштуваннях registar. Наприклад, за допомогою цифрового океану я ввожу наступне:

ns1.digitalocean.com
ns2.digitalocean.com
ns3.digitalocean.com

Потім я додаю налаштування домену у запис A мого сервера. Мені просто прийшло в голову, що будь-хто інший на тому ж постачальнику хостингу може додати запис A із власністю домену.

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

Ніколи не заперечуйте проти розділу коментарів нижче, і ніколи не заперечуйте проти попередніх відповідей в історії редагування. Приблизно через годину розмови з друзями (дякую @joeQwerty, @Iain та @JourneymanGeek), і деяких веселих хакерських дій, ми дійшли до нижньої точки вашого питання і ситуації в цілому. Вибачте за грубість та нерозуміння ситуації спочатку повністю.

Давайте переглянемо процес:

1. Ви купуєте wesleyisaderp.comна, скажімо, NameCheap.com.
2. Там, де ви будете заповнювати свої NS-записи, ви знайдете запит на ім'я. Скажімо, ви насправді хочете розмістити зону DNS у Digital Ocean.
3. Ви вказуєте NS записів блискучого нового домену на ns1.digitalocean.comта ns2.digitalocean.com.
4. Однак скажімо, я зміг визначити, що ви зареєстрували цей домен, і, крім того, ви змінили свої записи NS на Digital Ocean's . Тоді я побив вас до облікового запису Digital Ocean і додав зону wesleyisaderp.com до свого.
5. Ви намагаєтеся додати зону до свого * акаунта, але Digital Ocean каже, що зона вже існує у їхній системі! О, ні!
6. Я CNAME wesleyisaderp.comв wesleyisbetterthanyou.com.
7. Настає веселість.

Ми з друзями просто розігрували цей точний сценарій, і так, це працює. Якщо @JoeQwerty купує домен і вказує його на сервери імен Digital Ocean, але я вже додав цю зону до свого облікового запису, то я є майстром зони і можу робити з ним все, що я хочу.

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

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

Крім того, якщо ви володієте доменом у реєстратора, і якщо хтось випадково створив зону на провайдера, як-то Digital Ocean, з яким ви зіткнулися, я впевнений, що якщо ви надасте підтвердження права власності, він запитає особу, яка зробила зону в своєму обліковому записі, щоб видалити його, оскільки немає причин існувати, оскільки вони не є власником доменного імені.

А як щодо записів A

Першою особою, яка має зону, наприклад, Digital Ocean, буде та, яка керує нею. Ви не можете мати кілька однакових зон на одній інфраструктурі DNS. Так, наприклад, використовуючи дурні назви вище, якщо у мене є wesleyisaderp.com як зона в Digital Ocean, ніхто інший з DNS-інфраструктури DNS Digital Ocean не може додати його до свого облікового запису.

Ось найцікавіша частина: я насправді додав wesleyisaderp.com до свого облікового запису Digital Ocean! Вперед і спробуйте додати його до свого. Це нічого не зашкодить.

Отже, ви не можете додати запис A до wesleyisaderp.com. Це все моє.

А як же ...

Як @Iain вказував нижче, мій пункт №4 вище насправді занадто багатослівний. Мені взагалі не потрібно чекати, ані схему чи схему. Я можу просто зробити тисячі зон в обліковому записі, а потім сидіти і чекати. Технічно. Якщо я роблю тисячі доменів, а потім чекаю, коли вони зареєструються, і тоді сподіваюся, що вони використовуватимуть хости DNS, на які я встановив мої зони ... можливо, я можу щось погано зробити? Може бути? Але, мабуть, ні?

Вибачте за цифровий океан та ім'я NameCheap

Зауважте, що Digital Ocean та NameCheap не є унікальними і не мають нічого спільного з цим сценарієм. Це нормальна поведінка. Вони невинні на всіх фронтах. Я просто використовував їх, оскільки це був приклад, і вони дуже відомі бренди.

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

Основи такі:

• Ви зареєструєте свій домен (я перейду з іменитим ім'ям wesleyisaderp.comтут, просто тому.)
• Ви реєструєте сервери імен у свого реєстратора, як правило, через веб-інтерфейс, на який ви автентифікуєтесь за допомогою комбінаційного імені користувача / пароля.
• Ви також створюєте пару відкритих / приватних ключів, і ви завантажуєте свій відкритий ключ до свого реєстратора у вигляді запису DNSKEY. (Ось так реєстратор може налаштувати ланцюжок довіри до кореневих серверів для домену верхнього рівня - у цьому випадку кореневих серверів для .com.) Знову ж, ви завантажуєте це, коли ви входите з власним іменем / паролем комбо, тому він підключений до вашого домену (а), а не до чужого.
• Ви переходите до сервера імен, вводите свої записи і підписуєте отриманий зонний файл приватним ключем. Або якщо у вас є веб-інтерфейс до сервісу хостингу DNS, ви завантажуєте до них приватний ключ, щоб вони могли підписати до них файл зони.
• Коли Уеслі так грубо намагається викрасти ваш домен і CNAME його wesleyisbetterthanyou.com, його записи не будуть прийняті серверами кореневого домену .com, оскільки вони не підписані правою клавішею. Якщо ваш постачальник хостингових послуг DNS розумний, він перевірить це право з місця і навіть не дозволить йому намагатися додавати записи до цього домену, якщо у нього немає потрібного приватного ключа.
• Коли ви вводите власні записи, вони будуть підписані правою клавішею, тому вони працюватимуть.
• Тепер ви можете сидіти і сміятися над Веслі.

(У первісному випадку, той, який описує Уеслі, головна помилка полягала б у тому, що Digital Ocean не підтвердив право власності на домен, перш ніж дозволити комусь встановити записи DNS для нього. На жаль, вони в цьому не самотні; я знаю щонайменше одного шведського реєстратора з однаковими питаннями.)

Ви будете добре, поки ви заявите право власності на домен у DigitalOcean (тобто пов’язати його зі своїм обліковим записом), перш ніж ви скажете реєстратору використовувати їх сервери імен.

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

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

Я думаю, що це питання означає, що ніхто не повинен використовувати такі сервери імен (наприклад, Digital Ocean) як їхні розв’язувачі, оскільки кожен може зробити сервер імен для існуючого домену на них. Боротьба за контроль над доменом не має значення, оскільки право власності на домен можна довести легко, але той факт, що хтось, наприклад, може направити будь-який існуючий домен, який уже НЕ розміщений у Digital Ocean, куди завгодно.

Підсумок: не довіряйте серверам DNS жодної хостингової служби, яка не потребує підтвердження права власності на домен (це легко і швидко зробити, наприклад, запропонованим вище методом: додавши спочатку запис TXT з певним значенням у домен , це роблять, наприклад, Microsoft O365 та Google).