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.
anonymous
shared this idea
35 comments
-
Thomas (Mentum)
commented
Pls. merge this idea with http://www.mygreatwindowsazureidea.com/forums/34192-windows-azure-feature-voting/suggestions/397428-create-elastic-ips-so-we-can-actually-create-web-a.
It's easy in UserVoice.
-
Christopher commented
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.
Very disappointing.
-
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.
-
krolley
commented
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.
-
Andrew
commented
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 info@branches.net. -
Neev
commented
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
-
Sid
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.
-
Andrew
commented
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):
DNS Configuration:
• 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.
-
lwalker
commented
#Chris Auld but why not take a compromise solution? Maybe you could use the actual VIP (fixed IP asigned to a Cloud Service), but keep this IP asigned to the subscription for several days after deleting the cloud service). Then, you could select this "unused" IP when creating a new service...
This should not be dificuolt to implement, is it?
-
Fabio
commented
Yes, please do that, I love windows azure but I will need to hire AWS just because of the static ip to put on some firewalls.
-
vermorel
commented
Agreed, it has been a long standing issue for us as well.
-
Omri Gazitt
commented
From a private communication... it now appears that as long as you don't delete a deployment, Azure will preserve VIP addresses (and considers any VIP address change to be a bug). Awaiting public confirmation :-)
-
Omri Gazitt
commented
+1 to this feature request.
I have the exact scenario that Joe A described below... see the URL below for more details.
-
Joe Albahari
commented
I agree that elastic IPs are necessary to use http://domain.com as your primary URL instead of http://www.domain.com. This is because the former requires a cname on a second-level domain which conflicts with MX records
-
Gregory Katz
commented
I have a specific e-prescribe provider who uses IP based authentication and takes at least 2 weeks to change the setting.
-
Stephen Goss
commented
We go to third parties who impose IP based authentication. We need more stability in the IP address than the suggestion of not deleting the service. These IP authentications can take many weeks to set up with the larger corporates. The consequences of accidentally deleting the service and losing the IP are too serious.
