diff --git a/docs/admin/dns.md b/docs/admin/dns.md
index df34fbf8a9..c56fc5b89b 100644
--- a/docs/admin/dns.md
+++ b/docs/admin/dns.md
@@ -31,9 +31,13 @@ performance. The healthz container provides a single health check endpoint while
 
 ## Kubernetes Federation (Multiple Zone support)
 
-The 1.3 release introduced Federation (Ubernetes) support for multisite Kubernetes installations. There are
-DNS changes introduced that will allow the lookup of services using a six part DNS name.
-See [Federation docs](/docs/admin/multiple-zones/) for more details on multiple site support.
+Release 1.3 introduced Cluster Federation support for multi-site
+Kubernetes installations. This required some minor
+(backward-compatible) changes to the way
+the Kubernetes cluster DNS server processes DNS queries, to facilitate
+the lookup of federated services (which span multiple Kubernetes clusters).
+See the [Cluster Federation Administrators' Guide](/docs/admin/federation/index.md) for more
+details on Cluster Federation and multi-site support.
 
 ## References
 
diff --git a/docs/admin/multiple-zones.md b/docs/admin/multiple-zones.md
index f3378069d6..68383ea003 100644
--- a/docs/admin/multiple-zones.md
+++ b/docs/admin/multiple-zones.md
@@ -5,14 +5,14 @@
 
 Kubernetes 1.2 adds support for running a single cluster in multiple failure zones
 (GCE calls them simply "zones", AWS calls them "availability zones", here we'll refer to them as "zones").
-This is a lightweight version of a broader effort for federating multiple
-Kubernetes clusters together (sometimes referred to by the affectionate
+This is a lightweight version of a broader Cluster Federation feature (previously referred to by the affectionate
 nickname ["Ubernetes"](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/federation.md).
-Full federation will allow combining separate
-Kubernetes clusters running in different regions or clouds.  However, many
+Full Cluster Federation allows combining separate
+Kubernetes clusters running in different regions or cloud providers
+(or on-premise data centers).  However, many
 users simply want to run a more available Kubernetes cluster in multiple zones
-of their cloud provider, and this is what the multizone support in 1.2 allows
-(we nickname this "Ubernetes Lite").
+of their single cloud provider, and this is what the multizone support in 1.2 allows
+(this previously went by the nickname "Ubernetes Lite").
 
 Multizone support is deliberately limited: a single Kubernetes cluster can run
 in multiple zones, but only within the same region (and cloud provider).  Only