diff --git a/sig-scalability/slos/dns_programming_latency.md b/sig-scalability/slos/dns_programming_latency.md
index d2844af33..9e2482ab5 100644
--- a/sig-scalability/slos/dns_programming_latency.md
+++ b/sig-scalability/slos/dns_programming_latency.md
@@ -15,8 +15,10 @@ from all of them.
 DNS will start resolving service name to its newly started backends.
 - As a user of vanilla Kubernetes, I want some guarantee how quickly in-cluster
 DNS will stop resolving service name to its removed (or unhealthy) backends.
-- As a user of vanilla Kubernetes, I wasn some guarantee how quickly newly
+- As a user of vanilla Kubernetes, I want some guarantee how quickly newly
 create services will be resolvable via in-cluster DNS.
+- As a user of vanilla Kubernetes, I want some guarantee how quickly in-cluster
+DNS will start resolving headless service hostnames to its newly started backends.
 
 ### Other notes
 - We are consciously focusing on in-cluster DNS for the purpose of this SLI,
@@ -37,6 +39,12 @@ The reason for doing it this way is feasibility for efficiently computing that:
     in 99% of programmers (e.g. iptables). That requires tracking metrics on
     per-change base (which we can't do efficiently).
 
+- The SLI for DNS publishing should remain constant independent of the number of records.
+For example, in a headless service with thousands of pods the time between the pod being
+assigned an IP and the time DNS makes that IP available in the service's A/AAAA record(s)
+should be statisitically consistent for the first Pod and the last Pod.
+
+
 ### How to measure the SLI.
 There [network programming latency](./network_programming_latency.md) is
 formulated in almost exactly the same way. As a result, the methodology for