



Network Working Group                                            S. Kerr
Internet-Draft                                                       IBM
Intended status: Informational                              20 July 2025
Expires: 21 January 2026


            Authoritative DNS Server-Side Answer Generation
                 draft-kerr-auth-dns-server-ans-gen-00

Abstract

   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.

Status of This Memo

   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 Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.








Kerr                     Expires 21 January 2026                [Page 1]

Internet-Draft            DNS Answer Generation                July 2025


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Taxonomy  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  CNAME-at-Apex (ALIAS) . . . . . . . . . . . . . . . . . .   3
     2.2.  GeoIP . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Service Availability  . . . . . . . . . . . . . . . . . .   4
     2.4.  Traffic Steering  . . . . . . . . . . . . . . . . . . . .   5
     2.5.  Everything Else . . . . . . . . . . . . . . . . . . . . .   6
   3.  Other Considerations  . . . . . . . . . . . . . . . . . . . .   6
     3.1.  TTL Trade-Offs  . . . . . . . . . . . . . . . . . . . . .   6
   4.  Survey of Some DNS Vendors  . . . . . . . . . . . . . . . . .   6
     4.1.  Enterprise Managed DNS Vendors  . . . . . . . . . . . . .   6
       4.1.1.  IBM NS1 Connect . . . . . . . . . . . . . . . . . . .   7
       4.1.2.  UltraDNS  . . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Consumer Managed DNS Vendors  . . . . . . . . . . . . . .   8
       4.2.1.  DNS Made Easy . . . . . . . . . . . . . . . . . . . .   8
       4.2.2.  dnsimple  . . . . . . . . . . . . . . . . . . . . . .   8
     4.3.  Cloud Vendors . . . . . . . . . . . . . . . . . . . . . .   8
       4.3.1.  AWS Route 53  . . . . . . . . . . . . . . . . . . . .   8
       4.3.2.  Azure DNS . . . . . . . . . . . . . . . . . . . . . .   9
       4.3.3.  Google Cloud DNS  . . . . . . . . . . . . . . . . . .   9
     4.4.  CDN/Hosting Vendors . . . . . . . . . . . . . . . . . . .   9
       4.4.1.  Akamai Edge DNS . . . . . . . . . . . . . . . . . . .   9
       4.4.2.  Cloudflare  . . . . . . . . . . . . . . . . . . . . .   9
     4.5.  Registrars  . . . . . . . . . . . . . . . . . . . . . . .   9
       4.5.1.  GoDaddy Premium DNS (Akamai)  . . . . . . . . . . . .   9
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Many DNS authoritative servers have features to provide a different
   answer for the same DNS query.











Kerr                     Expires 21 January 2026                [Page 2]

Internet-Draft            DNS Answer Generation                July 2025


   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.

2.  Taxonomy

   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:

   *  Configuration, which is roughly static

   *  Data, which is relatively dynamic

2.1.  CNAME-at-Apex (ALIAS)

   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.





Kerr                     Expires 21 January 2026                [Page 3]

Internet-Draft            DNS Answer Generation                July 2025


2.2.  GeoIP

   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) (https://www.rfc-
   editor.org/rfc/rfc7871) 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.

2.3.  Service Availability

   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).






Kerr                     Expires 21 January 2026                [Page 4]

Internet-Draft            DNS Answer Generation                July 2025


   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.

2.4.  Traffic Steering

   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.




Kerr                     Expires 21 January 2026                [Page 5]

Internet-Draft            DNS Answer Generation                July 2025


2.5.  Everything Else

   Any server-side processing imaginable is done somewhere.  This
   includes anything from delivering weather reports to TXT-based
   traceroute information.  For example:

   *  Allow different types of server-side generation or modification to
      be used together.

   *  Weight responses, to split load unevenly.

   *  Map contents of one zone or record to another at runtime.

   *  Generate IP6.ARPA and IN-ADDR.ARPA responses based on AAAA or A
      records.

   Configuration: Anything from no configuration at all to Lua scripts
   as DNS records.

   Data: Everything is data if you try hard enough.

3.  Other Considerations

3.1.  TTL Trade-Offs

   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.

4.  Survey of Some DNS Vendors

   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.

4.1.  Enterprise Managed DNS Vendors






Kerr                     Expires 21 January 2026                [Page 6]

Internet-Draft            DNS Answer Generation                July 2025


4.1.1.  IBM NS1 Connect

   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:

   *  Geographic (country, region, latitude/longitude)

   *  Network (ASN or IP prefix)

   *  Health check-based (load, up/down)

   *  Traffic-steering (shuffle in various flavors, priority, pick N)

   *  "Pulsar" (RUM-based)

   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.

4.1.2.  UltraDNS

   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:

   *  Resource Distribution (RD): a group of A/AAAA records

   *  SiteBacker (SB): A or CNAME that monitors backend service with a
      redirect to another service on outage

   *  Traffic Controller (TC): SB as a Global Server Load Balancing
      solution

   *  Simple Load Balancing (SLB): A/AAAA records, an HTTP monitor, and
      a backup

   *  Simple Failover (SF): simple monitoring with failover



Kerr                     Expires 21 January 2026                [Page 7]

Internet-Draft            DNS Answer Generation                July 2025


   *  Directional (DIR): using GeoIP to determine response

4.2.  Consumer Managed DNS Vendors

4.2.1.  DNS Made Easy

   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).

4.2.2.  dnsimple

   dnsimple has a few proprietary types, ALIAS, POOL, and URL.

   The POOL type picks a single CNAME from a set of CNAME.

4.3.  Cloud Vendors

4.3.1.  AWS Route 53

   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:

   *  Simple; NS are only supported via this policy

   *  Geoproximity; either AWS region/local zone group (with bias
      setting), or latitude/longitude

   *  Latency; includes optional health check

   *  IP address (of the end user); CIDR /24 (IPv4) or /32 (IPv6); "CIDR
      collections"

   *  Geolocation; IP to location mapping; if no default -> "no answer"
      on miss (NXDOMAIN?  NODATA?); EDNS0 supported

   *  Failover; based on AWS health checkers

   *  Multivalue; health check for backend services




Kerr                     Expires 21 January 2026                [Page 8]

Internet-Draft            DNS Answer Generation                July 2025


   *  Weighted routing; distribute load proportionally

4.3.2.  Azure DNS

   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.

4.3.3.  Google Cloud DNS

   Google Cloud DNS has a couple of custom types, ALIAS and IPSECVPNKEY.

   There does not seem to be a way to provide custom responses.

4.4.  CDN/Hosting Vendors

4.4.1.  Akamai Edge DNS

   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.

4.4.2.  Cloudflare

   Cloudflare supports _CNAME flattening_, which is similar to ALIAS
   records.  The server will resolve the CNAME target and return it
   directly.

4.5.  Registrars

4.5.1.  GoDaddy Premium DNS (Akamai)

   GoDaddy does not seem to have any special server-side record
   processing.

Appendix A.  Acknowledgments

   Jan Vcelak reviewed the text, correcting errors and providing
   additional information about advanced features of some vendors.




Kerr                     Expires 21 January 2026                [Page 9]

Internet-Draft            DNS Answer Generation                July 2025


Author's Address

   Shane Kerr
   IBM
   Johan Huizingalaan 765
   1066 VH Amsterdam
   Netherlands
   Email: shane.kerr@ibm.com











































Kerr                     Expires 21 January 2026               [Page 10]
