I have DNS records for a web-app service, also hosted with Azure.
The site works if I do not prepend www on the url and sends back the following page if I do prepend it:
Here is my A record (I saw something about creating this):
I have looked everywhere I cannot find any good answers.
In other DNS management services I would just do this:
but I cannot do that here.
You should set CNAME to your Azure websites URL
New-AzDnsRecordSet -ZoneName contoso.com -ResourceGroupName "MyAzureResourceGroup" `
-Name "www" -RecordType "CNAME" -Ttl 600 `
-DnsRecords (New-AzDnsRecordConfig -cname "contoso.azurewebsites.net")
This looks like it is useful. It provides the full process:
https://learn.microsoft.com/en-us/azure/dns/dns-web-sites-custom-domain
Related
We created an Azure Red Hat OpenShift (ARO) cluster via:
az openshift create --resource-group $CLUSTER_NAME --name $CLUSTER_NAME -l $LOCATION --aad-client-app-id $APPID --aad-client-app-secret $SECRET --aad-tenant-id $TENANT --customer-admin-group-id $GROUPID
The URL for the cluster came out in the form:
https://openshift.<cluster-id>.<cluster-region>.azmosa.io/
Is there a way to give it a cleaner, human-readable URL like:
https://openshift.myprodcluster.<cluster-region>.azmosa.io/
As #Will Gordon comment, I don't think you can change the default URL https://openshift.<cluster-id>.<cluster-region>.azmosa.io/ provided by the Azure platform.
If you need a cleaner, human-readable URL, you could try to add a CNAME DNS record which maps your custom domain name like www.contoso.com to this hostname openshift.<cluster-id>.<cluster-region>.azmosa.io in your DNS provider.
If so, you will need to purchase a public domain and get an SSL certificate with that custom DNS name over a secure HTTPS connection. You also could get a free SSL certificate from Let’s Encrypt.
I have configured an Azure Web Application Firewall in-front of my App Service and it is successfully passing requests through. I have followed the instructions a the following microsoft docs.
I have the following configuration:
Custom domain: test.[customdomain].com the DNS records points to the public IP configured against the WAF. The custom domain is also configured on the Web App.
The WAF has a backendpool which is configured to use "IP Address or FQDN" with the following record:
[customwebsite].azurewebsites.net
When I navigate to test.[customdomain].com I am successfully receiving the website, however it appears as though the WAF is rewriting the request when forwarding to the App Service.
As such, my App Service receives the request and it has the URL [customwebsite].azurewebsites.net, instead of test.[customdomain].com.
Is this intended? Reviewing the multi-tenant documentation it should not be rewriting the host by default?
The solution was to ensure you do not use the option -PickHostNameFromBackendAddress when specifying the New-AzureRmApplicationGatewayBackendHttpSettings. I should have noticed, but this setting tells the WAF to rewrite using the addresses specified in the BackendHttpSettings.
You also then need to reconfigure your probe to specify manual hostnames. e.g. do not specify -PickHostNameFromBackendHttpSettings when setting AzureRmApplicationGatewayProbeConfig.
For me what has worked is in the HTTP Settings to make sure -PickHostNameFromBackendAddress is NOT selected. Also the interface doesn't let you set the -HostName so drop to PowerShell and set the -HostName and the probe like this:
$GW = Get-AzureRmApplicationGateway -ResourceGroupName "MY-APP-WAF-RG" -Name "APP-WAF"
$PROBE = Get-AzureRmApplicationGatewayProbeConfig -ApplicationGateway $GW -Name "my-api-https-probe"
Set-AzureRmApplicationGatewayBackendHttpSettings -ApplicationGateway $GW -Probe $PROBE -HostName "my-api.example.org" -CookieBasedAffinity "enabled" -AffinityCookieName "AGAffinity" -Protocol "HTTPS" -Port 443 -Name "my-api-https-settings"
Set-AzureRmApplicationGateway -ApplicationGateway $GW
Also on the probe I have the -PickHostNameFromBackendHttpSettings selected.
Using the above way I have two web apps with custom domain and SSL configured behind the WAF.
Terrible experience setting this up.
I have 2 web apps behind Application Gateway. I am trying to access by http://<aap_gateway_pub_ip>/web1 should go to http://webapp1.azurewebsites.net and http://<aap_gateway_pub_ip>/web2 should go to http://webapp2.azurewebsites.net. I have defined path based rule like:
$web1PathRule = New-AzureRmApplicationGatewayPathRuleConfig -Name web1pathrule -Paths "/web1" -BackendAddressPool $regbackendpool -BackendHttpSettings $poolSetting
$web2PathRule = New-AzureRmApplicationGatewayPathRuleConfig -Name web2pathrule -Paths "/web2" -BackendAddressPool $accbackendpool -BackendHttpSettings $poolSetting
$urlpathmap = New-AzureRmApplicationGatewayUrlPathMapConfig -Name urlpathmap -PathRules $web1PathRule, $web2PathRule -DefaultBackendAddressPool $defaultPool -DefaultBackendHttpSettings $poolSetting
$urlRoutingRule = New-AzureRmApplicationGatewayRequestRoutingRule -Name routingrule-001 -RuleType PathBasedRouting -HttpListener $defaultlistener -UrlPathMap $urlpathmap
The issue is when I directly access http://<aap_gateway_pub_ip> request goes to default pool which is web1 backendpool and opens web1 app. But when I access http://<aap_gateway_pub_ip>/web1, it returns 404 error.
What additional configuration is required to make this working?
I also got stuck in this problem for a day and trust me Microsoft should think about and adding more clear instructions.
The thing is when you access the base address of frontend IP like this http://<aap_gateway_pub_ip>
It simply replace the frontend IP with the backend pool based web app IP, so the request sent to the web app is something like http://webapp1.azurewebsites.net and it works.
Problem starts when you create a path based rule and configure it like this http://<aap_gateway_pub_ip>/web1 -> http://webapp1.azurewebsites.net
What app gateway does, it simply replace the front end ip with the backend ip
So the request sent to backend is
http://webapp1.azurewebsites.net/web1
and if your backend webapp does not contain that page in the website then it will through 404 error.
So there are 2 solutions for that
1> Edit the httpsetting of the rule and add a '/' in the "override backend path"
2> The other approach is to actually drive the path based rule in such a way that the final path (like web1 in your case) should actually exists in the backend server or webapp.
Please follow additional backend http settings and probe configuration for integration with Web Apps to work correctly. The documentation is here.
I am very much aware that Reverse DNS is possible on Azure Cloud Services. That's not what I'm asking about. I need to know if it's possible when using Azure Resource Manager. I've looked around a lot online, and while I've found some (2+ year) old questions about it, I can't find any answers.
Thanks!
If you've already created a static public IP and want to add reverse DNS to it:
Using Azure Powershell:
Login to azure subscription using:
login-azurermaccount
Select the subscription using:
select-azurermsubscription -subscriptionname mysubscription
Get the IP using:
$p = get-azurermpublicipaddress -name myipname -resourcegroupname myresourcegroupname
Set the reversedns (ensuring your forward DNS is set first) using:
$p.dnssettings.reversefqdn = "mail.mydomain.com"
Finalize the setting using:
set-azurermpublicipaddress -publicipaddress $p
Ok, while the other two answers were helpful, neither got me all the way there. But I finally figured this out. Many shouts to Michael B who has been a HUGE help!
The domain I used to learn and play is woodswild.com. If you want to follow along with these steps, just swap out as needed. Hope this helps save someone some time. It took me WAY WAY too long to figure this out.
One more thing: These steps assume you are NOT using a template.
1: Open Windows Azure Powershell
2: Inside Powershell, log in to your account with this command:
Login-AzureRMAccount
This will prompt you for a log in and password.
3: Create a Resource Group.
You can do this in the UI if you want, or in Powershell. This is the command if you want to do it in Powershell:
$rgName="RG1"
$locName="Central US"
New-AzureRmResourceGroup -Name $rgName -Location $locName
4: Create a Temporary Public IP Address:
The process of creating a Public IP Address with fully qualified Reverse DNS lookup (ReverseFqdn) is wonky. The first thing we have to do is create a temp (throwaway) Public IP Address withOUT a ReverseFqdn. Do that with this command:
$ipName = "tempRG1PIP"
$locName = "Central US"
$rgName = "RG1"
New-AzureRmPublicIpAddress -AllocationMethod Static -ResourceGroupName $rgName -Name $ipName -Location $locName
In this example, the domain I'm playing with is "woodswild.com". After running this command, go to the UI and under the Configuration for the IP Address you just created, give the IP address a DNS label of "tempwoodswild" (or whatever you want for your domain).
5: Create a CName record
For the domain you are setting up with Reverse DNS, log into your registrar. Go to the section where you manage your DNS records for your domain. Create a CName record with the host of "www" (or mail, if you are setting up a mail server) which points to "tempwoodswild.centralus.cloudapp.azure.com" (or to whatever DNS label you created.)
6. Create Another (Permanent) Public IP Address
Now that we have www.woodswild.com (or mail.woodswild.com) pointing to the temp IP address, we can create a perm one.
$ipName = "RG1PIP"
$locName = "Central US"
$rgName = "RG1"
$rvFqdn = "www.woodswild.com" (or mail...)
$dnLabel = "woodswild"
New-AzureRmPublicIpAddress -Name $ipName -ResourceGroupName $rgName -Location $locName -ReverseFqdn $rvFqdn -AllocationMethod Static -DomainNameLabel $dnLabel
You now have a Static, Public IP Address with a ReverseFqdn!!!
7. Delete the temp IP Address
You can do this in the Azure Portal UI.
At this point, in Azure, you should have a Resource Group with only one item in it: Your Public IP Address
8. Edit the CName record, and create an A (Host) Record.
Back in your registrar, edit the CName to be: woodswild.centralus.cloudapp.azure.com
Also, create an A(Host) record as follows:
Host: #
Points To: 40.122.166.144 (which is the IP of the new, perm, Public IP Address)
9. Test the ReverseIP Lookup:
At this point, you should be able to do a reverse lookup on the IP and get the domain:
Tip: At any time, you can see the info from this IP address with this command:
New-AzureRmPublicIpAddress -Name RG1PIP -ResourceGroupName RG1
Creating a Virtual Machine with the Public IP Address
From here, creating a virtual machine that is assigned your public (static) IP with Reverse Lookup capabilities is just a matter of associating the VM with the IP you just created.
Registering a reverse DNS in Azure is complicated by the fact that you need to have a forward A record pointing into an IP address before you can register the reverse. i.e. you need to register www.example.com to point to an IP address in Azure before you can register the reverse address.
That means that if you are creating via template, you need to pre-configure a forward domain else the template will fail.
So presuming you are using a template there are a few steps you need to perform beforehand.
Create an Azure static address - this needs to be static since we're not going to allocate it to a machine. If we created a dynamic address it wouldn't be available until it was attached.
$ip = New-AzureRmPublicIpAddress -Name TestIP1 `
-ResourceGroupName $ResourceGroupName `
-Location $location -AllocationMethod Static
Register the address you get above from $ip.IpAddress in DNS
www IN A 123.45.67.89 ;; $ip.IpAddress address
Run deployment script, if using a template
"properties": {
"publicIPAllocationMethod": "Dynamic",
"dnsSettings": {
"domainNameLabel": "[variables('PublicDNS2')]",
"ReverseFqdn": "[concat(parameters('vmName2'), '.', variables('domainname'))]"
}
Point forward domain to new address (this can be retrieved as an output from a template)
www IN A 123.45.67.90 ;; Deployment IP Address
Finally delete the temporary IP Address
Remove-AzureRmPublicIpAddress -Name TestIP1 `
-ResourceGroupName $ResourceGroupName -Force
Joe Who's answer worked perfectly for me, and was simpler than creating a temporary IP (I already had an existing one, plus I would have had to mess with my DNS settings for the 3rd time in a week).
mysubscription is your subscription type - in my case, it's "Pay-As-You-Go", which you can find in your Azure portal settings.
myipname is the name of your IP address resource, and myresourcegroupname is the name of the resource group that it's in. for the domain, I just entered "mydomain.com" (with my actual doman, of course).
Aside from the nightmare that was getting Azure PowerShell working, the whole thing took about 5 minutes.
Reverse DNS lookup is now functioning and my emails are no longer getting bounced as spam (there is more to set up of course other than this, but I'd already jumped through those hoops).
I created a 3-level Azure Traffic Manager. But it doesn't work.
At the top tier, it's called myroot.trafficmanager.net.
At the middle tier, there are 2 nested traffic manager profile called mysub1.trafficmanager.net and mysub2.trafficmanager.net.
At the bottom tier, each nested traffic manager profile has 2 endpoints, Azure websites.
The balancing method of the top tier is Round Robin.
The balancing method of the middle tier is Performance.
I used Azure PowerShell cmdlets to create the mapping between the top tier and the middle tier.
PS C:\> Get-AzureTrafficManagerProfile -Name “myroot"
PS C:\> $TrafficManagerProfile = Get-AzureTrafficManagerProfile -Name "myroot"
PS C:\> Add-AzureTrafficManagerEndpoint -TrafficManagerProfile $TrafficManagerProfile -DomainName "mysub1.trafficmanager.net" -Status "Enabled" -Type "TrafficManager" | Set-AzureTrafficManagerProfile
PS C:\> $TrafficManagerProfile = Get-AzureTrafficManagerProfile -Name "myroot"
PS C:\> Add-AzureTrafficManagerEndpoint -TrafficManagerProfile $TrafficManagerProfile -DomainName "mysub2.trafficmanager.net" -Status "Enabled" -Type "TrafficManager" | Set-AzureTrafficManagerProfile
After the above command is done. I can use nslookup myroot.trafficmanager.net command to see the IP have been directed to the right endpoint. But when I open myroot.trafficmanager.net in the browser, I got the error:
Error 404 - Web app not found.
I would appreciate if anyone could give me any clue.
This is most probably due to the fact that your top-level Traffic Manager domain (myroot.trafficmanager.net) is not mapped as custom domain to your web app (Web Site). And this is because, your Web Site only knows about mysub1.trafficmanager.net).
You can solve your issue by using custom domain and correctly map your custom domain to your Azure Web App. Then, also map your custom domain to your Traffic Manager Domain.