This is a continuation of a series of articles on operational engineering aspects of Azure public cloud computing that included the most recent discussion on Azure DNS which is a full-fledged general availability service that provides similar Service Level Agreements as expected from others in the category. In this article, we discuss delegation.
Azure DNS allows hosting a DNS zone and managing the DNS records for a domain in Azure. The domain must be delegated to the Azure DNS from the parent domain so that the DNS queries for that domain can reach Azure DNS. Since Azure DNS isn't the domain registrar, delegation must be configured properly. A domain registrar is a company who can provide internet domain names. An internet domain is purchased for legal ownership. This domain registrar must delegate to the Azure DNS.
The domain name system is a hierarchy of domains which starts from the root domain that starts with a ‘.’ followed by the top-level domains including ‘com’, ‘net’, ‘org’, etc. The second level domains are ‘org.uk’, ‘co.jp’ and so on. The domains in the DNS hierarchy are hosted using separate DNS zones. A DNS zone is used to host the DNS records for a particular domain.
There are two types of DNS Servers: 1) An authoritative DNS Server that hosts DNS zones and it answers the DNS queries for records in those zones only and 2) a recursive DNS server that doesn’t host DNS zones but queries the authoritative servers for answer. Azure DNS is an authoritative DNS service.
DNS clients in PCs or mobile devices call a recursive DNS server for the DNS queries their application needs. When a recursive DNS server receives a query for a DNS record, it finds the nameserver for the named domain by starting at the root nameserver and then walks down the hierarchy by following CNAMEs. The DNS maintains a special type of name record called an NS record which lets the parent zone point to the nameservers for a child zone. Setting up the NS records for the child zone in a parent zone is called delegating the domain. Each delegation has two copies of the NS records: one in the parent zone pointing to the child, and another in the child zone itself. These records are called authoritative NS records and they sit at the apex of the child zone.
The DNS records help with name resolution of services and resources. It can manage DNS records for external services as well. It supports private DNS domains as well which allows us to use custom domain names with private virtual networks.
It supports record sets where we can use an alias record that is set to refer to an Azure resource. If the IP address of the underlying resource changes, the alias record set updates itself during DNS resolution.
The DNS protocol prevents the assignment of a CNAME records at the zone apex. This restriction presents a problem when there are load balanced applications behind a Traffic Manager whose profile requires the creation of a CNAME record. This can be mitigated with Alias records which can be created at the zone apex.
Azure DNS alias records are qualifications on a DNS record set. They can reference other Azure resources from within the DNS zone. For example, an alias record set points to a public ip address instead of an A record. This pointing is dynamic. When the IP addresses change, the record sets update dynamically during name resolution. An alias record set can exist for A, AAAA, CNAME record types. An A record set also known as a resource record set is the collection of DNS records in the zone that have the same name and are of the same type. An AAAA record is for ipv6 address. The SOA and CNAME record types are exceptions The DNS Standard does not permit multiple records with the same name for these types. These record sets can only contain a single record.
Azure DNS supports wild card records. These get returned in response to any query with a matching name. CAA records allow domain owners to specify which certificate authorities are authorized to issue certificates for their domain.
CAA records allow domain owners to specify which certificate Authorities are authorized to issue certificates for their domain and this allows them to avoid issuing incorrect certificates in some cases. The CNAME record sets can’t co-exist with the other record sets with the same name. Also, CNAME record sets can’t be created in the zone apex (name = ‘@’) which will always contain the NS and SOA record sets during the creation of the zone. The NS records are bound to the creation and deletion of the zone. It contains the name of the Azure DNS name servers assigned to the zone. This only applies to the NS record set to support cohosting domains with more than one DNS provider
Some of the validations that can be performed on these records include:
1. Parent Zone with conflicting child records fails
2. Delegation with no conflicts pass
3. Delegation with already configured zone passes
4. Delegation with different configured zone fails
5. Delegations with trailing dot in record set pass
6. Zone with intermediate delegation fails
7. Zone with root wild card fails
8. Zone with root Txt wild card fails
9. Zone with intermediate wild card fails
10. A record can be created in the zone
11. A record can be created in an empty zone
12. A record can be created with the same data
13. A record can be created with compatible existing records
14. A record with conflicting another A record fails
15. A record with conflicting CNAME record fails
16. A record with conflicting wild card record fails
17. A CNAME record can be created
18. A CNAME record can be created in an empty zone
19. A CNAME record with same data succeeds
20. A CNAME record with conflicting record fails
21. A CNAME record with conflicting wild card fails
No comments:
Post a Comment