---
title: Взаємодія з DNS
linktitle: DNS
description: Як DNS взаємодіє з Istio.
weight: 33
keywords: [traffic-management,proxy]
owner: istio/wg-networking-maintainers
test: n/a
---

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

{{< warning >}}
Цей документ описує деталі низькорівневої реалізації. Для загальнішого огляду, перегляньте сторінки з [Концепції](/docs/concepts/traffic-management/) або [Завдання](/docs/tasks/traffic-management/) керування трафіком.
{{< /warning >}}

## Життя запиту {#life-of-a-request}

У цих прикладах ми розглянемо, що відбувається, коли застосунок виконує команду `curl example.com`. Хоча тут використовується `curl`, це стосується майже всіх клієнтів.

Коли ви надсилаєте запит на домен, клієнт виконує DNS-резолюцію, щоб перетворити його на IP-адресу. Це відбувається незалежно від будь-яких налаштувань Istio, оскільки Istio лише перехоплює мережевий трафік і не може змінювати поведінку вашого застосунку чи рішення про надсилання DNS-запиту. У наведеному нижче прикладі `example.com` був перетворений на `192.0.2.0`.

{{< text bash >}}
$ curl example.com -v
*   Trying 192.0.2.0:80...
{{< /text >}}

Далі запит буде перехоплено Istio. На цьому етапі Istio побачить як імʼя хосту (із заголовка `Host: example.com`), так і адресу призначення (`192.0.2.0:80`). Istio використовує цю інформацію, щоб визначити намічене призначення. Розділ [Розуміння маршрутизації трафіку](/docs/ops/configuration/traffic-management/traffic-routing/) докладно пояснює, як це працює.

Якби клієнт не зміг виконати DNS-запит, запит завершився б ще до того, як його отримав би Istio. Це означає, що якщо запит надіслано на хост, відомий Istio (наприклад, через `ServiceEntry`), але не відомий DNS-серверу, запит завершиться невдачею. [DNS-проксіювання](#dns-proxying) від Istio може змінити цю поведінку.

Як тільки Istio ідентифікував цільове призначення, він повинен вибрати адресу, на яку слід надіслати запит. Завдяки розширеним можливостям [балансування навантаження](/docs/concepts/traffic-management/#load-balancing-options) в Istio, це часто не є початковою IP-адресою, на яку надіслав запит клієнт. Залежно від конфігурації сервісу, Istio може виконати це кількома способами.

* Використати початкову IP-адресу клієнта (`192.0.2.0`, як у прикладі вище). Це відбувається для `ServiceEntry` типу `resolution: NONE` (стандартний тип) і для [headless сервісів](https://kubernetes.io/docs/concepts/services-networking/service/#headless-services).
* Балансувати навантаження на набір статичних IP-адрес. Це стосується `ServiceEntry` типу `resolution: STATIC`, де використовуються всі `spec.endpoints`, або для стандартних сервісів, де використовуються всі `Endpoints`.
* Періодично виконувати резолюцію адреси за допомогою DNS і балансувати навантаження серед усіх результатів. Це стосується `ServiceEntry` типу `resolution: DNS`.

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

## Резолюція DNS проксі {#proxy-dns-resolution}

На відміну від більшості клієнтів, які виконують DNS-запити на вимогу в момент запиту (а потім зазвичай кешують результати), проксі Istio ніколи не виконує синхронних DNS-запитів. Коли налаштовано `ServiceEntry` типу `resolution: DNS`, проксі періодично виконує резолюцію вказаних імен хостів і використовує їх для всіх запитів. Цей інтервал є фіксованим значенням (30 секунд) та не може бути змінений зараз. Це відбувається навіть якщо проксі ніколи не надсилає жодних запитів на ці застосунки.

Для мереж з багатьма проксі або багатьма `ServiceEntry` типу `resolution: DNS`, особливо коли використовується низький `TTL`, може створювати значне навантаження на DNS-сервери. У таких випадках можуть допомогти наступні дії для зменшення навантаження:

* Переключитися на `resolution: NONE`, щоб уникнути DNS-запитів проксі взагалі. Це підходить для багатьох сценаріїв.
* Якщо ви контролюєте домени, що обробляються, збільшіть їх TTL.
* Якщо ваш `ServiceEntry` потрібен лише для кількох робочих навантажень, обмежте його дію за допомогою `exportTo` або [`Sidecar`](/docs/reference/config/networking/sidecar/).

## Проксіювання DNS {#dns-proxying}

Istio пропонує функцію [поксіювання DNS-запитів](/docs/ops/configuration/traffic-management/dns-proxy/). Це дозволяє Istio перехоплювати DNS-запити, надіслані клієнтом, і безпосередньо відповідати на них.
Це може зменшити затримку DNS, знизити навантаження та дозволити резолюцію `ServiceEntry`, які інакше не були б відомі `kube-dns`.

Зверніть увагу, що це проксіювання застосовується лише до DNS-запитів, надісланих застосунками користувачів; коли використовується `ServiceEntry` типу `resolution: DNS`, проксі не впливає на DNS-резолюцію проксі Istio.