Classic DNS round-robin distributes IP addresses under the same record roughly equally. That model may be adequate for simple load sharing, but it does not provide the control required for new-release rollouts, A/B testing, blue/green cutovers or data-centre migrations. Operations teams typically want to send only 5 % of traffic to a new destination and leave the rest on the existing system.
Without weighting at the DNS level, traffic splitting must be solved in the application tier or in a separate traffic-splitting layer. That means additional architecture, additional monitoring, additional certificate management and additional failure points. When the decision can instead be made in the DNS answer, the client is directed to the right destination from the very first query.
Maintenance and drain scenarios are also blunt when handled by deleting records. Removing an IP from a DNS record is effective for new queries, but it does not address the need to gradually reduce the traffic share or take a target out of rotation in a controlled way. Client and intermediate resolver cache behaviour over the TTL window must also be taken into account.
The right model is to assign a separate weight to each DNS record and choose the algorithm for the scenario. Weighted round-robin suits balanced, ordered distribution; weighted random provides statistical percentage-based selection. A weight of 0 places the target in effective drain mode, removing it from new DNS answers.
TR7 Weighted DNS delivers controlled traffic distribution at the DNS layer through per-record weights, weighted round-robin, weighted random, live configuration reload and weight=0 drain behaviour.
TR7 lifts the DNS answer out of a static record list and turns it into a traffic-distribution decision governed by weight values and selectable algorithms.
An integer weight is defined for each IP or record member. The weighted round-robin algorithm uses these weights to distribute DNS answers proportionally across the pool.
The weighted random algorithm performs a weight-proportional random selection on every query. At high query volumes, the observed traffic distribution converges toward the defined weight ratios.
Weight changes enter the live configuration reload pipeline and new queries immediately receive the updated distribution. Because previously cached answers live until their TTL expires, TTL planning is essential in fast-transition scenarios.
When a record's weight is set to 0, it is removed from the active candidate list. This behaviour provides controlled drain for maintenance, rollback or decommissioning of a data centre.
Weighted DNS manages per-record weight values together with algorithm selection, live updates, topology integration and maintenance scenarios.
In TR7, every record member can have its own weight value. This value determines its relative share of the traffic distribution — weights of 5 and 2 target a roughly 5:2 ratio. If a float is provided, it is rounded to an integer before use. The model makes it straightforward to give higher-capacity targets a larger share and test targets a smaller one.
Weighted round-robin selects records in rotation according to their weight ratios. It is the preferred choice when balanced distribution is expected and sequential use of records is acceptable. It is a practical algorithm for canary releases, gradual rollouts and capacity-proportional traffic sharing. Operators reshape the distribution simply by changing weight values.
Weighted random produces a weight-proportional random selection on every DNS query. Small deviations may appear over short time windows; at high query volumes the distribution converges toward the defined ratios. It is well suited to A/B testing and experimental traffic routing. New targets with a low weight can be safely trialled within the same record pool.
When weight values change, the GTM configuration enters the live reload process. A debounce mechanism coalesces rapid successive changes, reducing unnecessary re-renders; the typical live reload latency is around 3 seconds. New DNS queries receive the updated weight distribution. Previously cached answers in client and resolver caches remain until their TTL expires.
When a DNS weight changes, the system updates new answers immediately; however, DNS responses already issued live in intermediate caches until their TTL expires. For canary, blue/green or fast-rollback scenarios, TTL should be kept low. Values in the 5-60 second range allow transitions to take effect more quickly. A higher TTL is appropriate during stable operating periods.
When an IP or record member's weight reaches 0, that target is removed from new DNS answers. This makes it possible to drain a record for maintenance without deleting it. Existing cached responses continue to use the old answer until their TTL expires; new queries no longer receive the target. It is a controlled and reversible method for maintenance, rollback or data-centre decommissioning.
In TR7, distribution is not confined to a single IP level — data-centre group and record member weight logic can work in combination. The appropriate data centre or candidate group is selected first; records within that group are then distributed by weight. This model helps account for both capacity and location in global traffic management. In large deployments, distribution becomes more layered and manageable.
When geo or topology-based selection is in use, the appropriate candidate group is identified first. Weight distribution is then applied within that candidate set. European users, for example, are routed to the European data-centre group, while IPs within that group are weighted. The topology decision and the weight decision are applied sequentially without interfering with each other.
Records that do not require weighted distribution can use classic round-robin or random selection. Round-robin distributes records equally; random selects at random. These algorithms are sufficient for simple scenarios and are managed through the same record model, so switching to weighted algorithms requires no structural changes. Operators choose the appropriate distribution behaviour for each DNS record.
The closest algorithm is available for A and AAAA records that require IP-proximity selection. Unlike weighted distribution, it focuses on selecting the nearest or most appropriate target for the client. Topology, closest and weight can serve as distinct decision layers in global traffic management. The result is a DNS answer that is context-aware rather than merely random.
Weighted DNS is operated together with weight format, algorithm selection, live reload latency, TTL impact and record selection behaviour.
Weight is defined as a number and used as an integer. If a float is provided it is rounded. Weight ratios represent relative shares among records, not absolute percentages.
Weighted round-robin and weighted random algorithms use the record list together with a weight map. Indexed weight values are generated for each record. This structure is evaluated by the selector function during DNS answer generation.
Configuration changes pass through a debounced live reload process. The typical debounce value is 3 seconds; a maximum wait limit can be applied during bursts of rapid successive changes. This behaviour reduces unnecessary frequent re-render operations.
A weight change takes effect on new DNS queries. Clients or resolvers that already received a previous answer continue using the cached record until its TTL expires. For this reason, TTL is as important an operational parameter as weight when planning transitions.
Weight 0 is used to remove a record from the active candidate list. This makes it possible to perform maintenance or migration without fully deleting the record. To reinstate the record, set the weight back to a positive value.
In certain scenarios, a number can be provided instead of an algorithm to select the first N records from the candidate list. This behaviour is useful for simple, deterministic record limiting. It is a practical option for special cases where weighted distribution is not required.
The new-release IP receives a low weight; the current release receives a high weight. The new version starts at roughly 5 % of traffic; as metrics look healthy, the weight is raised incrementally. If a problem appears, the new release is drained by setting its weight to 0.
While the blue environment is active, the green environment is tested at a low weight. At cutover, blue's weight is reduced to 0 and green becomes the sole active target. When a rollback is needed, the weights are reversed to return to the previous environment.
Two landing pages or two service variants are defined with separate IP records. Weights can be set 1:1 for an equal test or 9:1 for a limited experiment. Based on result analysis, the traffic ratio is adjusted at the DNS level.
The old data centre starts at a high weight; the new data centre is introduced at a low weight. The operations team shifts traffic to the new centre through a stepped reduction such as 100 → 80 → 50 → 20 → 0. When TTL is kept low, the impact of each step is observed more quickly.
Higher-capacity backends receive a higher weight; more constrained resources receive a lower weight. The traffic distribution becomes proportional to server capacity. Operators reshape the distribution purely by updating weight values.
The weight of the backend being taken into maintenance is reduced to 0. New DNS queries no longer route to that target; previously cached answers continue to be used until their TTL expires. When maintenance is complete, the weight is restored to a positive value and the backend re-enters service.
Per-record weights and live reload for canary releases, blue/green cutovers, A/B tests and data-centre migrations. Let's walk through a live setup in your environment.