Understanding DNS

This document describes low level implementation details. For a higher level overview, check out the traffic management Concepts or pages.

In these examples, we will walk through what happens when an application runs . While curl is used here, the same applies to almost all clients.

When you send a request to a domain, a client will do DNS resolution to resolve that to an IP address. This happens regardless of any Istio settings, as Istio only intercepts networking traffic; it cannot change your application’s behavior or decision to send a DNS request. In the example below, example.com resolved to 192.0.2.0.

If the client was unable to resolve the DNS request, the request would terminate before Istio receives it. This means that if a request is sent to a hostname which is known to Istio (for example, by a VirtualService) but not to the DNS server, the request will fail. Istio can change this behavior.

Once Istio has identified the intended destination, it must choose which address to send to. Because of Istio’s advanced load balancing capabilities, this is often not the original IP address the client sent. Depending on the service configuration, there are a few different ways Istio does this.

• Use the original IP address of the client (192.0.2.0, in the example above). This is the case for ServiceEntry of type (the default) and .
• Load balance over a set of static IP addresses. This is the case for ServiceEntry of type resolution: STATIC, where all spec.endpoints will be used, or for standard Services, where all Endpoints will be used.

Note that in all cases, DNS resolution within the Istio proxy is orthogonal to DNS resolution in a user application. Even when the client does DNS resolution, the proxy may ignore the resolved IP address and use its own, which could be from a static list of IPs or by doing its own DNS resolution (potentially of the same hostname or a different one).

For meshes with many proxies or many resolution: DNS type ServiceEntries, especially when low TTLs are used, this may cause a high load on DNS servers. In these cases, the following can help reduce the load:

• Switch to resolution: NONE to avoid proxy DNS lookups entirely. This is suitable for many use cases.
• If you control the domains being resolved, increase their TTL.

Istio offers a feature to proxy DNS requests. This allows Istio to capture DNS requests sent by the client and return a response directly. This can improve DNS latency, reduce load, and allow ServiceEntries, which otherwise would not be known to kube-dns, to be resolved.

Note this proxying only applies to DNS requests sent by user applications; when type ServiceEntries are used, the proxy has no impact on the DNS resolution of the Istio proxy.