| Internet-Draft | DNS Answer Generation | July 2025 |
| Kerr | Expires 21 January 2026 | [Page] |
The traditional model for DNS is that authoritative servers would read DNS data from static zone files and use that to answer DNS queries. Modern DNS servers do not act in this way, and their answers are created dynamically - either periodically or at query time.¶
This document presents a taxonomy breaking down the most common and useful methods used to customize responses on the authortiative side, as well as a survey of implementations by current large authoritative operators.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 21 January 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
Many DNS authoritative servers have features to provide a different answer for the same DNS query.¶
For example, one user querying the AAAA record for www.example.org
might get 2001:db8:1111::42 and another user querying the same
record might get 2001:db8:9999::11. The DNS recursive resolver for
each will cache the record normally, and the user's software will
connect to different servers at different locations. The goal is to
give the user a "better" answer, by whatever metric the operator is
using; this can be latency, cost, adherence to regulations, or
anything else.¶
DNS was not designed with this kind of responses in mind, and there are no standard ways to represent this data. This makes inter-operable systems difficult or impossible to build.¶
While there are a wide variety of ways that DNS authoritative servers modify or generate answers, most of those fall into a few categories. This section presents a taxonomy of such answers.¶
For each type of generated or modified answer we briefly describe:¶
In the DNS protocol the CNAME record type is special, and used to indicate that a name can be resolved at some other name. This is not possible at the apex of a zone (the "top" of a zone), because a CNAME cannot appear at the same name as another type, and both the SOA and NS types must appear at the zone apex.¶
A common solution is to do the equivalent of CNAME referral processing but on the authoritative side. This is often called an ALIAS record, but other names exist. Basically the authoritative server will do a lookup at the ALIAS target, acting as a client, and return the record there. This always includes address types (A and AAAA), although the details of exactly how this works will vary.¶
Configuration: The record is usually configured with the DNS name of the target, although other configuration might exist, for example specified behavior on failure or TTL behavior.¶
Data: The "data" for this type of response is the result of a DNS query.¶
The idea with GeoIP is to provide different answers depending on the IP address of the client, with the hope that the IP address provides a good hint at the physical location of the end user or system. This is not always true, but is good enough for many purposes.¶
Additionally, ECS (EDNS Client Subnet) is often used to provide more information about the IP address of the end user or system, which is useful for resolvers that are using IP addresses in different physical locations from the users.¶
Typical reasons to provide different answers include:¶
Better performance for users by sending them to servers closer to where they are located.¶
Attempting to meet legal requirements, such as blocking access to certain regions (for example due to gambling restrictions) or ensuring that traffic stays within specific borders (for example to avoid tariffs).¶
Sometimes instead of using the IP address directly, these may be mapped to an ASN (BGP Autonomous System Number). In a similar way that IP is used as a proxy for geographical location, ASN can be used as a proxy for the originating ISP (Internet Service Provider).¶
Configuration: Configuration will vary, but usually involves specifying a country or region associated with answers. It may also involve distance, for example choosing the answer closest to data centers of a service.¶
Data: The mapping of IP to geographic location (or other type of location) needs to be updated as IP addresses are transferred between organizations or used by an organization in different sites.¶
Within a single site some sort of load balancer can perform health checks on back-end servers and route traffic depending on their availability. For doing this across the Internet this is often done using the DNS; this technique is sometimes called Global Server Load Balancing (GLSB), DNS Server Load Balancing (DSLB) or just DNS Load Balancing (DLB).¶
The details of what the authoritative server will return vary. For example, the simplest case would be a service that returns one IP address when a health check is successful, and a different IP address otherwise. A more complicated case could be with pools of IP addresses, and the answer generated based on regional load metrics.¶
Configuration: In many cases the configuration can be quite simple, such as when a standby server is defined. If load or other factors are used to define availability, then the configuration can be arbitrarily complicated.¶
Data: The data about availability needs to be updated frequently, and may be something that organizations keep private. Cloud providers often have a rich set of availability information provided automatically by hosted services they operate.¶
The goal of traffic steering is to provide low latency, optimize for cost, or other network-related characteristics of a service.¶
Traffic steering is similar to service availability, but is used to alter responses based on the conditions of the network rather than conditions of the services themselves. Real-User Measurements (RUM) fall under this category; RUM is the ideal state, but the costs of obtaining, maintaining, and distributing RUM may be more than the benefits provided.¶
In contrast with availability checks, traffic steering is not about the status of systems under the control of the service operator, but about the Internet or possibly large systems not under their direct control, like Content-Delivery Networks (CDN) or transit network providers. While traffic steering requires more measurement points, and the networks being measured are not under direct control of the system operators, the modifications of DNS responses are similar.¶
Configuration: The source of information about the network is configured, as well as they type of transformation that is done on answers. The pool of answers might be configured, or it may be generated data as well.¶
Data: The measurements of network characteristics is typically proprietary information. For some services simple checks from a few points will be enough, although even in those cases organizations will often pay for distributed measurement networks. In other cases measurements will be provided by vendors, often the DNS provider themselves.¶
Any server-side processing imaginable is done somewhere. This includes anything from delivering weather reports to TXT-based traceroute information. For example:¶
Configuration: Anything from no configuration at all to Lua scripts as DNS records.¶
Data: Everything is data if you try hard enough.¶
The DNS includes a Time-To-Live (TTL) value which specifies the maximum time that a system is allowed to use a value. Systems do not have to use the value for that long - often a maximum of 1 day or even shorter is used. There is no minimum TTL in DNS, although many systems reject TTL that are too short.¶
A long TTL reduces load throughout all components in the DNS, and also reduces the impact of outages or other problems looking up DNS records. However, systems that modify or generate answers may need to respond to rapidly-changing conditions. CDN often use TTL of 1 minute or less.¶
In order to try to understand what the proprietary capabilities are in this space, a survey of some current authoritative DNS vendors was undertaken. This was not chosen based on science or data, although the largest players in this space are represented.¶
IBM NS1 Connect has a couple of custom record types, ALIAS and REDIRECT.¶
They have a special zone type called a linked zone, which maps the entire contents of one zone to another zone name. It does this without DNS lookups, so is limited to IBM NS1 Connect customers.¶
They have a special record type called a linked record, which is similar to a linked zone, but for a single record.¶
They have "filter chains" which provide special processing based on:¶
Any number of filter chains can be used on a record to answer queries. Results are always on the same DNS type and name, and result codes cannot be modified.¶
UltraDNS has a couple of custom record types, Apex Alias and Web Forwarding.¶
UltraDNS has something called a Pool, which combines specific records which work with specific checks. These are:¶
DNS Made Easy has a couple of custom record types, ANAME and HTTP redirect types.¶
They have a monitoring/failover solution.¶
Their upscale product, Constellix, also supports weighted round-robin load balancing and GeoDNS (including custom IP rules).¶
Route 53 has an alias record types.¶
You can specify an address record just by the service, rather than an IP address.¶
Route 53 has "routing" in the DNS, based on:¶
Azure has an alias record, which updates automatically for Azure data. The alias record can point to several types of automatically configured data, including applications and Traffic Manager, but also CDN endpoints. It does not seem to be able to alias to non-Azure DNS names.¶
Traffic Manager does support tracking hosts outside of Azure, either by IP address or FQDN. It include "endpoint monitoring", which is looking at HTTP/HTTPS/TCP endpoints. It also includes RUM.¶
Google Cloud DNS has a couple of custom types, ALIAS and IPSECVPNKEY.¶
There does not seem to be a way to provide custom responses.¶
Akamai has alias zones, which are a bit like ALIAS records but for the whole zone.¶
Akamai has zone apex mapping via the AKAMAICDN record type, which is a bit like ALIAS records.¶
Cloudflare supports CNAME flattening, which is similar to ALIAS records. The server will resolve the CNAME target and return it directly.¶
Jan Vcelak reviewed the text, correcting errors and providing additional information about advanced features of some vendors.¶