diff --git a/dev_guide/secrets.adoc b/dev_guide/secrets.adoc
index 6ed6efd98ab9..254d2facea6b 100644
--- a/dev_guide/secrets.adoc
+++ b/dev_guide/secrets.adoc
@@ -130,15 +130,23 @@ See xref:builds.adoc#source-secrets[Source Secrets] for more information.
 
 To secure communication to your service, have the cluster generate a signed
 serving certificate/key pair into a secret in your namespace. To do this, set
-the `*service.alpha.openshift.io/serving-cert-secret-name*` to the name you want
+the `service.alpha.openshift.io/serving-cert-secret-name` to the name you want
 to use for your secret. Then, your *PodSpec* can mount that secret. When it is
 available, your pod will run. The certificate will be good for the internal
-service DNS name, `*<service.name>.<service.namespace>.svc*`. The certificate
-and key are in PEM format, stored in `*tls.crt*` and `*tls.key*` respectively.
+service DNS name, `<service.name>.<service.namespace>.svc`. The certificate
+and key are in PEM format, stored in `tls.crt` and `tls.key` respectively.
 They are regenerated upon expiration. View the expiration date in the
-`*service.alpha.openshift.io/expiry*` annotation on the secret, which is in
+`service.alpha.openshift.io/expiry` annotation on the secret, which is in
 RFC3339 format.
 
+[NOTE]
+====
+In most cases, the service DNS name
+`<service.name>.<service.namespace>.svc` is not externally routable. The
+primary use of `<service.name>.<service.namespace>.svc` is for intracluster or
+intraservice communication, and with re-encrypt routes.
+====
+
 Other pods can trust cluster-created certificates (which are only signed for
 internal DNS names), by using the CA bundle in the
 *_/var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt_* file that is