Skip to main content

Technical Lab: Design Public DNS Zones

Questions​

Question 1 — Multiple Choice​

An infrastructure team needs the domain api.contoso.com to resolve to two different IP addresses with simple round-robin load balancing in Azure public DNS. The public zone contoso.com is already created in Azure DNS.

Which configuration combination meets this requirement?

A) Create an A record with the name api and high TTL, pointing to an Azure Traffic Manager profile with Performance routing method.

B) Create two A records with the same name api and different TTLs, each pointing to a different IP.

C) Create two A records with the same name api, same TTL and different IPs, forming a record set with multiple values.

D) Create a CNAME record with the name api pointing to an external A record that contains both IPs.

Question 2 — Technical Scenario​

A company acquired the domain fabrikam.net from an external registrar and created a public DNS zone in Azure DNS for this domain. After correctly delegating the zone to Azure name servers, internal records are working, but a TXT record created for domain validation in Microsoft 365 is not being resolved externally.

The team verifies the record in the portal and it exists. What is the most likely cause?

A) TXT records are not supported in Azure DNS public zones; it should have been created as a native SPF record.

B) The TXT record TTL is set to 3600 seconds, causing excessive caching in external resolvers.

C) The delegation was done pointing to only one of the four name servers provided by Azure DNS, and the other three are not being used.

D) The TXT record name was created with an explicit trailing dot, making it absolute rather than relative to the zone.

Question 3 — True or False​

In Azure DNS, a public DNS zone can contain a CNAME record at the zone apex (i.e., with the name @), as long as it doesn't coexist with other A or AAAA record types at the same level.

Question 4 — Technical Scenario​

An architect needs to host public DNS zones for three distinct clients, each with their own domain, within a single Azure subscription. He plans to use a single Resource Group to centralize management.

During planning, he observes the following behavior when trying to create the zones:

Zone 1: cliente-a.com    -> created successfully
Zone 2: cliente-b.com    -> created successfully
Zone 3: cliente-a.com    -> ERROR when creating in the same Resource Group

Which statement correctly explains the observed behavior?

A) Azure DNS doesn't allow hosting zones from different clients in the same subscription due to namespace isolation requirements.

B) It's not possible to create two zones with the same name within the same Resource Group, but it's possible to create them in different Resource Groups within the same subscription.

C) The error occurs because the zone cliente-a.com already exists globally in Azure DNS, and zone names are globally unique.

D) Azure DNS requires each client zone to be created in a separate subscription to avoid name server conflicts.

Question 5 — Multiple Choice​

An organization uses Azure DNS to host the public zone contoso.com. The security team requires that email traffic be delivered with preference to the server mail1.contoso.com and only in case of failure, to mail2.contoso.com.

Which MX record configuration correctly implements this requirement?

A) Create two MX records: mail1.contoso.com with priority 10 and mail2.contoso.com with priority 20.

B) Create two MX records: mail1.contoso.com with priority 20 and mail2.contoso.com with priority 10.

C) Create an MX record pointing to mail1.contoso.com with priority 1 and an A record for mail2.contoso.com as fallback.

D) Create two MX records with the same priority and rely on TTL to define delivery preference.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: C

In Azure DNS, a record set is the management unit for records with the same name and type. To implement DNS round-robin, create a single A-type record set with the name api, same TTL and multiple IP values. The resolver returns all IPs and clients alternate between them.

Alternative B is a common distractor: records with different TTLs under the same name are not allowed in Azure DNS; TTL is a property of the record set, not the individual record. Alternative A introduces Traffic Manager, which solves a different problem (intelligent routing, not simple round-robin). Alternative D is invalid because a CNAME cannot point to an A record with multiple IPs equivalently, and CNAMEs have restrictions at the apex.

Answer Key — Question 2​

Answer: C

Azure DNS provides exactly four name servers for each public zone. Correct delegation requires that all four be configured at the external registrar. When only one is delegated, resolution may work intermittently (when the resolver hits that server) or fail when trying the other three, which are not authorized for the zone according to the registrar. This explains the inconsistent behavior: records work in some contexts and fail in others.

Alternative A is false: TXT type is fully supported in Azure DNS public zones. Alternative B (TTL of 3600) describes normal and expected behavior, not a failure. Alternative D describes a real misconception about absolute versus relative names, but the Azure portal handles this automatically when creating records.

Answer Key — Question 3​

Answer: False

Azure DNS does not support CNAME records at the zone apex (the name @), regardless of coexistence with other types. This is a DNS protocol restriction (RFC 1034), not an Azure-specific limitation: a CNAME at the apex would conflict with mandatory SOA and NS records. The statement misleadingly suggests the restriction would be about coexistence with A/AAAA; in reality, the prohibition is absolute for the apex. To cover the apex with a canonical name, Azure DNS supports alias records (ALIAS records) pointing to resources like Traffic Manager or Front Door, which solve this scenario without violating the RFC.

Answer Key — Question 4​

Answer: B

In Azure DNS, the zone name is unique within a Resource Group, but not within the subscription as a whole. It's perfectly valid to create the same zone in different Resource Groups within the same subscription. This is a pattern used for multi-tenant or segregated test and production environments. Each zone instance will receive a distinct set of Azure name servers, which requires attention during delegation.

Alternative C represents a frequent misconception: public DNS zone names are not globally unique in Azure; uniqueness is scoped to the Resource Group. Alternatives A and D describe restrictions that don't exist on the platform.

Answer Key — Question 5​

Answer: A

In MX records, lower priority indicates higher preference. Therefore, mail1.contoso.com with priority 10 will be tried first, and mail2.contoso.com with priority 20 will act as fallback. Alternative B reverses this logic, giving preference to the wrong server. Alternative C is technically invalid: an A record doesn't function as MX fallback; only MX records are consulted for email delivery. Alternative D describes round-robin, not prioritization: equal priorities make email servers alternate between destinations without defined preference.