Create Elastic IPs so we can actually create web addressable apps with full DNS, not *.cloudapp.net
Right now, you can't use DNS to make your primary web app run seamlessly on Azure. Azure needs to add elastic IPs so you can point a mydomain.com at an Azure IP, instead of the current *.cloudapp.net requirement.
Please add the following to virtual networks and related services:
1. Purchase or have added as many static or at the very least reserved IP addresses that I need to use.
2. I want to be able to specify rules as to which IP(s) should map to which service of mine (firewall translation rule) and which ports can be allowed. (all mapped to my VNet addresses)
3. I need to be able to assign static addresses from my VNet to my VMs.
This would resolve a lot of issues for a lot of people.
1. SSL would be fixed and multiple sites could be supported correctly.
2. DNS addressing that requires static addresses would work.
3. Security that is IPsec driven would work.
4. Traffic would be able to be load balanced without using the cloud services. (this should be build into the service)
In an ideal world the traffic manager would have handled this, but, the TM only updates DNS info which is pointless for a company such as mine. Without these controls it would be foolish to move our services to the azure cloud. With them I could justify the move.
Azure currently allocates IP addresses as required when VPN gateways devices are created, public IP endpoints are defined, etc.
Instead of allocating these addresses from a list of uncontrolled IP addresses, it would be more useful to be able, from the portal, to reserve a number of public IP addresses and bind them individually to VPN gateways, roles, etc.
see the url below for more info about the scenario.
Allow Elastic IP (static IP) so that we can configure our corporate firewalls to allow traffic to and from the cloud servers and enterprise network. This is a big bottleneck as enterprise security folks never open ports to domain names and they like to work with IP addresses only.
Create 'elastic IP addresses' that can be assigned to any role in a Windows Azure subscription account (in the same DC) so that IPs will never have to change again even after removing a role.
There are two parts to this request. The first is being able to support A Record domain names on the current IP of Windows Azure. Today, given we only release the IP when the entire service (Web/Worker or VM), this is possible and done today.
The request for elastic and persistent IP is a separate request and will simplify this scenario even further. This is something we are looking at today.
Akash Kava commented
Did anybody notice that if you map domains using CNAME, the actual IP has TTL of less then 15 seconds, this means that every subsequent request with duration of more then 15 seconds will require explicit DNS request to nearest DNS server, which in turn will further make DNS request to root servers because TTL is so small. This reduces browsing speed. Microsoft should hire somebody who knows DNS better.
And if we map IP, we have no idea when that will change. Also now we understood that keeping one VM/Website alive on same Cloud Service will not release IP. Fine if we do that, what if Azure infrastructure goes down for maintenance or something goes wrong in your side and that changes our IP addresses, we will be doomed.
Dynamic IP addressing is never part of hosting business, every hosting company knows this, I am so surprised that how come Azure Architecture guys totally rule out problems of dynamic IP addressing.
Honestly, instead of spending time on building new features like Visual Studio Online and Cache etc, this is the biggest bottleneck of hosting. You know what today we are using Azure to store backup of our services on Amazon and I still feel it is always going to be our secondary backup storage instead of primary cloud services.
We just got burned by nit having a static IP. We had to take our VM down completely and bring it up again... only to find it with a different IP address, which messed up customer access until our DNS propogated.
We've also had to give our IP address to our payment gateway provider for a project while we are still developing our software. Now we cannot drop the VM to reduce costs during the dev phase because we know the IP we have given to the payment gateway will change, rendering our software inoperable.
I agree that this is critical for so many reasons. I am looking at switching from AWS to Azure today but this is a ship stopper for me. I need to be able to have a public IP that never changes and have host(s) behind it change at will.
David Wood commented
With AWS having EIPs, it's crucial that MS offer this too. In today's world, cusotmers can't afford to lose an IP address and tell all their customers they now have to update firewall. It has the potential for severe impact.
Fabian Schulz commented
If I could, I would give this all the 10 votes I have.
Fabian Schulz commented
This is such a must-have feature. It is so hard to explain to customers why their security policies - stating that communication must be secured with firewalls allowing only certain IPs at the other end - are totally outdated and have to be updated.
To be honest, even as a Microsoft partner we are thinking hard about switching to Amazon. And just for this one problem!
A great thanks would go to Microsoft for finally resolving this problem.
You could use DNS CNAME entries to alias your domain ( ?.mydomain.com ) to ?.cloudapp.net.
Andrew Allan commented
Where do you want to use your elastic band today?
Thomas (Mentum) commented
It's easy in UserVoice.
I simply can't believe that this request is from 2009 (4 years ago) and we still haven't even had any response from the product manager. Especially given the fact that it is currently the number 1 most requested feature.
We can't event connect to third-parties who do IP-Based authentication.
Andrew Middleton commented
It's a sad day when I hear that the most likely reason that his feature has not been added is because Microsoft thinks that it's more strategic to their bottom line to not have it. Apparently it's not a technical issue but an ideological one from what I've been told.
I do however have a solution for those that are looking to support multiple websites, it does not involve SNI and can be run out of azure or through another service. You can contact me below to work out a price. If you're running multiple sites I'm sure that I can save you money.
We use develop software that uses Burst to Azure from HPC. As it is, bringing a new Azure node into a local compute cluster creates a new deployment, which gives out a new VIP. Our corporate firewall, and that of many of our customers (finance industry), only whitelist IP addresses so dynamic IP addresses don't work for us.
Over the past two years many customers have been frustrated by the inability to use multiple IP addresses on the azure cloud. This increases cost and is impractical for companies that host multiple sites. I recently found a way to accommodate such a request which has the potential to reduce your overall operating costs. Since most people have sites with marginal amounts of traffic, it makes more sense to host those on a pair of central servers. If you have 100s of sites azure is not for you, until now. With a bit of effort and some changes to your topology SSL for multiple sites IS possible.
If you are interested in purchasing/licensing my solution please contact me at firstname.lastname@example.org.
Do you like join domain to various IP adresses ? Domain *cloudapp.net is stable, load-balancer transparent independent unique name !
LOAD BALANCER TRANSPARENT (FOR YOUR MULTIPLE NODES) !
Mohammad Hajjat commented
Can anyone please explain why would implementing such a thing be challenging and difficult? I'm really interested in knowing the reason. There must be a pressing reason why Microsoft isn't doing this...
Perbol Kodexe commented
When is MS actually going to roll this out? This request is from 2009 - 3 years back and the product manager hasn't said anything about it's roadmap. Especially considering this is the 2nd most popular request!?!
Without static IPs (or elastic IPs in a cloud-centric sense), we can't have whitelisted API services where whitelisting is done by IP addresses. This is a common practice in the finance world where only whitelisted IPs can connect to specific services.
Nor can we have A record DNS entries.
Nor can be have SSL certificates bound to IPs
Considering IP addresses are so very fundamental to the internet, it blows my mind that Microsoft won't let people (who actually *build* those very services and products) have any control over it.
Without a static IP SSL will not work. After talking with some of the sales team today it's very clear that this is an issue for Microsoft and has been on their radar for over a year now. I have no idea why it's not fixed but it's costing them business.
If they simply added port forwarding to the traffic manager this would resolve the issue outright as far as SSL is concerned. Traffic in on port 443 maps to 444 etc. IIS understands this and would then allow the connection to a different site on that criteria without impacting the customer.
Luke Latham commented
If you need wildcard CNAME support and you're ok with using something like Dyn services, I have posted some info here that might help: http://www.postoli.com/Dyn-Wildcard-CNAME-and-Microsoft-Azure ... these instructions permit you to use the myapp.cloudapp.net A-rec that Azure provides without having to use the VIP with your DNS setup. I also answer in there how to deal with the issue that Joe brought up regarding having traffic from mydomain.com get resolved to www.mydomain.com. In Dyn, this is accomplished with an A(Webhop) record in the DNS settings.
Lester W. commented
I am running both DNS and an Exchange server in my Azure cloud. There was a little bit of trickyness involved, but I have it working quite smoothly now as follows using two Virtual Machines ("VM1" and "VM2" for this example):
• Set up a domain name (e.g. "mydns.net") which will service all of your other domain names with NS1 as "VM1.cloudapp.net" and NS2 as "VM2.cloudapp.net". You'll have to make sure the names resolve to the correct IP addresses assigned by Azure. Depending on your registrar, any IP address change will get picked up and propogated. You could use the dnsazure.com service for this (optional).
• Now in your DNS server, define "ns1.mydns.net" as CNAME to "VM1.cloudapp.net" and "ns2.mydns.net" as CNAME to "VM2.cloudapp.net".
• Optionally, define "cname1.mydns.net" to CNAME to "VM1.cloudapp.net" and "cname2.mydns.net" to CNAME to "VM2.cloudapp.net", respectively. You can then use these CNAMEs for subsequent domain definitions.
• In general, I'd recommend keeping the maximum TTL on DNS records low (like 20 minutes), so if Azure changes your IP address on you, the changse should get picked up quickly.
• All remaining domains in your DNS should be registered with "ns1.mydns.net" and "ns2.mydns.net" as their name servers. You could also use "VM1.cloudapp.net" and "VM2.cloudapp.net" but this makes it easier to change in the future.
• Lastly, choose the primary domain name you will use for your Exchange server (e.g., "foo.net"). Define "mail.foo.net" as a CNAME to your Exchange virtual machine "VM1.cloudapp.net".
• For each domain that you plan to receive email on:
(a) define the MX record to point to "mail.foo.net" (e.g. "domain.com MX 10 mail.foo.net")
(b) define a TXT record with "v=spf1 a mx -all" (this will help with outbound email acceptance)
• Define any "www" records with the appropriate CNAME.
• Define each root domain name with an 'A' record with the IP address of the appropriate VM server - but only if needed (it is NOT needed for inbound email!). [This is the unfortunate step. In most cases though, I don't have an 'A' record at all, just an MX and TXT records for the domain.]
With the preceding configuration, you eliminate your dependency (for the most part) on the IP address assigned by Windows Azure. Furthermore, if you need to change to a different VM, you just need to change the CNAME records and the "mydns.net" name servers. Of course, if you have any 'A' records with the Azure VM IP address, then they will need to change.