8

See i.e.: How to set up CNAME to point to Azure

or the text within the azure portal:

Manage custom domains text

Why is this necessary in the first place? Why does pointing the domain name through an A record not prove that I am the owner of the domain?

I mean.. how can you otherwise change a DNS record in the first place?

What abuse does this rule prevent?

Community
  • 1
Dirk Boer
  • 455
  • 1
  • 3
  • 9
  • Care to explain the down vote so I can update my question? – Dirk Boer Sep 03 '15 at 10:24
  • You're asking random strangers on the internet to explain a company's policy. It would make much more sense to ask that company. – Jenny D Sep 04 '15 at 04:30
  • 1
    I'm pretty sure that there is actually a technical reason for this. People that know a lot about DNS and cloud might know the reason why - giving me and others a lot better understanding about these systems and there limitations. Besides that the Azure is actually **referring** to StackOverflow for questions, so in theory I am asking them. – Dirk Boer Sep 04 '15 at 06:47
  • I am aware that they are referring people here. I am not aware of the people volunteering their help here being employed by Azure. We are smart and helpful, but we are not them. – Jenny D Sep 04 '15 at 10:44
  • However, my guess as to why they're choosing this is that they've made a design decision when they built their verification system that said system will look for a CNAME and not an A record. Why they made that decision is something only they can answer. – Jenny D Sep 04 '15 at 10:46

5 Answers5

7

If you have control of a DNS lookup for a computer, or are able to inject a host record, then you could spoof an A record for that machine and point it to an Azure website (there's actually nothing to stop you doing that for a VM though)

By making you create a cname record, and independently verifying it (via their internal / public DNS system), it means that you do have control over the domain, and you're not spoofing somebody else's domain.

Michael B
  • 738
  • 3
  • 10
  • 1
    Why was this answer accepted when it's imprecise, it does say very little and there are lots of better (and more upvoted) ones? – Massimo Nov 23 '15 at 15:31
  • @Massimo there appear to be equally upvoted answers! and feel free to edit it if you think it is 'imprecise' or contribute a correct answer. Personally I felt the other answers didn't answer the question about why a cname is used, so I contributed an answer that explained the reason. At the time of writing there was a single answer that was incorrect. – Michael B Nov 23 '15 at 17:57
  • The question was about why a CNAME is used instead of other record types, not the basic topic of "you need to make changes to DNS in order to prove domain ownership"; the correct answer is "because Azure websites have dynamic IP addressing and so you refer to them by their public names". Additionally, your point about spoofing doesn't really mean anything here... – Massimo Nov 23 '15 at 18:08
  • @Massimo according to [Azure Documentation](https://azure.microsoft.com/en-us/documentation/articles/web-sites-custom-domain-name/) "Azure also assigns a virtual IP address" and "For web apps, you’ll create either an A record or a CNAME record." also "The IP address may change if you delete and recreate your web app, or change the web app mode back to free" - The question asked 'why is this necessary / what abuse does it stop" which is the question I answered. and the awverify record has nothing to do with connecting to the website - it is to verify (the hint is in the name) – Michael B Nov 23 '15 at 20:58
2

Let me try to answer your question by providing two cases. In both cases, you will still need to verify that you are the owner, it is just a security step.

1) www.example.com is not being visited and not in production

2) www.example.com is currently in production and is heavily being used

1) If your domain is now being setup or is not in production/being accessed, you can create a CNAME record that points to yoursite.azurewebsites.net. No awverify.myhost.azurewebsites.net needed.

2) If your domain is in heavy use and being accessed currently, and you wish to test to see if Azure sees the changes in your DNS records, you can create a sub-domain named 'awverify' as in awverify.example.com and point it to a created sub-domain awverify.myhost.azurewebsites.net. This will not affect your current users accessing your website going to www.example.com. Once Azure verifies that it sees the change in the CNAME, you can then notify users of maintenance and change the A record. If you just change the A record, the site may be seen as offline for up to 8 hours.

So to answer your question simply, you don't need to use awverify. Just changing the CNAME can work as well. Also, just changing the A record will redirect all traffic from yourdomain.com to yoursite.azurewebsites.net

Hope this helps.

Joel Coel
  • 12,910
  • 13
  • 61
  • 99
Yudhistre
  • 21
  • 2
  • Hi @Massimo / Yudhistre, thanks for the extended answer. But what I still don't get - how does a CNAME verify that I am the owner, and *an A record does not*? – Dirk Boer Sep 03 '15 at 10:21
  • 2
    A records point to IP addresses, CNAME records point to names (they are aliases). You don't use A records to reference Azure services, because they use dynamic IP addressing and an A record must point to a static IP address; instead, Azure services have fixed *names*, so you need to use CNAME records to reference them. – Massimo Sep 03 '15 at 10:35
  • You can actually reserve a static IP ( http://blogs.msdn.com/b/benjaminperkins/archive/2014/05/05/how-to-get-a-static-ip-address-for-your-microsoft-azure-web-site.aspx ) - besides that, they explitly talk about pointing an A record to your IP (is i.e. often necessary for naked domains) – Dirk Boer Sep 04 '15 at 06:42
  • So I guess somewhere there must be actually another *technical* reason for the whole awverify process. – Dirk Boer Sep 04 '15 at 06:50
  • 1
    Your second 1) is incorrect, you cannot direct traffic to a website on Azure unless you have performed the awverify step. (I have just verified this) You are simply directed to a page that says "The web app owner has registered a custom domain to point to the Microsoft Azure App Service, but has not yet configured Azure to recognize it." – Michael B Sep 08 '15 at 03:57
2

In order to prove control of the domain, you need to put some information in a DNS record on the domain, which will identify your Azure account.

Such information can be embedded in the domain name which a CNAME points to. The part of the domain which was omitted from your post I would expect to identify your particular Azure account.

You don't actually need to keep that name secret. After all, it is going to be publicly visible once you put it in a DNS record.

The reason they couldn't do the same with an A record is that there is not sufficient entropy in an A record to achieve the same security.

That doesn't mean the CNAME is the only method they could have used. Other methods which could have worked include:

  • A TXT record
  • An AAAA record
  • Multiple A records

Personally I consider a TXT record on a subdomain randomly generated by the verifier to be the best method, since it is the least intrusive. But that appears not to be supported in your case.

kasperd
  • 29,894
  • 16
  • 72
  • 122
  • Hi @kasperd, thanks for your detailed answer. What do you mean with 'not sufficient entropy'? Might have to do with that english is not my native language :) – Dirk Boer Sep 04 '15 at 09:56
  • @DirkBoer If two users were ever to try to get verified for the same domain simultaneously, they would have to have been assigned different IP addresses in order to know which of the users succeeded in verification. And the IP addresses have better be different enough that one doesn't accidentally get turned into the other due to the user making a typo. Doing such a thing in a robust way requires more addresses than are available due to IPv4 shortage. – kasperd Sep 04 '15 at 10:01
  • @DirkBoer You cannot reasonably allocate 2^16 IPv4 addresses just for such verifications. And that would still only give 16 bits of entropy. With IPv6 you could allocate 2^80 addresses without the least concern, which would give you plenty of entropy, so an AAAA record would work. A CNAME or a TXT record would contain some text string, which could contain even more entropy. – kasperd Sep 04 '15 at 10:04
0

1) I have setup several sites on Azure, and they all have the same IP address in the A record. I don't know if the A record IP address might also be assigned to another account, but perhaps that is a possibility. If so, then one might be able to highjack someone else's Azure web site simply by entering the domain into the one's own Azure control panel. This is just a theory, I do not know if it is remotely possible.

2) As mentioned above, the CNAME record is basically an inert record. It does not redirect traffic. When I migrated a large site, and its SSL certificate, it was a blessing to be able to claim ownership with the awsverify, get the domain and SSL certificate configured, and then all the code tested on Azure. Weeks later, I changed the A record to go live. The point being that the A record was not changed until the moment of go-live, weeks after using the awsverify to validate ownership in the domain. So, in my case it was helpful.

Bill Clark
  • 1
0

Not that I agree with this, but here is the answer I got directly from Microsoft. In short, it stops someone from adding a domain you own to another Azure web application, but only in the same datacenter as you. So essentially, someone would have to try to register a domain that you own AND be in the same datacenter (Azure region) for this protection to be useful. From a DNS perspective, it makes little sense, since I can add www.microsoft.com and put up a bogus web page on every webserver I own, but if I don't have access to change the DNS record, it means nothing. Sure I could do this with a rogue DNS server on a rogue access point, but what do I need an Azure web app for in that instance? I can spin up a VM and bypass the restriction anyways. It really makes not sense to me and is really just an annoyance whenever it comes time to add a new site. The process that takes a few minutes now puts a reliance upon DNS before I can even ADD a domain to a web application. This is generally okay for new domains, but if I have an existing domain, it's a pain. I have to create this other DNS record, then delete it after I add my domain to my web app, then modify the DNS record I actually want to change. Anyways, here is Microsoft's response on why:

The security concern is, considering this scenario, if it allows someone to add your domain to their app before you could do it to your web app, then you will be unable to add your domain again due to confliction because Azure web apps share the same front end servers within same datacenter. So it must verify each domain/subdomain before assign it to a web app. If we host websites on a Virtual Machine, there will be no restriction on it.

DubStep
  • 264
  • 2
  • 8