nitinag
It works like this: Root -> TLD -> NS -> NS -> ETC.
Root Servers are fixed and everything drills down from there: https://www.iana.org/domains/root/servers
A visual example of how the nameserver hops work starting from the root using the nameserver delegation view feature of our dns lookup tool: https://www.misk.com/tools/#dns/[email protected]...
(Disclosure: I work @ Misk.com, an ICANN accredited registrar, our link above)
AWS Well-Architected Framework [pdf]
AWS Well-Architected Framework
S3 Select and Glacier Select – Retrieving Subsets of Objects
Microsoft's Redmond HQ is getting a multi-billion dollar makeover
Amazon Elastic Container Service for Kubernetes
Amazon Elastic File System – Shared File Storage for Amazon EC2
AWS EC2 Container Service
New MacBook Air Released – $100 Cheaper
Gmail Down for 50 Minutes Today
Building on that: The github blog post states that using an ALIAS record will allow you to take advantage of their CDN. I don't know if I believe that. Since the ip is being fetched by the ALIAS supporting nameserver, the CDN will use that as the end user location. Therefore, everyone is going to that location.
The only way around that would be:
1) CDN uses IP ANYCAST (in which case their CDN would work with just listing the IP as well and the ALIAS point is moot)
OR
2) ALIAS supporting nameserver uses the draft edns-client-subnet rfc (very low probability any current ALIAS provider uses it to resolve the ALIAS since support for the draft may be iffy and much heavier ns resolve logic for ALIAS provider).
Additional thoughts welcome.
Update: Github's external CDN provider is using ANYCAST, so that explains why that's working --- AND --- to explain why their CDN doesn't work on direct ip pointing is because they are giving you the ip to their own direct servers, which are non-cdn / non-anycast, which explains why in this case, the ALIAS record gives the benefit for their CDN, while the ip doesn't (because they're having you use a different non-cdn ip so they can change external cdn providers at will and not affect those that are pointing to the ip directly).
Link: http://www.icann.org/en/resources/registrars/raa/approved-wi...
You can thank the law enforcement lobby and ICANN wanting to keep them happy. All of us registrars fought hard against it for a number of obvious reasons, but they went forward with it anyway.
Almost all registrars will be on the new contract soon if they already aren't because ICANN made it a requirement to be able to sell the new GTLDs. This is now going to be a normal part of owning a domain name.
Thanks for pointing that use case out. I'll get support for resolving IPv6 Only hostnames added in.
Existing IPv6 Support:
AAAA Lookup - https://www.misk.com/tools/#dns/arin.net
IPv6 Reverse Dns & FCrDNS - https://www.misk.com/tools/#dns/2001:500:4:13::80
IPv6 Traceroute - https://www.misk.com/tools/#traceroute/2001:500:4:13::80
IPv6 Whois - https://www.misk.com/tools/#whois/2001:500:4:13::80Realtime Dns Tool w/ IPv6 Support
- Queries all common dns records together (A, AAAA, CNAME, MX, TXT, SRV) - Reverse DNS and FCrDNS - Specific nameserver support - IPv4 + IPv6
Here are the expiration policies I could find for GoDaddy, Namecheap, and Misk.com (us):
http://support.godaddy.com/help/article/608/what-is-your-pro...
http://www.namecheap.com/support/knowledgebase/article.aspx/...