Which is better for provisioning sub-domains on Azure - wildcard CNAME or an API-based DNS like Route 53?
I am building开发者_Go百科 an application on Azure that requires the use of subdomains for each customer. Subdomains will be provisioned during the registration process. Since Azure requires the use of CNAME for DNS resolution, I must decide between a wildcard CNAME or should I add each entry manually using an API such as Amazon Route 53
I am concerned about wildcard CNames because there is some question of whether or not they are fully supported by all DNS systems. I see that it is part of the RFC spec, but I am worried about how up to date all the DNS systems are.
Alternatively, I'm worried about provisioning new CNAME DNS entries for customers in real time. Would they have to wait for the TTL to expire, or would new subdomain CNAME entries be picked up immediately?
Thanks, Doug
I don't know about how many DNS systems support wildcards, but I do know that DNS caches failures. So if a user requests the new domain before you have provisioned it (or perhaps requests anything from the base domain) then he will need to wait up to TTL before he can see the new entry.
DNS wildcards is like meta-information to your DNS server. It never leaves the nameserver, and simply directs your server to treat DNS queries a certain way.
Your DNS clients, or their recursive resolvers don't know, don't need to know, and can't tell* that you're using a CNAME with a wildcard.
That Serverfault link you have just means you will have a harder time finding a host that you can add a wildcard to.
If Amazon Route 53 supports wildcard for CNAMES then that is fine for production, assuming the rest of the server complies with the other DNS RFCs. The only other time you should care about wildcard support is if you use secondary NS records at a different provider.
Regarding the TTL, there are two TTLs to pay attention to: the TTL of the wildcard CNAME or static CNAME you create. Then there is the A record TTL that is stored on Microsoft's name servers and you can't control this one. (you also can't control MSFT's NXDOMAIN expiry in the SOA record, but that is a tangent) You need to consider that when switching between Prod and DEV that there will be clients caching the A record of the former up until the A record expires. If you're using a mobile app, then I've seen cellular ISP's cache this entry longer than expected, and some phones to cache the A record longer too. Sometimes the way to fix this is to reboot the phone.
Bottom line is don't worry about CNAME TTL, it's the A record that matters and MSFT owns this. Do a dig or NSlookup to see the value. If you find a NameServer that supports wildcards, go ahead an use it, but I'd be worried about security and compatibility with other RFCs. I really only trust the DNS provider of my ISP (ATT), UltraDNS, and Dynect. Amazon and UltraDNS have a good relationship. All except ATT has a SOAP API.
If you want to use ATT, you can use them (or another ISP) as a secondary DNS server and make that the primary NameServer. Then make all your changes to the hidden Master DNS.
I geek out on DNS so feel free to ask follow up questions.
*Footnote: They can tell if you are using a CNAME by querying RandomGUID.domain.com If they get the same Answer then they can assume you're using a wildcard CNAME.
精彩评论