Looks to me that they simply did not update their domain on the TLD servers when their authoritative servers changed. They are using Route 53 I presume?
Edit: I overlooked that in second query was for second level domain. This is normal if the first level domain has different name servers than the second. There's still an not optimal part though, on the second lookup it returns authoritative name servers but without glue record (i.e. it does not list IPs of those servers) so the client has to resolve them themselves, which could add few more extra lookups.
This is normal behavior. The .net root server gives you the authoritative name servers for cloudfront.net, and cloudfront.net's name server gives you the name servers for your CloudFront subdomain. Most users will do lookups through their ISPs' recursive resolvers, so they'll get a cached response in a single round trip from there instead of doing the full 3-level resolution starting from the root.
In theory, Amazon could serve the A-records out of the cloudfront.net zone. Practically though, there are other factors like the dynamic nature of CDNs, the massive size of a zone containing records for all of the CloudFront subdomains, and the aforementioned ISP caching resolvers that preclude such an approach.
Interesting. Did not think about ISP caching resolvers having to deal with massive zones. But a TTL of just 1831 in the second delegation sounds too low.
4 comments
[ 3.4 ms ] story [ 20.9 ms ] threadEdit: I overlooked that in second query was for second level domain. This is normal if the first level domain has different name servers than the second. There's still an not optimal part though, on the second lookup it returns authoritative name servers but without glue record (i.e. it does not list IPs of those servers) so the client has to resolve them themselves, which could add few more extra lookups.
In theory, Amazon could serve the A-records out of the cloudfront.net zone. Practically though, there are other factors like the dynamic nature of CDNs, the massive size of a zone containing records for all of the CloudFront subdomains, and the aforementioned ISP caching resolvers that preclude such an approach.