Особливості розміщення адрес в DNS

Існують деякі обмеження у використанні DNS під час переходу від IPv4 до IPv6.
Так, рекомендується не додавати до DNS АААА записів до тих пір, поки не виконаються наступні 3 умови:
1. Адресу призначено інтерфейсу на вузлі.
2. Інтерфейс налаштовано на адресу.
3. Інтерфейс знаходиться на каналі, що під’єднаний до IPv6 інфраструктури.

За таких умов, якщо вузол не під’єднано до жодної з мереж IPv6, то виходячи з обмеження №3, такий вузол не повинен мати IPv6 записів в DNS.
Ця схема добре працює якщо інші вузли з подвійним стеком намагаються встановити зв’язок з даним напів-ізольованим вузлом. Оскільки в DNS відсутні АААА записи для цього вузла, то сторона, що викликає, навіть не намагається використовувати IPv6 для встановлення з’єднання, а одразу переходить до IPv4 (за умови, що IPv4 А-запис присутній в DNS).
Проте необхідно зауважити, що подібна схема перестає працювати коли ізольований вузол намагається встановити з’єднання. Навіть якщо вузол не має власного запису в DNS, він все одно знайде АААА запис в DNS для вузла з яким намагається встановити з’єднання. Оскільки ізольований вузол має IPv6 адресу, яка призначена хоча б до одного його інтерфейсу, він намагатиметься встановити з’єднання використовуючи IPv6. Через відсутність маршруту до IPv6 мережі (адже вузол ізольований) з’єднання не відбудеться. Зазвичай, це означає декілька хвилин затримки через TCP тайм-аути. Як тільки тайм-аут TCP закінчиться, прикладна програма може спробувати здійснити з’єднання, використовуючи IPv4 адресу, але до цього моменту пройде достатньо багато часу.
Інша проблема може виникнути навіть якщо обидва вузли мають з’єднання через мережі IPv4 та IPv6. Ця проблема стосується прикладних сервісів, які використовуються на вузлах. Наявність подвійного стеку IPv6/IPv4 не означає, що всі прикладні сервіси будуть працювати за обома протоколами. За таких вихідних даних можлива поява ситуації, зображена на рис:

Подвійний стек, але сервіс тільки IPv4

На рис. зображено 2 вузли, кожен з яких має подвійний стек, адреси обох типів, а також А та АААА записи в DNS. Вузол А має двопротокольний веб-клієнт (web-v4/6), а вузол Б веб-сервер (httpd-v4), який очікує запити лише на IPv4 адресі. Вузол А намагається встановити з’єднання з вузлом Б по його назві. Завдяки системному виклику getaddrinfo() та системі DNS вузол А отримує 2 адреси для вузла Б – IPv6 та IPv4 адреси. При спробі встановити з’єднання з вузлом Б за його IPv6 адресою вузол А зазнає невдачі, оскільки на вузлі Б не відкритий відповідний сокет (IPv6_адреса:порт).
Проблема може бути частково вирішена на прикладному рівні. Тобто двопротокольна прикладна програма повинна ініціювати з’єднання по другому протоколу, якщо з’єднання по першому протоколу не відбулося. Проте слід зауважити, що інтерактивність та зручність у користуванні такими програмами буде втрачено.
Наведений приклад не є достатнім для опису можливих проблем при взаємодії подібного типу. Він призначений лише для того, щоб вказати на недостатність трьох вимог, вказаних вище. Отже, лише за рахунок DNS проблему взаємодії двох вузлів з подвійним IPv6/IPv4 стеком не вирішити.

Далі – “Основні механізми тунелювання”

Опубліковано на сайті: “IPv6 українською“