DualStack headless DNS behavior

kubernetes · Feb 4, 2020 · 8101701 · 8101701
1 parent 7b467a9
commit 8101701
Showing 1 changed file with 8 additions and 6 deletions.
diff --git a/keps/sig-network/20180612-ipv4-ipv6-dual-stack.md b/keps/sig-network/20180612-ipv4-ipv6-dual-stack.md
@@ -50,7 +50,7 @@ status: implementable
     - [Kube-Proxy Startup Configuration Changes](#kube-proxy-startup-configuration-changes)
       - [Multiple bind addresses configuration](#multiple-bind-addresses-configuration)
       - [Multiple cluster CIDRs configuration](#multiple-cluster-cidrs-configuration)
-  - [CoreDNS Operation](#coredns-operation)
+  - [DNS Operation](#dns-operation)
   - [Ingress Controller Operation](#ingress-controller-operation)
     - [GCE Ingress Controller: Out-of-Scope, Testing Deferred For Now](#gce-ingress-controller-out-of-scope-testing-deferred-for-now)
     - [NGINX Ingress Controller - Dual-Stack Support for Bare Metal Clusters](#nginx-ingress-controller---dual-stack-support-for-bare-metal-clusters)
@@ -401,13 +401,15 @@ A new [kube-proxy configuration](https://kubernetes.io/docs/reference/command-li
 ```
 Only the first CIDR for each IP family will be used; all others will be ignored.
 
-### CoreDNS Operation
+### DNS Operation
 
-CoreDNS will need to make changes in order to support the plural form of endpoint addresses. Some other considerations of CoreDNS support for dual-stack:
+DNS will need to support the plural form of endpoint addresses and the [Kubernetes DNS specification](https://github.com/kubernetes/dns/blob/master/docs/specification.md). Some other considerations of DNS support for dual-stack:
 
-- Because service IPs will remain single-family, pods will continue to access the CoreDNS server via a single service IP. In other words, the nameserver entries in a pod's /etc/resolv.conf will typically be a single IPv4 or single IPv6 address, depending upon the IP family of the cluster's service CIDR.
-- Non-headless Kubernetes services: CoreDNS will resolve these services to either an IPv4 entry (A record) or an IPv6 entry (AAAA record), depending upon the IP family of the cluster's service CIDR.
-- Headless Kubernetes services: CoreDNS will resolve these services to either an IPv4 entry (A record), an IPv6 entry (AAAA record), or both, depending on the service's `ipFamily`.
+- Because service IPs will remain single-family, pods will continue to access the DNS server via a single service IP. In other words, the nameserver entries in a pod's /etc/resolv.conf will typically be a single IPv4 or single IPv6 address, depending upon the IP family of the cluster's service CIDR.
+- Non-headless Kubernetes services: DNS will resolve these services to either an IPv4 entry (A record) or an IPv6 entry (AAAA record). The endpoints are autogenerated from the pods associated to the service, filtered by the IP family of the service, they will resolve accordenly.
+- Headless Kubernetes services with selectors: the endpoints controller creates Endpoints records in the API, and modifies the DNS configuration to return records (addresses) that point directly to the Pods backing the Service. It will generate IPv4 entries (A records) or IPv6 entries (AAAA record), depending on the field `ipFamily`. If `ipFamily` is nil it defaults to IPv4.
+- Headless Kubernetes services without selectors: will generate IPv4 entries (A records) or IPv6 entries (AAAA record), depending on the field `ipFamily`, based on the endpoints that share a name with the service. If the `ipFamily` of the service is nil it may generate both A and AAAA.
+- ExternalName services will generate a CNAME record, so the IP family doesn't apply to them.
 
 ### Ingress Controller Operation