Verify Domain Ownership and Configure DNS Records
Before mapping a custom domain to an Azure App Service, the administrator must prove ownership of the domain through a verification step. This requires the App Service app to be running on a tier above the Free tier. The process begins by navigating to the App Service in the Azure portal, opening the Custom domains pane, and copying the Custom Domain Verification ID—a unique string that ties the domain to the Azure resource. On the domain provider’s DNS management page, a TXT record is added with a host name that depends on the target domain type. For a root domain such as contoso.com, the host is _asuid and the value is the copied verification ID. This TXT record proves that the administrator controls the DNS zone and prevents unauthorized binding.
Once verification is in place, the actual DNS record that points traffic to the App Service must be created or remapped. The administrator retrieves the App Service’s external IP address from the Custom domains pane. For a root domain, an A record is used with the host @ and the value set to that IP address. For a subdomain like www.contoso.com, a CNAME record pointing to the App Service’s default hostname is preferred because it adapts automatically if the App Service’s inbound IP changes. After the DNS changes propagate, the administrator returns to the Azure portal, opens the Add custom domain dialog, enters the domain, and selects Validate. Green check marks confirm that both the verification TXT record and the traffic record are correctly set. If validation succeeds but a red X with “No binding” appears, a private certificate must be added and bound to the domain. Finally, browsing to the custom domain tests the resolution; if errors occur, clearing the browser cache or remapping the A record (if the App Service IP changed) resolves them.
Configure Custom Domain Bindings in Azure App Service
Azure App Service replaces its default URL with a Custom Domain to strengthen brand identity, but the administrator must choose the correct DNS record type based on the domain structure. An A record is required for root domains (e.g., contoso.com) and must point to the App Service’s dedicated IP address. A CNAME record is preferred for subdomains (e.g., www.contoso.com) because it remains valid even when the App Service’s inbound IP changes. Wildcard records (*.contoso.com) can map all subdomains at once. Selecting the right record type ensures stable traffic routing and reduces future maintenance when the App Service scales or moves to a different stamp.
Security is enforced through a mandatory TXT record containing the Domain Verification ID. This record prevents a subdomain takeover attack, where a threat actor claims ownership of a domain that has been removed from its original resource but still has DNS pointing at Azure. The verification ID is unique to each App Service app and must be present in the DNS zone before Azure allows the binding. Once verified, the administrator configures SSL/TLS bindings to encrypt traffic. Azure provides a free App Service Managed Certificate that is automatically issued and renewed, but it cannot be exported. For more control, the administrator can upload a PFX certificate or import one from Azure Key Vault. The binding method depends on the certificate and tier: SNI SSL allows multiple certificates to share one IP address and works with most modern browsers, while IP SSL dedicates a static public IP to a single certificate and requires a higher pricing tier, often used for legacy clients that do not support SNI.
Implement and Manage SSL/TLS Certificates for Custom Domains
SSL/TLS certificates secure communication between clients and the App Service by encrypting data in transit and authenticating the server’s identity. For a custom domain, a certificate must be bound to enable HTTPS. Azure App Service supports two binding methods. SNI SSL is the default; it lets multiple certificates secure different domains on the same IP address, making it cost-effective and compatible with almost all modern browsers. IP SSL dedicates a unique public IP address to a single certificate, which is necessary only for legacy clients that do not implement SNI. The administrator chooses the method based on the client base and the App Service pricing tier, since IP SSL requires a Standard or higher tier.
Certificates can originate from two sources. Azure App Service Managed Certificates are free, automatically issued by Azure, and autorenewed as long as the domain’s DNS records (the verification TXT record and the traffic A or CNAME record) remain correctly configured. Managed certificates cannot be exported, but they simplify maintenance. Bring Your Own Certificate (BYOC) covers scenarios where the organization already owns a certificate from a trusted CA or needs specific properties. BYOC certificates can be uploaded as PFX files directly or imported from Azure Key Vault for centralized key management. For BYOC, the administrator must manually upload or import the certificate, then bind it to the custom domain in the Custom domains section of the App Service. Renewal is manual: when the certificate expires, a new PFX must be uploaded and the binding updated. This process can cause downtime if not planned, especially for IP SSL bindings where a new IP address might be assigned.
Advanced security settings further harden the App Service. The administrator should configure the minimum TLS version (e.g., TLS 1.2 or 1.3) to meet compliance standards such as PCI DSS and disable outdated protocols like SSL 3.0 or TLS 1.0. Mutual TLS (mTLS) can require clients to present a certificate for authentication, though the validation logic must be implemented in the application code. Certificates should use strong cryptographic settings, including SHA256 hashing and RSA keys of at least 2048 bits. Regularly monitoring certificate expiration via Azure Advisor helps prevent service interruptions, and any changes to the domain’s DNS records (such as removing the verification TXT record) will cause managed certificates to stop autorenewing, so administrators must keep the DNS configuration stable.
StudyCerts
StudyCerts