Introducing New WhoAmI Tool DNS Resolver Information
The Domain Name System (DNS) tools “whoami.akamai.net” and its alias “whoami.akamai.com” have been used for many years, often as a step in the process for diagnosing how a content delivery network (CDN) is directing traffic, locality, and network reachability issues. Whoami was originally introduced as a quick solution that, as often happens, ended up sticking around for far longer than expected.
Now we're slightly modifying its function by adding support for the modern internet (IPv6 and ECS), and moving whoami over to its own domain. If you’re a user of the legacy whoami names, you should start your migration to the new names below to prevent interruptions.
I'll go into this in more detail below, but if you're familiar with whoami, you would typically do this:
dig +short A whoami.akamai.net
Note: dig, if you're not familiar with it, is short for "domain information groper" and is a network administration command-line tool for querying Domain Name System servers.
But now with the new whoami tool, you'll do it like this:
dig +short TXT whoami.ds.akahelp.net
How it works
The DNS acts like a phone book for the Internet. When a client wants to look up (“resolve”) the address records for a name such as “www.example.com” it typically has a piece of software called a “stub resolver” that talks to a DNS “recursive resolver”.
The recursive resolver may be operated by an internet service provider (ISP), enterprise network, a public resolver service (such as GoogleDNS, OpenDNS, Quad9, etc.), or through a service such as Akamai’s Secure Internet Access Enterprise or AnswerX Managed. Sometimes there are one or more forwarding resolvers (such as “dnsmasq” running on a home router) in between the stub resolver and the recursive resolver.
The recursive resolver then makes connections out to DNS authoritative nameservers ("authorities"). Akamai's Fast DNS product is an example of an authoritative nameserver. Recursive resolvers start at the root authorities and follow referrals delegating responsibility to a zone lower in the hierarchy until they reach an authority that can provide the answer for the DNS name being requested.
In the example below, the resolver starts at the root authorities; every DNS name has an implicit "." at the end indicating the root. They delegate to the authorities for ".com", which delegate to the authorities for "example.com", which then finally hand out the address records for "www.example.com".
While the client knows which forwarding resolver or recursive resolver it’s talking to, it doesn’t know which IP address the recursive resolver is using to talk to the authorities, nor does it know what EDNS0 Client Subnet Extension (ECS) information the recursive resolver may be passing along. Recursive resolvers will also often talk to authorities over a different IP version (IPv4 vs IPv6) than that used by the client. For many recursive resolvers, the address that clients use to speak to them will be anycast, but they will use a local unicast address for issuing queries.
The DNS authorities for many CDNs such as Akamai (as well as other systems filling functions such as global traffic management and request routing) will often use both the DNS source address of the DNS recursive resolver, as well as ECS data passed along that may provide better information about client location, as inputs into deciding where to direct traffic.
For example, some systems will hand out different CNAMEs based on country-level IP-Geo information, while others will direct clients to a nearby server cluster. As such, getting information about the recursive resolver source addresses (and ECS usage) can be helpful when looking to tune or troubleshoot issues such as a sub-optimal mapping by a CDN.
Introducing akahelp.net
The new resolver diagnostic tools we're introducing in place of whoami.akamai.net and whoami.akamai.com are:
Dual Stack (recursive resolver chooses the protocol): whoami.ds.akahelp.net
Force recursion over IPv6 (when available): whoami.ipv6.akahelp.net
Force recursion over IPv4: whoami.ipv4.akahelp.net
Like the old whoami.akamai.net, each of these new domains provides the unicast IP address of the recursive resolver that queried the akahelp.net authoritative name server.
Both domains now also include the EDNS0 End User Client Subnet (ECS, RFC7871) information as seen by the authoritative name server, when it is present for queries to akahelp.net. These names respond only to TXT record queries.
Reading the results
Unlike the old whoami.akamai.net and whoami.akamai.com, the akahelp.net names will only respond to TXT record queries. Below is example output from running a dig command using a new whoami domain:
# dig +short TXT whoami.ds.akahelp.net
"ns" "2001:db8::abcd"
"ecs" "203.0.113.0/24/0"
"ip" "203.0.113.132"
In the response, the record labeled "ns" is the unicast IP address of the requesting recursive resolver. It may be IPv4 or IPv6. Note that some recursive resolvers are clusters with multiple servers, each with their own IPs. Some resolvers may also conditionally use IPv4 and/or IPv6, hence the value in doing queries against all of “.ds.”, “.ipv4.”, and “.ipv6.”.
Two additional records may also appear if the recursive resolver sends ECS information along with the query. The "ecs" record is the ECS client subnet included in the query. The "ip" record is a representative ip address selected at random by Akamai’s authoritative nameserver from the ECS client subnet. (Recursive resolvers don’t send the actual client IP they observe, in order to reduce the privacy impacts of ECS.)
Querying on windows
Below is an example using nslookup on a Windows machine to do the same query:
C:\Users\Username>nslookup -type=TXT whoami.ds.akahelp.net Server: recursive-dns.example.com Address: 2001:DB8::1000:1
Non-authoritative answer: whoami.ds.akahelp.net text = “ns” “198.51.100.1” whoami.ds.akahelp.net text = “ecs” “2001:DB8:2000::/56/0” whoami.ds.akahelp.net text = “ip” “2001:DB8:2000::BD85:3240:D2B3”
Offered as-is
Like with whoami.akamai.net, the new akahelp.net domains are offered to the general public as a best-effort service. At this time these names are used for debugging both internal and external issues, so Akamai currently has a vested interest in maintaining them, and we would love to have your help in this effort. If you run into issues or would like to report outages, please contact us via https://community.akamai.com or through Akamai support.
The future of whoami.akamai.net and whoami.akamai.com
An end-of-life date for whoami.akamai.net and whoami.akamai.com has not been set at this time, but we expect that it will be decommissioned within the next 12 months. We hope that the new akahelp.net tool will be useful to users of the legacy whoami.
