DNS hijacking

Сервер-шахрай DNS переводить доменні імена популярних вебсайтів (пошукових систем, банків і т. д.) в IP-адреси сайтів з непередбачуваним вмістом, навіть шкідливих вебсайтів. Більшості користувачів DNS-сервери призначаються автоматично їх провайдерами. Комп'ютери-зомбі запускають трояни, непомітно змінюють адресу автоматично присвоєну провайдером DNS-сервера на DNS-сервер шахрая. Коли користувачі намагаються відвідати вебсайти, вони потрапляють на підроблений сайт. Така атака називається фармінг. Якщо шкідливий сайт, на який перенаправляються запити, маскуючись під легальний вебсайт, який намагається обманним шляхом отримати доступ до конфіденційної інформації, то це називається фішингом.

Деякі провайдери, такі як OpenDNS, Cablevision's Optimum Online, Comcast, Time Warner, Cox Communications, RCN, Rogers, Charter Communications, Verizon, Virgin Media, Frontier Communications, Bell Sympatico, UPC, T-Online, Optus, Mediacom, ONO, TalkTalk і Bigpond (Telstra) використовують перенаправлення DNS в своїх цілях, наприклад для відображення реклами або збору статистики. Це порушує RFC стандарти для DNS (NXDOMAIN)-відповідей і може відкрити користувачам можливість міжсайтового скриптингу.

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

Так, якщо доменне ім'я запитується на одному з цих неіснуючих провайдерів, можна отримувати підроблену IP-адресу, що належить провайдеру. У веб-браузері така поведінка може бути дратівливою або образливою, коли з'єднання з цією IP-адресою відображають провайдерські сторінки перенаправлення, іноді з рекламою, замість належного повідомлення про помилку. Однак, інші програми, які покладаються на помилку NXDOMAIN, замість цього будуть намагатися ініціювати з'єднання з цією підробленою IP-адресою, потенційно піддаючи ризику конфіденційну інформацію.

Приклади функціональності, яка пропадає, якщо провайдери перенаправляють DNS:

• Маршрутизовані ноутбуки, є членами домену Windows Server, помилково припускають, що вони повернулися в корпоративну мережу, тому що ресурси, такі як контролери домену, поштові сервери та інші об'єкти інфраструктури, стають доступні. Програми намагаються ініціювати з'єднання з цими корпоративними серверами, але зазнають невдачі, що призводить до погіршення продуктивності, непотрібного трафіку в Інтернеті і тайм-аутам.
• Багато малих офісів і більшість домашніх мереж не мають власного сервера DNS, покладаючись натомість на широкомовний дозвіл імен. Оскільки DNS-запити є більш пріоритетними, ніж локальне широкомовлення, всі імена будуть помилково відправлятись на сервери, що належать провайдеру, і локальна мережа працювати не буде.
• Браузери, такі як Firefox, не зможуть виконувати «пошук по імені» (коли ключові слова, набрані в адресному рядку, перенаправляють вас на найближчий знайдений сайт).
• Локальний DNS-клієнт, вбудований в сучасні операційні системи, буде кешувати результати DNS-пошуку для підвищення продуктивності. Якщо клієнт перемикається між домашньою мережею і VPN, помилкові записи можуть залишитися закешованими, тим самим створюючи перерви в обслуговуванні з'єднання VPN.
• Анти-спам рішення DNSBL засновані на DNS; тому помилкові результати DNS заважають правильній роботі DNSBL.
• Конфіденційні дані користувача можуть бути розкриті додатком, який ввів в оману провайдер, вдаючи, що сервіс, до якого він намагається підключиться, доступний.
• Пошукова система не зможе виправляти неправильно надруковані URL, спираючись на попередні вибори користувача, так як провайдер визначає, які результати пошуку відобразити користувачеві; додатки, такі як панель інструментів Google, не зможуть працювати коректно.
• Комп'ютери, налаштовані на використання роздільного тунелювання  перестануть працювати з VPN-підключенням, тому що імена інтрамережі, які не повинні дозволятися поза тунелем в публічній мережі Інтернет, стануть дозволятися фіктивні адреси, замість того, щоб коректно дозволятися через VPN-тунель на приватному DNS-сервері при отриманні запису NXDOMAIN з Інтернету. Наприклад, поштовий клієнт, який намагається дозволити DNS запис типу А для внутрішнього поштового сервера, може отримати помилкову DNS-відповідь, яка направляє на платний веб-сервер з чергою повідомлень на доставку у разі, якщо повторна передача була невдалою.
• Це порушує роботу WPAP (протоколу автоматичного налаштування проксі), змушуючи веб-браузери помилково вважати, що провайдер має конфігурацію проксі-сервера.
• Це порушує роботу програмного забезпечення для контролю. Наприклад, якщо ми періодично звертаємося до сервера для перевірки працездатності, монітор не помітить підробки, поки не спробує перевірити криптографічний ключ сервера.

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

Деякі реєстратори доменних імен, зокрема Name.com, виробляють перенаправлення DNS при невдалому пошуку доменних імен, незважаючи на заперечення проти цього ICANN і їх споживачів.