When I do
dig whoami.akamai.net AAAA on my computer, I got
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32160 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;whoami.akamai.net. IN AAAA
But if I try from @18.104.22.168 or @22.214.171.124 or even OpenDNS, I can get a AAAA RR.
What prevent my local dig not to get a result?
According to the RFC4074 (https://tools.ietf.org/html/rfc4074#section-3):
Suppose that an authoritative server has an A RR but has no AAAA RR
for a host name. Then, the server should return a response to a query
for an AAAA RR of the name with the response code (RCODE) being 0
(indicating no error) and with an empty answer section (see Sections
4.3.2 and 6.2.4 of RFC 1034). Such a response indicates that there is at least one RR of a different type than AAAA for the queried name, and
the stub resolver can then look for A RRs.
I thought it was what happening, but it looks like the domain has an existing AAAA record (since the major dns resolver have it). I do not get what is happening here.
Akamai is a very large CDN and as such it uses geographically split DNS, so that DNS queries will (at least most of the time) return an IP address that is close to the user on the network. But that’s not what is happening here.
whoami.akamai.net is a special tool. Its purpose is to return the IP address of the DNS server that sent the DNS request to Akamai’s authoritative nameservers.
It is also deprecated and if this is a tool you rely on, you should move to its replacement.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.