Azure Fundamentals for Web Hosting: Networking basics for web apps (DNS, public IPs, ports, and firewalls)

Minimum networking concepts you need for safe web hosting

To host a website on Azure, you mainly need to understand how a name (your domain) maps to an internet endpoint, which ports are reachable from the internet, and where traffic is allowed or blocked. This chapter focuses on DNS records (A, CNAME, TXT), public endpoints (public IPs and platform URLs), inbound ports (80/443), and the role of firewalls and TLS termination.

DNS in practice: A, CNAME, and TXT records

DNS (Domain Name System) translates a human-friendly domain name (like www.example.com) into a destination your browser can reach. For web hosting, you typically use these record types:

• A record: Maps a hostname to an IPv4 address (a public IP). Use this when you have a stable public IP, commonly with a VM or a load balancer.

  www.example.com  A   203.0.113.10

• CNAME record: Maps a hostname to another hostname (an alias). Use this when Azure gives you a platform hostname (common with App Service and Container Apps) and you want your domain to point to it.

  www.example.com  CNAME   myapp.azurewebsites.net

• TXT record: Stores text used for domain verification and security controls. In Azure web hosting, TXT records are commonly used to prove you own the domain (before binding it) and sometimes for certificate automation workflows.

  Continue in our app.

  You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

  Or continue reading below...

  

  Download the app

  asuid.www.example.com  TXT   "<verification-token>"

Practical cautions: DNS changes are not always instant. Expect propagation delays based on TTL (time to live). When migrating endpoints, lower TTL ahead of time to reduce downtime, then raise it after the cutover.

Public endpoints: what is actually exposed to the internet

A public endpoint is anything on Azure that can be reached from the public internet. Depending on the service, the endpoint might be:

• A public IP address (common with Virtual Machines, Azure Load Balancer, Application Gateway, Azure Firewall).

• A platform-managed hostname (common with App Service: *.azurewebsites.net, and Container Apps: a service URL provided by the platform).

The key safety idea is exposure: only expose what must be reachable by users (usually HTTPS on port 443). Everything else should be private or restricted.

Ports for web hosting: 80 and 443 (and why you should care)

Ports are like numbered doors on a destination. Web traffic uses:

• Port 80 (HTTP): Unencrypted. Often used only to redirect to HTTPS.

• Port 443 (HTTPS): Encrypted using TLS. This should be the default for real websites.

Practical cautions:

• If you must keep port 80 open, configure an automatic redirect to HTTPS and avoid serving sensitive content over HTTP.

• Do not open management ports to the internet (examples: SSH 22, RDP 3389, database ports like 1433/3306). If you need admin access, prefer private access paths and strict allowlists.

How Azure services expose web apps

Platform-managed networking (App Service / Container Apps)

With platform-managed services, Azure handles much of the network exposure for you. You typically get:

• A public URL managed by Azure (service hostname).

• Built-in support for TLS certificates and HTTPS-only settings.

• Service-level access controls (for example, IP restrictions/ingress settings) without you managing NICs, subnets, or OS firewalls.

What you manage: DNS records for your custom domain, TLS certificate binding (or managed certificate options), and inbound access restrictions (such as allowlisting corporate IPs for admin endpoints).

Least-exposure default: expose only the web endpoint (HTTPS). Avoid adding extra inbound ports; most platform services do not even allow arbitrary inbound ports, which is a security advantage.

VNet-based networking (Virtual Machines)

With Virtual Machines, you are responsible for most networking and host security controls. A typical VM web setup includes:

• A VM network interface (NIC) in a subnet inside a Virtual Network (VNet).

• A public IP (directly on the VM or, preferably, on a fronting component like a load balancer or application gateway).

• Network Security Groups (NSGs) controlling inbound/outbound traffic at subnet/NIC level.

• OS-level firewall rules (Windows Firewall / iptables) controlling traffic on the VM itself.

Least-exposure default: do not assign a public IP directly to a VM unless you must. Prefer placing a reverse proxy/load balancer in front and keep the VM private. If you must manage the VM, avoid exposing SSH/RDP to the internet; use private connectivity and strict allowlists.

Walkthrough: a typical request path from browser to Azure endpoint

This walkthrough shows where DNS, public endpoints, ports, TLS termination, and firewall rules apply. The exact components differ by service, but the flow is similar.

Step 1: Browser resolves DNS

When a user visits https://www.example.com:

• The browser (via a DNS resolver) queries DNS for www.example.com.

• DNS returns either an IP address (A record) or an alias (CNAME) that ultimately resolves to an IP.

Where this can fail: wrong record type, stale TTL, or missing verification TXT record when binding a custom domain to an Azure service.

Step 2: Client connects to the public endpoint on port 443

The browser opens a TCP connection to the resolved destination on port 443 for HTTPS (or port 80 for HTTP). This is the first place where inbound exposure matters:

• For App Service/Container Apps, Azure’s front-end accepts the connection.

• For VM-based hosting, the connection reaches your public IP (or a load balancer/application gateway public IP) and then is forwarded to the VM.

Step 3: TLS handshake and TLS termination

TLS termination is where HTTPS encryption is established and the certificate is presented. It can happen at different layers:

• Platform-managed services: TLS often terminates at the service front-end (Azure-managed). You bind a certificate to your custom domain and can enforce HTTPS-only.

• VM-based services: TLS can terminate on the VM (web server like Nginx/IIS) or on a fronting reverse proxy (recommended). If TLS terminates before the VM, traffic between the terminator and the VM should be protected (for example, re-encrypt to the backend or keep it on a private network).

Practical cautions: ensure the certificate matches the hostname users visit (CN/SAN). If you use HTTP for port 80, use it only for redirecting to HTTPS.

Step 4: Firewall and access rules decide whether traffic is allowed

After the connection attempt, one or more layers can allow or block it:

• Service-level access restrictions (App Service access restrictions, Container Apps ingress settings): allow/deny by IP ranges, require authentication at the app layer, or restrict ingress to internal-only depending on configuration.

• NSG rules (VM-based): define which inbound ports are allowed to the VM subnet/NIC. A safe baseline for a public web VM is to allow inbound TCP 443 (and optionally TCP 80 for redirect) and deny everything else from the internet.

• OS firewall (VM-based): should match the NSG intent. Treat it as a second layer, not the only layer.

Least-exposure rule: if a port is not required for end-user web traffic, it should not be open to the internet.

Step 5: Request reaches the web app

Once allowed through, the HTTP request is routed to your application:

• App Service/Container Apps: the platform routes the request to your app instance(s). You typically do not manage inbound ports beyond HTTP/HTTPS ingress.

• VM: the request reaches your web server process listening on the configured port (often 80/443 on the VM, or a private port if a reverse proxy forwards internally).

Practical step-by-step: setting up DNS and safe inbound exposure

Scenario A: Custom domain for App Service (platform-managed endpoint)

This is the common pattern when you want Azure to manage the public web front-end.

• Step 1: Identify the Azure-provided hostname (for example, myapp.azurewebsites.net).

• Step 2: Add DNS records at your DNS provider:

  • Create a CNAME for www pointing to the Azure hostname.

  • Create the required TXT record for domain verification (Azure will tell you the exact name/value).

• Step 3: Bind the custom domain in Azure and wait for verification to succeed.

• Step 4: Configure TLS:

  • Attach a certificate for www.example.com (managed or uploaded).

  • Enable HTTPS Only.

  • If port 80 is enabled, configure redirect to HTTPS.

• Step 5: Restrict access if needed (optional but common for admin paths): use access restrictions to allow only trusted IP ranges to sensitive endpoints, or put admin tools behind authentication.

Caution: do not attempt to “open extra ports” for App Service like you would on a VM. If your app needs background processing or internal services, use platform features (jobs, queues, internal endpoints) rather than exposing new inbound ports.

Scenario B: VM-hosted website with a public IP (VNet-based endpoint)

This pattern gives maximum control, but also maximum responsibility.

• Step 1: Decide where the public IP lives:

  • Preferred: public IP on a fronting reverse proxy/load balancer, VM stays private.

  • Simple but riskier: public IP directly on the VM NIC.

• Step 2: Create DNS A record:

  • Point www.example.com to the public IP with an A record.

• Step 3: Lock down inbound with NSG rules (baseline):

  • Allow inbound TCP 443 from Internet to the web endpoint.

  • Optionally allow inbound TCP 80 only if you need HTTP-to-HTTPS redirect.

  • Deny inbound management ports from the internet (SSH 22, RDP 3389). If temporary access is required, allow only from a specific trusted IP and remove the rule immediately after use.

• Step 4: Configure OS firewall to match:

  • Allow the web server ports you actually use.

  • Ensure management services are not listening publicly, or are restricted to private interfaces.

• Step 5: Configure TLS termination:

  • Install and configure the certificate on your reverse proxy/web server.

  • Prefer serving the site only on HTTPS and redirect HTTP to HTTPS.

Caution: a VM is not “secure by default” just because it’s in Azure. If you expose a public IP, you will receive internet scans. Keep the exposed surface area minimal (ideally only 443) and avoid direct admin access from the internet.

Quick comparison: platform-managed vs VM-based networking

• App Service / Container Apps: you mainly manage DNS, custom domains, TLS settings, and service-level access restrictions. The platform limits inbound exposure to web ingress patterns, which reduces risk.

• Virtual Machines: you manage public IP placement, NSGs, OS firewalls, patching, and service hardening. You can expose any port, which is powerful but increases the chance of accidental exposure.

Common safety checks (least-exposure defaults)

• Expose only 443 publicly for production websites; keep 80 only for redirect if needed.

• Do not expose SSH/RDP to the internet; if unavoidable, restrict by source IP and time-box access.

• Ensure TLS terminates at a controlled point and certificates are valid for the domain.

• Use service-level access restrictions (platform) or NSGs (VM) to enforce allow/deny rules.

• Prefer placing compute behind a managed front end (platform service or reverse proxy) rather than giving every server a public IP.