- Release Notes and Announcements
- Product Introduction
- Purchase Guide
- Getting Started
- Operation Guide
- FAQs
- Overview
- Permissions
- Pod Startup Fails Because the Envoy Sidecar Is Unready
- Envoy Converts Headers to Lowercase
- Headless Service-related FAQs
- Istio-init Crashes
- VirtualService Does Not Take Effect
- Inappropriate VirtualService Route Matching Order
- Failed to Access an Ingress Gateway from the Public Network
- Parsing Fails After Smart DNS Is Enabled
- Locality Load Balancing Does Not Take Effect
- Sidecars Are Not Automatically Injected
- Circuit Breaking Does Not Take Effect
- Service Is Abnormal Due to a Retry Policy
- Incomplete Call Tracing Information
- TCM Policy
- Glossary
- Release Notes and Announcements
- Product Introduction
- Purchase Guide
- Getting Started
- Operation Guide
- FAQs
- Overview
- Permissions
- Pod Startup Fails Because the Envoy Sidecar Is Unready
- Envoy Converts Headers to Lowercase
- Headless Service-related FAQs
- Istio-init Crashes
- VirtualService Does Not Take Effect
- Inappropriate VirtualService Route Matching Order
- Failed to Access an Ingress Gateway from the Public Network
- Parsing Fails After Smart DNS Is Enabled
- Locality Load Balancing Does Not Take Effect
- Sidecars Are Not Automatically Injected
- Circuit Breaking Does Not Take Effect
- Service Is Abnormal Due to a Retry Policy
- Incomplete Call Tracing Information
- TCM Policy
- Glossary
After Istio's smart DNS is enabled, DNS resolution fails in some cases. For example:
DNS resolution fails in a container created from an alpine image.
DNS resolution fails in a gRPC service.
Cause
There are some problems in the initial implementation of smart DNS. The format of a responded DNS packet is different from that of ordinary DNS. There is no problem when the underlying library glibc is used for resolution. However, resolution may fail if another DNS client is used.
The alpine image uses musl libc as its underlying library. The resolution behavior of musl libc is different from that of glibc. When the packet format is abnormal, musl libc may fail to resolve the packet. Most applications use the underlying library for resolution, which causes a resolution failure.
For services that use the c/c++ based gRPC framework, the c-ares library is used for DNS resolution by default, and the underlying library is not invoked for resolution. c-ares will fail to resolve the packet in some scenarios when the packet is abnormal.
Bug Fixing
Workaround Solution
If Istio cannot be upgraded to a version later than 1.9.2 temporarily, you can work around the problem by the following methods:
Change the base image from the alpine image to another image (underlying libraries of other base images are basically glibc).
Set the
GRPC_DNS_RESOLVER environment variable for the c/c++ based gRPC service to native. This setting indicates that the underlying library is used for resolution, not the default library c-ares. For description of environment variables, see the gRPC Documentation.
Yes
No
Was this page helpful?